Why do we have five user APIs
Nobody ever decided to build the same component five times. Projects have goals, and maintaining the platform is not one of them, so the system ends up being whatever the projects left behind.
The argument
Deliver the project, or look after the system. The conflict is old, and it resolves the same way, because the project has a goal and a date and the system has neither.
Agents do not resolve it by themselves. Every agent team is scoped to a component, so an organization that never settled who owns what has taken the brake off rather than slowed anything down.
The question gets asked two years on, and it always has that shape. It is worth understanding where it comes from, because it is not incompetence and nobody ever decided it. In my career it has come from two places, projects and acquisitions. Both leave the same shape behind, and this note follows the project.
We had projects, and a project has a goal. It is funded to deliver that goal, it is measured on that goal, and maintaining the platform underneath is not on the list. That is not a criticism of projects. It is what a project is for.
So the project defines the system it needs in order to reach its goal, the team stands that system up, and when the project ends the team is left owning the whole of what it touched, because that is what got defined. Run another one next year, with a different goal and a different team, and you have two.
Each of those was a reasonable decision. Every project was right locally. Nothing in the process was capable of noticing that the thing being asked for already existed somewhere else, because nothing in the process was looking at the whole. That is Conway's law read as a diagnostic rather than as advice: the duplicates are the communication structure of the teams, made visible.
The correction sits above team design
Systems thinking, enterprise architecture in the old sense of the phrase, is what defines the system architecture, and the architecture is what defines the breakdown into teams. The order matters: teams downstream of the architecture, not the architecture downstream of whoever shipped last.
A cadence still carries the communication across the organization, and it has to hold. But it is not what decides this. What the teams inside it are aligned to is.
What agents change, and it is not what people expect
This is the part I would not treat as history. Agents do not fix an ownership model and they do not break one. They amplify whichever one you already have, so the question is only ever which one that is.
And the amplification is not even-handed, which is the part worth sitting with. A team that needs a component changed has two ways to get it. Ask the team that owns it, or build its own. Both just got cheaper to do. Only the first still ends in front of somebody who can say no, because the review standing between a team and its own second copy sits inside the team that wants it, run by the people taking the cheaper option today rather than by whoever carries the bill later.
So what was holding the estate's shape was never only the architecture. It was partly how much any one project could afford to build for itself, and that is the part agents relax. The conditions that produced five user APIs are unchanged. What has changed is how quickly they can produce the next five, and nothing in that mechanism prefers a good ownership model to a bad one.
Set up the other way, the same property is the fix. A team that owns an asset and expects to still be answerable for it next quarter behaves differently from a team assembled around an initiative, and an agent team is the most literal version of that there has ever been: it is scoped to the component whether anybody writes the ownership down or not. The only question is whether the organization chose the scope or inherited it.
The question worth asking
One question, asked at the organization level rather than the team level. Does it make sense for this system to have more than one of these?
If the answer is yes, there is no issue and nothing should block. Bounded contexts are a perfectly good yes, and forcing one canonical model is its own well-documented mistake. If the answer is no, the duplicate is not the problem. It is where the problem became visible. What I object to is the case where nobody asked.
One thing this does not do, and it matters more than it looks. Getting ownership right contains the problem: it stops the sixth user API being created without anybody deciding to. It does not remove the five you already have. That is remediation, it is its own funded work, and it will not happen inside the project that noticed it, because that project has a goal and this is not it. Anybody telling you the alignment fixes what you already built is selling you something.