Context routing only works when the source of truth is boring

One of the quieter lessons from working with coding agents is that context is not a pile of files. It is a routing problem. The agent does not need every document in the repository. It needs the right slice of truth at the moment a decision is being made.

I started noticing this when the same project facts kept appearing in different Markdown files: recent memory, long-term memory, feature notes, implementation guides, PR summaries, and meeting write-ups. Each file was useful in isolation, but the system became weaker when they all tried to be the source of truth.

That is where context routing becomes more than prompt hygiene. A good route says: for this task, read the current requirements here, the durable decisions there, and the latest evidence from this smaller note. It keeps the agent from wandering through stale context and keeps the human reviewer from asking why an old assumption came back into the work.

Refreshing the data across Markdown files is the unglamorous part. If one file says the dashboard route belongs to one surface, another says it belongs somewhere else, and a third has the newest proof, the AI workflow will amplify confusion. The fix is not a bigger prompt. The fix is deciding which file owns the fact and making the other files point back to it.

I like treating documentation this way because it makes the system honest. Recent notes can be temporary and evidence-heavy. Long-term memory can hold durable rules. Feature specs can own product intent. Implementation guides can own repeatable execution. They do not all need to repeat each other. They need clear authority and a refresh path.

The same discipline applies inside a product codebase. A design token should not be redefined in three components. A route rule should not live in a test, a README, and a helper function with slightly different wording. A translation key should not become a second product requirement. When truth is duplicated, every future change becomes a negotiation with drift.

AI makes this more important, not less. Coding agents are very good at following written context, which means bad context becomes executable. If the Markdown is stale, the agent can produce a confident implementation of yesterday's decision. If the source of truth is clear, the same agent becomes much more useful because it can move quickly without inventing the ground it stands on.

So my version of AI-native engineering is not only better prompts or faster code generation. It is a documentation system where facts have owners, context has routes, stale files get refreshed, and every repeated claim has a reason to exist. The boring source of truth is what lets the exciting tools do reliable work.