Count the repetitive changes, not the repositories

If your agent teams are working, one change the business asks for touches fewer places over time. This is how you would know, and the number the argument most naturally suggests is the wrong one.

John Kelly  ·  5 September 2026

The home page states the measure and stops there: if your agent teams are working, the number of systems you have to change to deliver one thing the business asked for goes down. This is what sits behind it, and the first thing it needs is a distinction: the places that count are the ones somebody has to keep in agreement by hand. What follows is not a measurement. It is the pair of numbers that would tell you whether the agent teams are working.

The number that makes somebody ask

What a company has to spend on maintenance and on critical customer defects is already on somebody's desk. Nobody has to be persuaded it matters, and when it climbs the explanation is rarely to hand. That is its whole strength.

It can also be explained by scale, by age, by regulation, and by having more customers than last year. So on its own it cannot be attributed to duplicated work, and reading a rising maintenance line as evidence of it is picking one explanation from several that fit. The lagging number is what makes somebody ask. It is not what answers.

The number that can answer

The instrument is how many changes have to be made in the system for the same functional change. One behavior, asked for once. Count where it has to land, and note who owns each place, because three edits inside one team's remit is not the same cost as three across three backlogs.

That is deliberately not a count of repositories, and the reason matters more than the instrument. The same estate arrives at the same repository count by several different routes, and creating something new can be the correct call even where ownership is exactly right. It is the count the argument seems to suggest, and the first one to reject. A repository count answers a question nobody asked, and answers it confidently.

The distinction that makes it an instrument rather than a complaint

A capability that spans a frontend, a service and a schema is distributed work: three different edits composing one behavior. Three means nothing bad. A capability where the same decision has been worked out separately in four places is duplicated work, and four is the cost.

The test is not how many places. It is whether they have to be kept in agreement by hand. A rule written down once and enforced at three layers because each layer has a different job costs nothing when it changes, and validating in a browser and again in a service is exactly that: not waste, and not one thing done three times. Four teams that each arrived at their own version of a pricing rule have four places to find, and somebody has to find all four.

Same number, opposite meaning. Any dashboard that counts touched systems without making that distinction is measuring your architecture and calling it waste, and it will be believed because it has a number on it.

Why this is cheaper than it sounds

The judgment the instrument needs is already being made. A team breaking a request down knows, at the moment it does so, which of the items in front of it are the same work repeated. That is narrower than knowing what already exists somewhere else in the estate, which nothing in the process is looking at and which is a different problem. It is still the judgment this needs, and nothing on the artifact has anywhere to put it, so it is made and thrown away.

One field on a decomposition record is the whole instrument. Not a program, not a dashboard, not a new practice. A place to write down something somebody already knows.

And it stays honest only while nobody is judged on it. The field goes up precisely when a team built its own copy rather than going to ask another team to change something, which makes it a confession written by the person confessing. Attach it to a review, or carry it up as a team target, and distributed becomes the answer to every question. The number goes flat and the duplication continues underneath it. It is worth reading across an estate, by somebody who is not deciding anybody's year, and it is worth nothing as a target.

It also assumes there is a decomposition record at all. The note on the last hop argues that some teams minimized documentation wherever they were allowed to, and that the breakdown historically lived in an engineer's head. Where that is still true this is not cheap. That agents need it written down at all is the first reason to start; this is the second.

Version control can tell you what changed together, afterwards, with nobody filling in anything. That is worth having and it is a different instrument: it records what did change together and cannot tell you whether it should have. This one is filled in before the work, by the only people in a position to know.

Two shapes, and I am not going to tell you which arrives first

Several services implementing the same behavior is one shape, and it is visible from inside engineering. Several end-user systems needing the same change is the other, and it is visible from outside, because watching one feature ship three times needs no access to any code.

Which of the two gets noticed first is not something anybody here has counted. It reads as though it has an obvious answer, which is exactly what a frequency claim looks like before somebody checks it.

What is not known. Both numbers together would show whether the agent teams are working. Neither shows what that is worth. There is no cost model behind any of this, so this says what to watch and prices none of it. And the outcome itself remains unmeasured: the instrument is what would test the claim, not evidence that it holds.