Project context, instructions & MCP

Context drift is a structural problem, not a discipline problem. A context file is a snapshot of the project at the moment you last edited it, and the project does not hold still for the snapshot. Decisions change, structure evolves, the FastAPI setup you documented gets reorganized — and the file keeps describing the old world. Because nothing forces an update, the default state of a hand-maintained context file is mildly out of date, trending toward badly out of date the longer the project lives.

The cost is subtle and corrosive. An agent following a stale rule does not error; it does the wrong thing correctly, with full confidence, because the instruction told it to. Cursor users describe exactly this: CLAUDE.md and AGENTS.md files that keep old decisions and deprecated patterns around until agents follow obsolete rules. You then debug a problem that traces back not to the code but to a memory file nobody updated.

No amount of diligence closes the gap, because the project changes constantly and the file changes only when you remember to touch it. The fix is not more disciplined file maintenance — it is removing the manual maintenance from the loop, so the rules and decisions live somewhere that can be updated and retired instead of quietly rotting in a markdown file.

The other half of the file pain is repetition across tools. The same project rules have to be told to Claude Code, to Codex, to Cursor, separately, again and again, because each one starts from nothing and there is no shared source of truth between them. You become a human synchronization layer, copying the same context into three different formats and keeping all three current by hand — which, predictably, you do not, so they drift independently and disagree with each other.

The honest answer to "how much context should I give?" is that the format is the problem. Pasting and re-pasting the same setup paragraph into every chat, every day, for every tool was never going to scale, because it puts the maintenance burden on the human and the maintenance never gets done. So everybody's AI ends up working from a worse picture than the person can actually articulate. Cursor users ask this directly: how do you give coding tools memory that carries repo structure, failed attempts, task state, and decisions across sessions and tools?

The goal is a single source of truth the tools draw from, instead of N hand-kept copies that each go stale on their own schedule. Store the context once; let each client reach into it.

The first instinct when a team adopts AI is to standardize: "we're a Cursor shop now," "everyone use Claude Code." Then the second week happens. The backend person likes Claude Code for shell-heavy work, the frontend person wants Cursor's inline diffing, the PM thinks out loud in ChatGPT, the data person has a private MCP-driven workflow that fits none of those. You can fight that and lose — people use what makes them faster — or accept that the tool is the wrong unit to standardize on.

What a team actually needs in common is not a vendor. It is the project's living context: the prompts that work, the decisions that have been made, the conventions someone wrote down, the named customers and systems. A two-person AI startup framed it precisely — execution is not the bottleneck anymore; keeping long-term vision, roadmap, docs, meeting notes, tasks, and backlog synchronized is.

If the shared layer sits underneath the tools instead of inside one of them, the standardization problem dissolves. Each person picks the client that fits their hands; they all reach into the same context. A decision recorded once ("we're not upgrading to v4 yet because of the auth break") surfaces weeks later when a different teammate asks the AI about the upgrade path — and stops the loop. Pick a single vendor's app to hold shared context, and you have just forced everyone back into that app to use it.

There is a failure mode of AI memory worse than forgetting. You keep a decisions.md maintained with the agent's help; over weeks it drifts out of sync with reality; then one day the agent reads the drifted record and implements the exact opposite of a decision you actually made — with confidence, because the record looked settled. Forgetting is recoverable: you notice the gap and fill it. A confident contradiction ships before anyone questions it.

AI-maintained docs drift the same way hand-maintained ones do, sometimes faster, because they accumulate plausible-sounding additions that were never actually decided. The deeper issue: a memory you cannot verify is indistinguishable from one that is wrong. If you have to re-check every remembered decision against reality before trusting it, the memory has saved you nothing — you are doing the work of remembering anyway, plus an audit step. The stakes climb for sensitive work — financial models, regulated material — where a lossily summarized detail has real consequences.

So "does the AI remember?" is the wrong question. The right one is "can I trust what it remembers?" That means source-linked claims that point back to the conversation or document they came from, retrieval that surfaces the actual decision rather than a paraphrase of a paraphrase, and visibility into what context was used and why. Memory you cannot inspect cannot be trusted, no matter how confidently it reads.

