The question that is coming
Sometime in the next year, someone is going to ask you what your AI coding agents were instructed with when they wrote the code you ship.
It might be an enterprise customer’s due-diligence questionnaire, growing a new section the way they grew a sub-processor section a decade ago. It might be an auditor. It might be your own engineers, three months into an incident review, trying to establish why a service handles retries the way it does. The asker varies; the question is the same: what did the machine that wrote this know about how you build software?
The honest answer, in most engineering organizations today, is that nobody knows. Not “it’s written down somewhere.” Genuinely unknowable — because nothing recorded it, it was assembled differently by every developer in every session, and the sessions are gone.
That is a strange thing to be unable to state about your primary means of production.
Velocity arrived. Governance didn’t.
Nobody decided this. Coding agents arrived bottom-up — a developer here, a team there — and they made the numbers better. Cycle time down, deploy frequency up, backlogs finally moving. Every metric you track improved, so every review of the situation ended with “keep going.”
But the metrics you track measure output. What changed underneath is an input: the instruction layer.
In the human era, you knew — roughly, imperfectly — what your engineers had been taught. Onboarding taught the systems. Code review transmitted the standards. Tech talks, design docs, the senior engineer two desks away: it was informal, but it was inspectable, and it was roughly the same education for everyone.
In the agent era, an agent’s entire professional education is its context window, assembled in the seconds before it writes. And who assembles it? Whichever developer happens to be running the session — from a private rules file, from folklore, from whatever they remembered to paste in. Multiply that by every developer, every repository, every session, and you get the current state of most organizations:
Context is the management layer of AI-assisted engineering.
Right now, almost nobody manages it.
You multiplied write events without multiplying the layer that instructs them. The gap between those two curves is where your architecture is quietly being decided.
The ten-minute audit
You do not need a tool to see this. You need three questions in your next staff meeting or leads channel, and honest answers.
1
The instruction question
Pick three active repositories. Ask each lead: “Which of our architectural standards were in your coding agents’ context last sprint — and by what mechanism did they get there?” A real answer names artifacts and a delivery path. “Our developers know the standards” is an answer about humans; the question was about agents. If the room goes quiet, that silence is the finding.
2
The variance question
Ask two developers on the same team to share their agent configuration — the rules files, the standing prompts, whatever their tools read at session start. Diff them. That diff is your de facto standards variance: each developer is running a private fork of your engineering standards, forked at the moment they last paid attention, and the forks have never been reconciled. Your architecture, as practiced, is the union of those forks.
3
The evidence question
Take one AI-assisted change that shipped last month — ideally one on a critical path. Ask for the record of what constraints the agent was operating under when it wrote the code. Not what the developer believes was in there; the record. This is the exact question the due-diligence questionnaire will ask. Today the answer is that no such record exists.
Score it honestly. Most organizations get: unanswerable, alarming, and none.
Why this lands on your desk
This is not a tooling preference for the platform team to sort out. Four properties make it a leadership problem.
Risk. When the customer, the auditor, or the postmortem asks the evidence question, “we don’t know” becomes an answer on the record — about the process that produced the majority of your recent code.
Consistency. Standards that reach agents through private forks aren’t standards; they’re suggestions with variance. At agent speed, that variance compounds into the codebase faster than review can catch it.
Waste. Every team is independently solving context assembly — badly, in parallel, without sharing. That is undifferentiated heavy lifting performed by your most expensive people.
Compounding. Agents learn your codebase partly by reading it. Whatever ships becomes the example the next session imitates. Ungoverned context doesn’t produce one bad quarter of code; it seeds the corpus that future code is written against.
And the same asymmetry, read the other way, is the opportunity. Same agents, same models, same spend — materially different code, depending entirely on what the agents are told. Context is the one input in the whole AI stack that you fully control. It is the cheapest quality lever you have, and in most organizations it is currently set by folklore.
The document plane, from the org chart
What does the governed version look like? Not a new gate in the pipeline — a missing layer under it. We call it the document plane: one versioned layer where standards, specs, decision records, and checks live, delivered identically to every agent at write time, with evidence flowing back the other way. Governed context has four properties:
1
One source, versioned. The standards agents receive are the standards in git — not thirty private forks of a wiki page.
2
Uniform delivery. Every agent in every repository pulls from the same layer, through the same protocol, at the moment it writes.
3
A return path. Decisions agents make come back as records, made at the moment of decision — so the evidence question has an answer by construction.
4
Drift detection. The layer flags when its own content stops matching the repositories it governs.
This is what we are building with SystemDox. Concretely: standards, specs, architecture decision records, checks, and project rules live git-first with GitHub as the source of truth, and are served over MCP — the open protocol Claude Code, Cursor, and effectively every serious coding agent now speaks — so every agent session starts from the same governed context instead of a private fork. Agents record architectural decisions as they make them, repository scanning flags documentation that has drifted from the code, and the same knowledge publishes as a readable knowledge base for humans.
Note what is absent: a new approval step, a new IDE, a new process for developers to resent. The layer rides the protocol the agents already use. Governance arrives as configuration, not as friction — which is the only way governance survives contact with a delivery organization.
And the question this article opened with becomes answerable in one sentence: what were the agents told? — read the repository. The answer is versioned, diffable, and the same for every team.
What this does not fix
Delivered context is not obeyed context. Agents follow instructions imperfectly, which is why the document plane pairs delivery with verification — checks that validate output against the standards in CI — and why code review remains your control, not a casualty. Distribution also amplifies whatever you distribute: a weak standard, uniformly delivered, is now uniformly weak. The quality of the governance content remains your organization’s job. This layer makes your standards reach and your decisions traceable; it does not make them right.
Start here
Ask the three questions this week. Budget ten minutes; the silence is usually immediate.
If they come back unanswerable, instrument one repository: publish the standards you already have into a document plane, point that team’s agents at it, and re-ask the instruction question next quarter. SystemDox’s free tier covers one repository, permanently — one governed repo is enough to show your leads what an answerable question feels like.
You measured the velocity. Now govern the instruction layer that’s steering it.