Is there any portable format for the context you build up with an assistant?

One habit worth adopting whichever route you take: when you correct an assistant about something for the second time, write it into the file immediately rather than after the session.

The corrections you make repeatedly are exactly the content that is worth keeping, and they are the ones you forget existed once the tool has been trained out of the behaviour. Capturing them at the moment of irritation is the only reliable time.

There is no accepted standard, and the practical answer is the boring one: keep it yourself, in plain files, in version control.

What has actually converged is a convention rather than a format — most coding assistants now read a markdown instructions file from the project root. The filenames differ, and the content is just prose, which means one file plus a symlink or a small copy step covers several tools.

So the portable layer already exists and it is markdown in a repository. What is not portable is everything held inside a vendor's account: conversation history, tool configurations, memory features, custom instructions set in a web interface.

My rule after being burned twice: anything I would mind rewriting goes in the repository. If it only exists in a product's settings page, I treat it as disposable.

Worth splitting the context into three kinds, because they have different homes and people try to solve them with one tool.

Project knowledge — conventions, architecture, what not to touch. Belongs in the repository, reviewed like code, and it benefits everyone including humans. This is the largest and most valuable category.

Personal working preferences — how you like to be talked to, your tooling, your habits. Belongs in a personal file you carry between machines.

Task state — what we are doing right now, what has been tried. Genuinely ephemeral, and the thing people most want to preserve and least should. If a task's state matters after the session, it belongs in an issue or a document, not in a transcript.

Most of the pain people describe as "losing my context" is the first category never having been written down, and it is a documentation problem wearing a new hat.

On the bridging products specifically: the value is real and narrow.

What they can genuinely do is export from one product's account and import into another, and keep a canonical copy synchronised so a change lands in several places. That is fiddly work and worth paying for if you switch often.

What they cannot do is make the behaviour transfer. The same instructions produce noticeably different results across models and harnesses — an instruction that was necessary to stop one assistant doing something may be irrelevant or actively harmful with another. So a large accumulated instruction file is partly a record of one tool's quirks.

Which is an argument for periodically pruning it rather than carrying it forever. Half of mine turned out to be workarounds for a model that no longer exists.