The last hop nobody wrote down
Where engineers did the final decomposition in their heads, it worked because they knew the system. An agent can read the code, but not who owns the next component, so the breakdown for each request has to be written down.
Part 2 of 3. It starts at Why do we have five user APIs.
The argument
The bridge from an outcome to the components that implement it was real work, done reliably, and invisible. It never had to be written down in order to happen.
It does now. Which means the teams that already had the discipline start ahead, and the ones running lean on it are further behind than they think.
Take an API team, working the old way. They get an epic and break it into user stories. The stories name an outcome: the API. But the outcome is delivered through changes across several components, often across several repositories, and how much of that got written down varied by team.
Some broke it down and recorded it. Others minimized documentation wherever they were allowed to. Not out of carelessness: the engineers understood the system well enough to execute without being told, and writing it down bought them nothing at the time. The bridge from the outcome to the components that implement it was real work, done reliably, and invisible.
An agent can read the code. What it cannot read is who owns the next component, or whether another team already has a version of it, because that is not in the code it is reading. Nothing fills the gap between “build the API” and the specific changes in the specific components, so the work has to be broken down to the teams that maintain those components, explicitly, in a way it never had to be before.
Take the API delivery. The new experience needs a facade layer interface, and the facade calls three domain services, so one line on the plan is four specifications for four agent teams. How many depends on the repositories and the architecture rather than on the requirement: two organizations handed the same capability will staff it differently and both can be right. Deciding team structure from the shape of the backlog means reading the wrong document.
None of those four can write the others on their own. The facade team cannot specify a domain service it does not own, and no domain team can see the whole path. Being wrong about the cut does not surface as a bad specification. It surfaces as four teams delivering exactly what they were asked for and a capability that does not work.
What that is worth, and to whom
The teams that already had the discipline start ahead. Writing down the breakdown for each request read as overhead for years, and it is now the input. That is an uncomfortable thing to tell a team that has been running lean on it.
It also changes what skipping it costs. Generation is cheap now, so a team that is not aligned to the components it touches still produces the work. It just produces it in places nobody is answerable for. That used to be limited by how much a team could write by hand, and it is not limited by that any more.