Solving the “cold start” with a personal Context Passport

If I was going to build a startup in 2026 (and I might) here's one idea I would be looking at:  solving The Cold Start Problem with a personal context passport.

In commercial AI, the “cold start” is that moment of friction where the machine knows nothing about you. When you load up a new app or platform you have to paste in your preferences, your history, and your constraints. Again. And again. Think about the amount of times you have to fill information in when searching for a holiday. 

But what if we flipped the model?

What if, instead of every app building (and owning) a profile of you, you held a portable context that you could share on your terms?

This idea starts as a way of making everyday things, like shopping, travel, and fitness easier. But it could end somewhere much bigger: giving people control over their data in the most critical moments of their lives.

Version 1 (low-fi): The "Me" File

Right now, we could sort of solve the cold start problem with simple documents. For the sake of the investors we'll call this a 'Context Passport', but really it's just a simple, structured document you use when you interact with LLMs. Set some context fields, set your preferences, and away you go. So next time you interact with a travel ‘agent’ (as in an AI Agent - see what I did there) or a fitness coach LLM, you don't need to type out your history. You just upload the relevant ‘passport’.

Here’s an example: The Travel Context

Planning a trip is a pain. Yes there are apps that pull together bits of this, but you have to constantly jumped around, re-entering preferences or being stuck with one vendor. And it’s why agents are being pushed in this space to make life easier… but soon there will be a proliferation of different agents and then shortly after you’ll be answering the same twenty questions about budgets and preferences. Could a travel passport solve this? Maybe it looks something simple like this?

Travel Context - [Your Name]

Logistics

• Home Airport: NCL (Newcastle)
• Local Train Station: Newcastle
• Citizenship: UK
• Loyalty: British Airways (Gold)

Train Preferences

• Seat: Table, quiet carriage, window

Accommodation Style

• Vibe: Boutique/Independent over large chains.
• Must-haves: High-speed WiFi (remote work), blackout curtains.
• Avoid: All-inclusive resorts, ground floor rooms.

Travel Pace

• Style: "Deep Dive" - prefer 5 days in one city vs. 5 cities in 5 days.
• Food: Priority on street food/local markets over fine dining.

Here’s another example: The Fitness Context

The fitness industry is huge and the push for AI coaches is big business. But most are too general to really help you as they don’t have the context of you. So what about if you held that context and shared it with your new ‘coach’ allowing the AI to offer advice that might be closer to your needs, preferences and constraints. 

Fitness & Wellbeing Context - [Your Name]

Physiological Profile

• Injuries: Left knee ACL reconstruction (2019) - avoid high impact.
• Conditions: Mild asthma (triggered by cold air).

Goals

• Primary: Functional strength for hiking.
• Anti-Goal: Not interested in bodybuilding or aesthetics/weight loss focus.

Logistics

• Equipment Access: Kettlebells (12kg, 16kg), Yoga mat. No gym membership.
• Time Constraints: 30 mins max, Mon-Fri mornings.

Now of course at this stage, this is just a file you control, and in fact this is something you could make yourself and sort of do this process now, by adding it into any of the chat interfaces, store it in chatGPT as context, add it as artefact in Claude. But you need to do this for every interface, and if we really want to tackle the cold start problem we need to control our data. And as these files grow, simply "pasting" them isn't safe or efficient. You don't want the retail bot to see your health data, or the travel bot to see your housing history.

Version 2: The Logic Layer (Granular Permissions)

This is where the opportunity shifts from “file management” to infrastructure.

If we want portable context to work across tools, we need a way to grant specific apps access to specific slices of our context, for a specific purpose, for a limited time, with revocation and audit logs built in.

Protocols like SOLID point to an architecture where your data lives in a personal pod (user-controlled), not a corporate silo.

Here’s what that kind of permission layer might look like:

section: housing_context.current_situation
access_control:
  - service: "newcastle_housing"
    granted: "2025-11-02T10:30:00Z"
    expires: "2026-06-01T23:59:59Z"
    scope: "full_read"
  - service: "housing_provider"
    granted: "2025-11-10T14:15:00Z"
    expires: "2026-03-15T23:59:59Z"
    scope: "full_read"
audit:
  last_accessed: "2026-01-14T14:22:18Z"
  access_count: 23
  accessed_by: ["newcastle_housing"]

When a service requests your context:

