The drift
Nobody becomes an ivory-tower architect by getting worse at architecture.
The pattern is more specific than that. An architect who is respected precisely because their recommendations match reality gets promoted. Scope widens. The calendar fills with governance boards, strategy sessions, and stakeholder reviews — each one individually justified, and each one displacing something that was never on the calendar in the first place: the standup dropped in on, the pull request skimmed over coffee, the corridor conversation about why last night’s deploy failed.
Output doesn’t fall. Standards keep getting written. Diagrams stay current. Reviews still happen. But somewhere in this period, recommendations stop being defended with evidence and start being defended with principles. Teams stop working through the architecture and start working around it — and nobody announces that. The first hard signal arrives a year later, and it arrives as a reputation.
From the inside, the whole time, it looks like strategic focus. That is what makes the drift dangerous: it is invisible precisely to the person it is happening to.
The standard diagnosis is personal — the architect “lost touch.” The standard cure is attendance: get back to the standups, review pull requests, sit with a developer during a deployment. This is genuinely good advice, and every experienced architect has given or received it.
But it has a scaling problem, and in the last two years the scaling problem became terminal.
Governance by proximity
The stay-hands-on prescription treats contact as something you attend. Call it governance by proximity: you stay accurate by being physically and socially near the work, sampling it with your own attention.
Proximity works when change is human-paced. An architect covering five teams can personally see a meaningful fraction of the significant changes. At enterprise scope — thirty or forty repositories — the same practice becomes statistical sampling with a sample size too small to mean anything. One standup a week and one pull request a day is a few hundred observations a year against tens of thousands of changes. That is not contact. That is polling, with a margin of error nobody has calculated.
Then coding agents arrived, and the population being sampled exploded.
A growing share of enterprise code is now written by AI agents — in sessions that last minutes, at any hour, in parallel across every repository you govern. An agent does not attend your standup. It does not absorb the architecture through osmosis, and it cannot be taken aside for a corridor conversation. It knows exactly one thing: what is in its context window at the moment it writes. Nothing else.
Which forces a sentence most architecture practices are not built around:
Your architecture exists only to the extent that whoever — or whatever — is writing the code can read it at the moment of writing.
Everything else is a PDF.
There is an uncomfortable inverse, too. Your organization already has a real, operating architecture standard: it is whatever was actually in your developers’ heads and your agents’ context windows, aggregated over the last quarter. Nobody has ever read that document. It is nevertheless the one being followed.
The write-time test
Here is a fifteen-minute audit that requires no tooling — only honesty. Pick two or three repositories you are accountable for and run three checks.
1
The reach test
Take your most important architectural standard — the one you would defend in front of the CTO. Find the most recent commit it should have governed, and trace the path from where the standard lives to the person or agent who wrote that commit, at the moment they wrote it. For a developer: was it open, or reliably in their head? For an agent: was it in the context window? Count the hops. The moment the path includes “someone remembers to bring it up” or “it’s on the wiki if you look,” the test is failed. Not weakened — failed. A standard that reaches the writer only through voluntary recall has the same write-time existence as one that was never written.
2
The return-path test
Find the last three significant technical decisions made in those repositories — a library adopted, a boundary drawn, a workaround accepted. Set a twenty-minute timer and try to reconstruct why each one was made, from artifacts alone: no Slack archaeology, no asking the person who was there. The gap between decisions made and decisions recorded is where drift accumulates. Every unrecorded decision is a place where the codebase moved and your model of it didn’t. Next year it resurfaces as “why on earth is it built this way,” asked by someone who will get no answer.
3
The staleness test
Take one standard that names concrete technology — a deployment pattern, an approved library, an integration rule — and diff it against how that domain actually ships today. When did the standard last change? When did the pipeline last change? If the second date is much more recent than the first, you are governing a system that no longer exists.
Most architects who run this honestly fail at least two of the three. If that’s you, here is the part that matters: this is not a diligence problem, and more attendance will not fix it.
Contact, in almost every enterprise, has only ever been attended — carried by one person’s calendar, sampled at one person’s bandwidth, and lost to every promotion. Every other engineering discipline that hit this wall made the same move. Operations stopped SSH-ing into boxes to check whether the service was up, and built observability. Finance stopped trusting the till count, and kept ledgers. Architecture is the last discipline still trying to stay accurate by physically walking over.
Contact has to stop being attended and start being instrumented.
The document plane
Between the plane where direction is set and the plane where code ships, there is a missing layer of infrastructure. Call it the document plane: the layer where architectural intent — standards, specs, decisions, checks — lives in a form that whoever is writing code consumes at the moment of writing, and through which evidence flows back the other way.
A wiki is not this, and neither is a beautifully organized architecture repository. A wiki is addressed to a human who might someday visit. The document plane is addressed to the writer of the next commit, human or agent, and it has four properties a wiki never has:
1
It lives with the code. Standards and decision records are versioned in git, next to what they govern — not in a parallel system that drifts on its own schedule.
2
It reaches write time. Constraints are delivered into the coding agent’s context — and the developer’s editor — through the same protocol the agents already speak, not through evangelism and recall.
3
It has a return path. Decisions are recorded as a by-product of the work, at the moment they are made, by the same tools doing the work — not reconstructed six months later under audit pressure.
4
It knows when it’s lying. The layer continuously compares what the documents claim against what the repositories contain, and surfaces the drift — so staleness becomes a signal you receive, not an embarrassment you discover.
This is what we are building with SystemDox. Concretely: your standards — specs, architecture decision records, checks, project rules — live git-first, with GitHub as the source of truth. They are served over MCP — the open protocol that Claude Code, Cursor, and effectively every serious coding agent now speaks — so an agent working in any of your repositories pulls the relevant constraints into its context before it writes. The same connection runs backwards: agents record architectural decisions as they make them and keep specs current from inside the workflow, and repository scanning flags documentation that no longer matches the code it describes. Humans get the same knowledge as a published knowledge base; agents get it as structured context. One layer, both audiences.
What this does not fix
Honesty matters more to architects than to any other audience, so: instrumenting the document plane restores the signal of implementation contact. It does not restore the instinct.
No tool substitutes for sitting next to a developer while a deployment fails. The feel for where systems hurt is built in person, and it atrophies without practice regardless of your tooling. What instrumentation changes is the latency of discovery: the drift that today stays invisible for eight months — until it surfaces as a reputation — becomes visible in days, while it is still just information.
It also will not make a weak standard strong. It will make a weak standard visibly weak much faster — which is its own kind of uncomfortable, and exactly the point.
Start here
Run the write-time test this week. Fifteen minutes, three checks, no tooling. You will know which one is failing.
If it is reach or the return path, instrument one repository: connect it, publish one real standard through the document plane following a documentation standard agents can navigate, point your coding agents at it, and watch what comes back. SystemDox’s free tier covers one repository, permanently — that is deliberate, because one instrumented repo is enough to see whether your architecture actually reaches write time.
The ivory tower was never a character flaw. It was an instrumentation gap. Close it before it closes on you.