Four Developers Was Easy. Six Teams Was Not.
Part 3 of an ongoing series on building an agentic engineering practice.
The previous piece described artifacts: numbered capabilities, machine-validated architecture records, blueprints with guardrails. Read on its own, it looks like a lot of apparatus for building software.
A fair question at this point is whether any of it is necessary for one person working alone. The answer is that the artifacts are — an agent invents whatever you did not write down regardless of how many colleagues you have, and a specification steers a machine just as much at n=1. What one person does not need is everything built around the artifacts: negotiating shared vocabulary, defining who owns which record across six functions, defending a convention against someone else's equally reasonable one, rolling anything out to anyone.
That second layer is what this piece is about, and it is worth being explicit about the direction it travels. A practice built for forty people works fine for one. A practice built for one does not survive forty. So the harder case is the one worth designing for, and it is the case almost nobody writes about — most published accounts of working with agents are accounts of one person's workflow.
The pilot was a forgiving environment
The pilot was four developers in an alpha team. It produced the numbers, and it established that the effect was real. It established very little about the scale-up, because a small self-selected group working closely on one platform is a forgiving environment: they talk constantly, they correct each other in passing, and any drift gets caught in a conversation nobody needs to record.
Then it goes to the whole engineering organisation. Six teams, several products, people who did not volunteer, people who have maintained parts of the codebase for years and hold well-earned opinions about how it should be treated.
Here is the failure mode, and it is not the one you expect. Nobody does anything wrong. Every person applies a reasonable interpretation. But "write a good specification" resolves to six different things across six teams, all defensible, none identical — and with agents in the loop, each of those interpretations produces working, plausible, shipped code. The divergence does not announce itself. It shows up months later as a codebase that looks like it was built by six companies.
One person's inconsistency is visible to the person causing it. Six teams' inconsistency is visible to nobody until it collides.
So the standard has to stop being something each person holds and become a single shared object. That is what the artifacts do here that they do not have to do at n=1. A requirements document is the standard for what "specified" means, made inspectable. A blueprint is the standard for what "planned" means. An architecture record is the standard for what "decided" means. Their organisational function is that two people can look at the same thing and find out that they disagree.
It could not stop at engineering
This is where most agentic tooling stops, and it is why most of it stays a productivity aid.
Agentic tools are sold to developers. But if the specification is now the machine interface, then product management is inside the system, not upstream of it. Acceptance criteria that a machine can fail are written by product people. Design does not hand over screens to be interpreted charitably: the design record is derived from the prototype the product manager already validated, and design signs it off. Architecture answers for the architecture record and the blueprint, which means an agent that hits an unplanned decision hands control back to a person rather than resolving it. Quality moves from testing after the fact to putting the test strategy into the plan before anything is built. Documentation is a completion condition, and a missing decision record is a finding rather than a gap.
Worth noting what the marks in that chart do and do not mean. Agents draft most of these artifacts. The filled marks show who answers for the result, which is a different thing and the more important one. Six of the eight steps stop until a person decides.
Six roles, one chain, one set of definitions. Getting engineering to adopt a new working model is a project. Getting product, design, engineering, quality and documentation to adopt the same working model, with the same vocabulary, at the same time, is a different order of difficulty — and skipping it is why so many organisations end up with fast developers waiting on the same slow, ambiguous inputs as before.
A practice that only changes engineering has moved the bottleneck, not removed it.
How it actually spread
Not by announcement. The alpha team was the mechanism: those people went back into their own product teams afterwards and carried the practice with them through structured workshops, as the first practitioners rather than as messengers.
That distinction matters more than it sounds. A rollout led by people who have not done the work produces compliance. A rollout led by the four people who spent two months finding out where it hurts produces argument, which is slower and considerably more durable. They could answer the objection "that will never work on our codebase" with a specific counter-example, and sometimes with agreement.
The condition nobody states
There is one property without which none of this survives contact with an organisation: the process has to cost what the work is worth.
A practice that charges the same ceremony for a two-line fix as for a new capability will be abandoned, and it will deserve to be. Not because people are undisciplined — because they are right. The exception is genuinely justified, everyone in the room knows it, and after the third justified exception the practice is decorative.
So the depth is not fixed. Requests are classified at intake by type and size, and the classification determines how much of the chain runs. Small, well-understood work goes through a short lane: described, classified, built, gated, done. No requirements document, no architecture record, nothing that exceeds the change.
What is not optional is the classification. Something has to have decided which lane this is, and that decision has to be visible afterwards. The failure we design against is not "a small change shipped quickly." It is "nobody can now tell which of those this was."
And the honest part: this is the least finished thing in the whole system. Adaptive process depth is a property we have partially, not fully. The lane model works at the extremes and is vague in the middle, which is exactly where most real work lives. It is the largest open item on our list, and I would rather say that than present a maturity we have not reached.
Where this goes
Everything above is still agreement. Shared artifacts, shared vocabulary, a lane model people accept as sensible.
Agreement decays. Not dramatically, and not through bad faith: through a hundred locally correct decisions under time pressure, each one reasonable, until the practice describes what people used to do.
The next piece is about what happens when you stop asking.