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.
If your organization has ended up with several systems doing the same thing, and nobody can point at the decision that caused it, the first three of these are one argument about why that happens and what an agentic model changes about it. The next two are about where the agent team itself lives, and what has to cross between there and whatever you publish. The rest stand alone: how you would know any of it is working, what an agent team can actually be handed, who owns the answer when two records disagree, and what changes once the thing you edit is the spec rather than the prompt.
The argument, in three parts
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.
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.
Standards, review boards and reference implementations all degraded the same way: each team read them differently. A shared skill removes the re-reading. It does not remove the interpretation.
Two repositories, in two parts
One public repository used to be fine. With agent teams, the thing that says how your engineers work is an artifact for the first time, and I would not expect most teams to want it published alongside the product.
The front door is public and the work is private, so reports have to cross inward. Outbound is the direction a design guards first. The inbound one carries text an agent will read as instructions.
On their own
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.
How you scope a team used to be a question about coordination cost. It now decides whether you can hand that team a specification at all, and a team you can only prompt gives you nothing to test the answer against.
Duplicate services and duplicate facts both fail quietly. The difference is that you can count the services. Nothing anywhere enumerates the facts, so the first person to find out can be a customer.
The shift is not that engineers write less code. It is that when the output is wrong, the thing you edit stops being the prompt and becomes the spec or the agent definition.
What the gaps cost ·How the work gets done ·Crinaro.AI
Written by John Kelly. If a piece of this does not hold in your architecture, at your size, that is the mail worth sending: john@crinaro.ai. Today I read it myself.