Bring your own context

Every new site I sign up to asks me the same things. What am I interested in, how much time have I got, am I vegetarian, how many of us are there. The assistant I use every day already knows most of that, and there is no standard way for it to tell the site, even when I would be happy for it to.

Plenty of tools now let you bring your own API key, so the site gets a model without paying for one. None of them let you bring your own context. The site still starts from nothing about you, and you fill in another onboarding form.

So I wrote a proposal for it, called Context Manifest.

Why now

Assistants hold a lot about the people who use them now. ChatGPT started testing memory in 2024, Claude’s memory became available to everyone in March this year, and that same month Claude and Gemini both added a way to import your memory from another assistant by pasting a prompt. People are already moving their context around.

Sites still cannot use any of it. There is good work on portable memory, but it is about where your memory lives and what shape it takes, not how a site asks for part of it. MCP lets a site ask you a question; it has no way to ask your assistant about you, with a stated purpose and a time limit. And the first vendor routes are appearing, such as Sign in with ChatGPT, which gives a site your name, email and picture through one company’s account. I would rather there was an open way that any site and any assistant can use.

One file, stated up front

A site publishes one JSON file at /.well-known/context-manifest.json saying what it would like to know, why, how long it will keep it, and what it will give back. Your assistant reads it, answers the harmless parts from memory, asks you about the rest, shows you one screen listing exactly what it is about to send, and keeps a receipt of what the site stored.

The worked example is a recipe site. Your diet and the kit in your kitchen are preferences, so the assistant can answer those from memory, although they still appear on the consent screen. How many people you cook for is about other people, so it always asks. Allergies are protected: the assistant never fills them in from memory, you say them yourself, and the site keeps them for that visit only.

The part I care most about is that those classes are fixed by the specification, not chosen by each site. The assistant can raise a class but never lower one. And a manifest cannot ask for passwords, card numbers, government ID, biometrics, live location or the content of your conversations. An assistant that finds one of those refuses the whole thing.

Before you even have an account

A first visit is when a site knows least about you, and it usually comes before sign-up. So the assistant can hand its answers over without an account: it gets back a link that works once, for an hour, and you open it to find the sign-up form already filled in with what you agreed to share. Nothing is kept beyond the session unless you submit that form yourself, and anything sensitive waits until you have signed in.

The half that gives back

The other half is what the site returns: the record of what you actually did there, such as the recipes you cooked and how you rated them. Your assistant learns from what you did, not just from what you told it. A site can even publish a manifest that only gives and never asks.

Small on purpose

It is not a memory format, an identity system or a place to store your data, and it is not a legal basis for anything. It works over MCP, over plain HTTP, or with a paste flow that works with any assistant today.

It is draft 0.1: a specification, schemas, seven worked examples from recipes to car insurance, a validator, and the hard problems written up honestly, from shared family accounts to work and personal assistants that remember different things. If you build sites with onboarding forms, or you work on an assistant, I would like to know where it breaks for you: get in touch.

I used AI assistance to help write and fact-check this post and parts of the specification.