For two years the default unit of AI work has been the conversation: open a chat, explain your situation from scratch, get something useful, close the tab. The transcript drifts into a sidebar you will probably never open again. It worked because the alternative was nothing — but it quietly trained everyone to treat hard-won context as disposable.

Chat history is a log, not a memory. A transcript records what happened but does not decide what should be carried forward. Long conversations contain useful decisions next to false starts, outdated instructions, pasted files, and dead branches of reasoning. If all of that becomes memory equally, the next session inherits noise; if none of it does, you explain the project from scratch again. Longer context windows do not fix this — a million tokens can still hold stale instructions, contradictory decisions, and missing source links.

The valuable material was never the conversation itself. It is the decisions, constraints, source links, project facts, prompt patterns, and next actions that should survive after the window closes. Owned memory starts from a different premise: capture those reusable pieces as first-class objects, with structure that lives outside the session that produced them. Do that, and each session starts in the middle of the work instead of at the beginning — the transcript stays as evidence, and the small, reusable core becomes the actual memory.

A recurring thread: a Claude user running a heavy trading project with many uploaded files, linked data, and specific instructions, wondering whether a different model would do better — when the real problem is not the model. Uploaded files hit limits, and retrieval is where it breaks. A PhD student has two years of research notes, meeting notes, and protocol notes in Obsidian; a productivity thread describes saving huge amounts of knowledge and then failing to retrieve it under deadline pressure.

Saving context feels productive until you need a specific piece of it later. That is where note systems and AI chats fail — they collect material, but retrieval depends on remembering the right folder, title, prompt, or conversation date. A project workspace used as a long-running tutor (a curriculum log, a mock-interview score sheet, standing pair-coding instructions) is genuinely effective until it fills the context limit and the only move is to upgrade the plan or start deleting the very history that made it useful. The asset there was never the chat; it was the small, structured, portable curriculum log and instruction set.

Real project memory has to include the documents and decisions, not just the transcript — and it has to make retrieval part of the design. Project names, topics, source links, tags, and recent use are what answer the practical question: what context should be available for this next piece of work?

People building fully local AI assistants — running models on their own hardware, deliberately, so nothing leaves the box — keep hitting the same missing piece: not the model, the memory. A local assistant with no persistent context is a clever stranger every morning; it cannot recall your projects, preferences, or last week's decisions without a place to store them. And the memory has to honor the same boundary as the model. There is little point running inference locally if the assistant's long-term memory ships off to a cloud service.

Ownership sounds philosophical until a model changes, a product limit appears, an account gets locked, or a workspace migration begins. Then it is operational: users need to export the memory, inspect it, back it up, and bring it to another assistant. There is a privacy edge too — handing an entire personal research archive (client material, half-formed ideas, private notes) to an external service just to get a deck out of it is a real decision, not a checkbox.

The durable pattern is a local or exportable layer that sits beside the model. It can feed Claude today, a local model tomorrow, and a different workspace next month, and it preserves your decisions even when the chat surface changes. The model is replaceable; the memory should not be. Local-first is not a feature here — it is the whole premise.

Look at the last five MCP servers that landed in your timeline. One shipped a memory tool — so it added a storage backend, an embeddings pipeline, a search index, and a CRUD surface. One shipped a prompt library — same thing, different schema. One a credentials helper, one a research notebook, one a "context" tool. Five servers, five almost-identical storage layers, five different places your data lives, five sets of trust decisions to make.

MCP nailed the boundary between the model client and the tool: a server exposes capabilities, a client decides when to call them. But the protocol said nothing about where the durable state underneath a tool should live, so every author ships their own — SQLite under ~/.local/share, JSON in a config folder, a cloud backend with an API key you are expected to manage. The protocol that was supposed to unbundle tools accidentally bundled storage into every single one. Use five MCP tools and your prompts sit in one substrate, memories in another, snippets in a third — none aware of each other.

What is missing is not a protocol change but a convention: a default vault layer that is local-first, encrypted by default, MCP-native, schema-flexible, and portable — something server authors call the way web apps call Postgres. Then the boring half of every project goes away, and the user's data lives in one durable, auditable place underneath the tools instead of scattered beneath each of them.