1. Check: The system verifies the service's ID against your permission block.
2. Filter: It strips out everything except the scoped data (e.g., Housing sees tenancy history, but not your fitness goals).
3. Log: It records exactly who looked at your data and when.

Version 3: The Integration Layer

For consumer products, the cold start is annoying. For essential public services, it is worse and possibly actively harmful.

Currently, a person who interacts with public services often repeats their story across different agencies. They act as the "integration layer," carrying their context from the housing office to the food bank to the social worker.

By applying the same logic we used for the "Travel Passport" - portable, user-owned context maybe we can revolutionise public services for the better.

Imagine that you controlled a portable memory vault. Your context, your history, your needs, your circumstances, your preferences, owned by you. When you need to access a service, you grant it temporary, revocable access to the specific parts of your context it needs to help you. Not some monolithic centralised government database that knows everything about everyone (or tries to). Not fragmented silos that know nothing about each other.

Citizen-owned, portable context that you carry with you and share on your terms.

Imagine Alex is trying to stabilise a housing situation: rent arrears have built up after a job change, and three separate processes are in motion:

• The council housing team is assessing homelessness prevention support.
• Universal Credit needs updated rent and landlord details.
• An energy supplier is discussing a payment plan and whether Alex should be treated as needing extra support on the account.

Alex shouldn’t have to re-upload the same documents and re-explain the same timeline three times.

Instead, Alex opens their Context Passport and creates a time-limited “Housing Pack”.

It contains only:

• Tenancy basics (address, start date, landlord contact)
• Rent amount + arrears summary (with a supporting statement/letter)
• Household basics (optional and minimal)
• Preferred contact method + safe times to call

A short, user-written note: what’s changed, and what Alex is asking for
Then Alex shares different slices with different services:

• Council housing team: tenancy + arrears summary + the note (valid for 30 days)
• Universal Credit: rent amount + landlord details only (valid for 14 days)
• Energy supplier: support/payment-plan eligibility flag + contact preferences (valid for 7 days)

No service gets a full profile. Nothing is “always on”. Shares expire by default.

How it works in practice

• Request: the council housing team requests: “We need tenancy details, arrears amount, and confirmation of current income support.”
• Consent: Alex’s wallet shows the request in plain language and offers a minimum-share option (e.g., share a UC award statement + arrears letter rather than full bank statements).
• Coordination: with permission, Universal Credit and/or the landlord provides a simple verification back into Alex’s context: “UC housing element in payment” / “arrears total confirmed as £X on date Y.” The housing team can view that without Alex acting as courier.
• Revocation: shares expire automatically; Alex can revoke access instantly if circumstances change.

Less repetition, fewer missed details, fewer “prove it again” loops.

The Startup Opportunity

So we even have some companies starting to look at this for specific use cases, companies like Mem0 , and there is talk of developing an Open Context Layer (OCL). We have existing technology (SOLID, encrypted pods, LLMs). We have layers for verifiable credentials for identity and things like Open Badges. But at the moment it feels like there is a gap in the personal context layer in the commercial space and especially in the citizen space. 

For me the ‘startup’ opportunity is building the citizen-facing layer that makes this actually usable for public services.

The Citizen Data Wallet: A personal vault where you control your own data. Health records, housing history, educational credentials, benefit assessments, support needs, outcomes from previous interventions. Not scattered across 40 different systems, but in one place you control.

Granular Permission Management: When you access a service, you grant it read access to specific parts of your context. The housing team needs your current situation and support history. They don't need your health records. You grant specific access, time-limited, revocable at any point.

The Service Integration Layer: Public services connect to a standard protocol, not to your specific wallet directly. They request: "we need context about housing need and family composition to assess your application." Your wallet asks: "are you okay sharing this?" You approve. The service gets what it needs, nothing more.

Cross-Service Context Building: When you receive support from multiple services, they can (with your permission) contribute to your shared context. The mental health service logs that you've completed a trauma-informed programme. The housing service can see this (if you grant access), understanding you have support in place. 

Why This Matters

We are moving toward a world of AI agents. If we don't build this infrastructure, there is a risk that every government department and company will build their own "profile" of you, or there is a massive centralised data platform - eek.  You won't know what's in it, you won't be able to correct it, and you won't be able to take it with you.

By starting with simple, personal context, like shopping, travel, and fitness maybe we normalize the idea that you own your data. Once that pattern is established, perhaps we can scale it to solve the "explaining who I am and my context 15 times to different services" problem, turning a bureaucratic nightmare into a system of dignity and control.