You Automated the One Moment Your Architecture Was Ever Handed to Anyone.

Two new engineers joined my team over a three-week window, and one of them, Ethan, could not get his development environment running without sitting on calls with one specific senior engineer. It turned out there was not one correct environment; there were several. Front-end developers worked against a shared dev server, and backend developers ran the full stack locally, even for front-end work. Neither group knew the other's approach existed.

The documentation was not wrong. That is the part that took me a while to see. It described an architecture the team itself had never fully agreed on, so there was nothing to correct and nothing missing that anyone could have written. Ethan was not looking at a documentation failure. He was looking at the gap between the system as documented and the system as actually lived, and he could see it only because he had not adapted to it yet.

Then he did the thing that made the whole episode useful: he offered to document the environment he had built during onboarding, take it to the team, and hold them to a sanctioned version. The person with the least history on the team found the problem, and then supplied the fix.

Your agents are in Ethan's position permanently, and they will never do the second half.

The conventional response to a bad agent contribution is supply. Write a better rules file, add a repository index, point retrieval at more of the codebase, wait for a larger context window. Every technical leader reading this has answered a bad result by improving the prompt, and it works often enough to keep them doing it. The assumption nobody examines is that the missing thing was written down somewhere to be supplied. You cannot retrieve an agreement the team never made.

So the agent receives everything explicit, produces work that is locally correct and architecturally naive, and the team sends it back. The obvious objection here is memory, and it deserves a direct answer: agents persist context across sessions now, through rules files, project instructions, and extracted memory stores. Every one of those carries what somebody wrote down. None of them carries what nobody ever decided, and Ethan's environment split was the second kind. Nobody ever put a line item on a new engineer learning which environment was the real one, which is part of why the loss has never shown up anywhere.

The real difference was never memory. Ethan could not get his environment running, so he went and sat on calls with a senior engineer, and that question was the transmission event. An agent in the identical position produces something plausible and moves on. A confused person generates a question; a confused agent generates output, at a volume that does not decay. Call it The Foreman: a bureaucrat-architect in a hard hat with a wrecking ball marked Day One, rebuilding the same structure from the ground up every time, not because he forgot but because he never asked what the foundation was for.

The shadow state surfaces when somebody crosses into an area they have not worked in, or have not touched in a year. They hit the gap, they ask, and somebody explains why the obvious approach is wrong. That is how the implicit architecture has always moved, continuously, across the whole team rather than only at onboarding. It is also the exact situation now most likely to be handed to an agent, because not knowing an area is the canonical reason to reach for one. The transmission occasions are not being displaced as a side effect of volume; the most valuable ones are automated first, because unfamiliarity is the trigger for both.

The cost lands in two places at once. Review is the compensating control, and it only works when the reviewer holds the shadow state in their own head, so every contested contribution routes to the few people carrying it while agent output scales freely and their capacity does not move. That is a queue. The second cost is worse and slower: review comments were one of the channels the reasoning traveled through, so spending that capacity on volume starves the thing it was also teaching.

The leaders who hold onto their architecture through this are not using fewer agents, and they are not more disciplined about documentation. They stopped treating unfamiliarity as a routing problem and started treating it as a signal.

What the codebase needs is a Train Plan, which is a term I named for a week when a team member was hit by a train hours after his wedding and almost nothing he carried could be picked up by anyone else. What that team built was not a list of what the systems did. It was a record of how decisions had been reasoned, because that was the only part actually missing. Same distinction here: the shadow state is not undocumented facts, it is unrecorded reasoning, and a document of what will never contain it.

Make it a contested-ground register and it stays small enough to finish. One line per area where the team holds an unwritten answer: what the obvious approach looks like, why it is wrong here, and what was actually decided. Start only where the shadow state has already caused a visible failure. The register then sets the threshold on its own, so the decision is made in advance rather than in the moment: a crossing into registered ground routes to a person, and everything else runs at full agent volume with no ceremony. Those are different categories of work, not fast and slow versions of the same one.

Take the last agent contribution somebody on your team sent back, and ask exactly what was wrong with it. If the objection was written down somewhere, this is a supply problem and more context genuinely fixes it. If it was not, a person's memory is load-bearing infrastructure and nobody has ever said so out loud. Then list the last three times somebody handed work to an agent because they did not know that area, and ask what each of them would have learned by doing it themselves. That is what you spent, and it appeared on no invoice.

The LeadershipOS™ book has the full Train Plan ritual this article only points at, including how to capture reasoning rather than outcomes so it survives the person who holds it: http://TheLeadershipOSBook.com