Context is perishable

You open a session with your coding assistant and the first thing it needs is orientation. What are we building? Where did we leave off? What changed since yesterday?

These are real questions, but they point at something worth noticing. The assistant isn’t forgetful - it was never given anything to remember. Each session begins at absolute zero. Whatever understanding the last session built - the thread of reasoning, the feel for where things are heading, the small accumulated judgments about what matters - dissipated the moment the session ended. Nothing carried over. The warmth has to be rebuilt from scratch, every time.

The file that holds still

The community response was to write things down. Context files, memory banks, rule documents - markdown artifacts placed where the assistant can find them on startup. A .cursorrules describing the project. A CLAUDE.md with architecture notes. A memory bank tracking decisions from the last session.

This helps. Genuinely. But the help has a specific shape.

A context file captures what was true at the moment of writing, then holds perfectly still. The project keeps breathing. Tasks complete, priorities shift, blockers resolve, new ones surface. The file knows nothing of this. It sits where you left it, growing quietly inaccurate - the way a stopped clock still shows the right time twice a day but is no longer participating in time.

You can maintain it. Some developers do, diligently, updating the file after every session. But notice what that is: a new maintenance task generated by the tool that was supposed to reduce maintenance. The context about the context has become its own small overhead.

A connection, not a copy

The Model Context Protocol does something structurally different. Not a file for the assistant to read, but a connection to the system where the work is already being tracked.

The distinction is temporal. A file stores state. A connection inhabits it. When the assistant reaches for context, it doesn’t consult a document someone composed last Tuesday. It asks the project board - the living one, the one the team is looking at right now - and receives an answer that is current because it was never separated from the source.

This is not a description of the project. It is the project, speaking for itself.

And then the quieter thing

The first consequence is obvious: no cold start. The assistant arrives with orientation. Good.

The second is the one worth sitting with. When the assistant finishes work, it writes back. Updates a task. Leaves a note. Marks something done. And because it writes to the same surface the team inhabits, the work becomes visible without anyone translating it.

A developer ships a fix at midnight with their AI assistant. The task moves. A colleague on another continent sees it with their morning coffee. Nobody wrote a status report. Nobody compressed what happened into a paragraph. The doing and the showing happened in the same gesture.

This is what kept surfacing while we were building Balladic’s MCP server. Fifty tools connecting an AI assistant to a living project board - reading tasks, updating state, checking dependencies, leaving comments. The protocol is fast, the implementation straightforward. But the interesting thing was never the protocol.

It was what stopped happening. The orientation ritual at the start of each session. The updating of files that describe what the board already knows. The quiet labor of keeping two representations of the same truth in agreement.

When context lives where the work does, it stops being something you maintain. It just stays current - not through any cleverness of its own, but because it was never a copy in the first place.