Use cases
Something you already explained, being asked for again. Six places that happens, and what changes when the context is yours rather than each tool’s.
Six situations
None of these are job titles. They are moments — and if you work across more than one AI tool, you have had at least three of them this month.
Today · You explain the architecture, the conventions and the deploy path in your editor. Then you open a browser chat and explain all three again.
With shared context · Both read the same context, and an answer can show which source a fact came from rather than asking you to take it on trust.
Today · A tool confidently proposes the approach you ruled out two months ago, because nothing it can see records that you ruled it out.
With shared context · The decision and the reason behind it are stored context, so the suggestion arrives already knowing it was considered and rejected.
Today · How you name things, how you want reviews framed, the phrasing you never want suggested — retyped at the top of every session.
With shared context · Written once as a preference item, with your consent recorded on it, and read by whichever tool you happen to be in.
Today · Reconstructing what changed means reading through commits, tickets and threads before you can ask a useful question.
With shared context · The state of the work is already context, kept current from the sources it came from, with the age of each item visible.
Today · The same walkthrough, delivered by you, for the fourth time — and their tools still start from nothing afterwards.
With shared context · They get the slice you scoped for them, and so do their tools, without you being the transfer mechanism.
Today · Whatever a vendor's memory feature learned about you stays inside it. Switching means rebuilding the picture by hand.
With shared context · The layer is yours, not the vendor's. A new tool connects to the same context, and you can export or delete all of it.
The right-hand column describes what the product is for, not a list of things that all run today. Which parts do is itemised in the capability ledger — including the ones that do not.
The pattern underneath
Every situation above is the same three moves. The point of the whole thing is that you only perform the first one.
You authorize a source once, scoped at the moment you grant it. Widening what it reads takes a new grant.
Material from that source becomes context items that carry where they came from and when they arrived.
A tool that speaks the Model Context Protocol asks for context and gets the part it is permitted to see.
You stay the owner throughout: every item shows its origin, everything is exportable in an open format, and a connection can be revoked on its own. See the docs for the endpoints behind each move.
Connect a source, point a tool at it, and explain it once. Free while we build the core.