Conway's Law Came for Your Agents

Somewhere in the next few weeks, someone is going to ask you to approve an agent.

It will be a good ask. A named team, a real workflow, a slide with a number on it, a sponsor who has clearly done the thinking. On its own merits it deserves a yes, and if you judge it on its own merits you will give one.

Here is the question I would want answered first, and I have not yet watched a room answer it quickly. How many agents does this organisation already run, who owns each one, and which of them is still doing the job it was built for?

If that takes a week to assemble, you are not approving anything. You are adding to a pile nobody has counted.

The research landed in a cluster this year, and it says roughly the same thing from four directions.

OutSystems surveyed close to 1,900 global IT leaders between December 2025 and January 2026. Ninety-six per cent already run AI agents in some form. Ninety-four per cent say sprawl is increasing complexity, technical debt and security risk. Twelve per cent have a centralised platform to manage any of it. Thirty-eight per cent are mixing custom-built and pre-built agents in the same estate.

The SAP LeanIX Agentic AI Survey 2026 found 98 per cent of companies have deployed agents or plan to, and fewer than half have visibility into an inventory of them.

Gartner's estimate, published on 28 April 2026, is that by 2028 the average global Fortune 500 enterprise will have more than 150,000 AI agents in use, against 13 per cent of organisations who believe they have the governance to manage them. Max Goss, senior director analyst at Gartner, put it to a London audience in April as an "ungoverned sprawl of agents" exposing organisations to misinformation, oversharing and data loss.

The part we miss: read together, those four numbers are not about adoption. Adoption is fine. Adoption is close to universal. What is missing is the register: the list of what exists, who owns it, and what it is allowed to touch.

One caveat I would rather state than have you notice. OutSystems sells an application platform, SAP sells an AI governance product, and Gartner sells the advice. Every organisation telling you that you have too many agents is also selling you the console that counts them. That does not make the numbers wrong. It does mean the framing arrives pre-shaped, and you should read the finding rather than the conclusion.

Your agent count is not climbing because agents are cheap, although they are. Owning one has become the price of being a team.

Melvin Conway published "How Do Committees Invent?" in Datamation in April 1968. The thesis, in his own later summary of it, is that any organisation designing a system will produce a design whose structure copies the organisation's communication structure. Software has quoted that back at itself for nearly sixty years, usually to explain why the microservice boundaries follow the team boundaries.

The line from that paper I keep returning to is a different one. Conway names the commonest factor behind badly designed systems as "the availability of a design organization in need of work."

That is your agent estate. Not a technology failure. A structural one, and an old one, arriving in new clothes.

Clare Liguori, a senior principal engineer at AWS working on agentic AI, made the same observation on Dev Interrupted in August. Andrew Zigler's write-up of that conversation opens on it directly: every engineering team wants to build its own custom agent, when what the organisation may actually need is a standardised skill or a stateless MCP server. Her position, and it is worth sitting with, is that stripping away heavy custom scaffolding is how enterprise AI scales.

Which turns it into an argument about who gets to own what.

Every team wanted its own dashboard. Every team got one.

Then every team wanted its own alerting, on its own thresholds, with its own definition of what "down" meant for its own service. Nobody said no, because each request was reasonable and the cost of each one was small. The cost of all of them together was a decade of consolidation programmes, an unreadable operational picture during incidents, and a bill that arrived long after the people who approved it had moved on.

I have watched exactly this on a government digital-services engagement. The complaints came from the public, about one low-volume service, while every dashboard showed green. The monitoring used global auto-baselining, so the low volume of that service meant the failure was never picked up. The SRE team tracked it down by hand, then put up a very awful temporary dashboard of just 400s and 500s to start seeing where the monitoring gaps were.

The numbers came off that dashboard. Of 49 major services, about 7 per cent were failing regularly. Some ran only 10 to 20 times a day, or once a month, but sat inside longer journeys. It was the 500s, not the 400s. One service had been throwing them under the radar for 17 days, with no events on the floor, because the dynamic baselining never fired.

The mechanism is identical here. Individually rational requests, every view green on its own terms, and no owner for the total. What has changed is speed and blast radius. A dashboard nobody reads is clutter. An agent nobody owns holds credentials, calls tools, and takes actions in systems that have consequences. SAP's own framing of sprawl is worth borrowing because it is precise: agents created, deployed or connected faster than the enterprise can inventory them, assign ownership, control permissions, monitor behaviour, and retire them when they stop being fit for purpose.

Retire them. That is the verb that matters, and it is the one nobody has budget for.

The case for shared skills over per-team agents has mostly been made on intuition. It picked up a piece of actual data last month.

Shuyan Huang, Kai Du and Andrew Lan published a study on 10 August 2026 covering 206 real developer-agent sessions across 13 developers, testing whether skills personalised to an individual developer outperform generic ones. They did not. Personalised skills delivered small and inconsistent gains over no skills at all, while generic skills pooled across developers produced the largest and most consistent improvement.

Be careful with that, and I want to be honest about the gap rather than let it pass. That study is about individual developers and coding agents, not about business teams and production agents, and 13 developers is a small sample. It does not prove that your marketing team's agent should be a shared skill. What it does is put a crack in the assumption underneath every one of these requests, which is that proximity to the problem justifies owning the tool. Sometimes it does. The evidence we have says it does so less often than the person asking believes.

The practical move is an audit, and it is genuinely dull. Name every agent that is live. Name its owner, by person rather than by team. Record what it can reach, what it has actually done in the last ninety days, and what happens if it is switched off tomorrow.

Most organisations will find three things in that exercise. A handful of agents doing real work. A long tail doing nothing measurable. And at least one that nobody present can confidently say who owns, which is the one you want to look at hardest.

Tidiness is the least of the reasons to do this. Every question you will be asked later depends on the answer. Which agent touched that record. Who approved its access. When did anyone last review it. Whether it can be stood down without breaking something else. None of those questions can be answered retrospectively from a system that was never inventoried, and all of them get asked on the worst possible day.

I wrote recently about where the gate actually lives in an autonomous system, and about what a leader is signing when they switch a run mode on. This is the layer underneath both. A gate on an agent you cannot enumerate is a control over a subset you happen to know about.

This is not an argument for centralising everything, and the failure mode of the argument is worth naming as clearly as the argument itself.

Goss makes the point in the same Gartner commentary: organisations that respond to sprawl by blocking or restricting agents usually get shadow AI instead, which is strictly worse, because the estate still exists and now you cannot see any of it. A consolidation programme that reads as a ban will produce exactly that outcome, and it will produce it quickly.

So the test is not ownership, it is difference. A team should own an agent where its workflow, data or risk profile is genuinely unlike anything else in the organisation, and where the shared platform would have to be bent out of shape to accommodate it. Where the difference is really just preference, or a reasonable wish to not queue behind another team's roadmap, the answer is a skill or a tool that the shared platform picks up. That second case is far more common, and it is usually solvable with capacity, not architecture.

I could be wrong about the proportions. I am not wrong that almost nobody is asking the question.

Ask for the register. Not a project to build one. The current state of it, this week, however incomplete, because the incompleteness is the finding.

If somebody can hand you a list of live agents with named owners and a last-reviewed date, approve the new one on its merits and enjoy working somewhere unusually well run. If nobody can, then the request in front of you is not really a request about one agent. It is the organisation asking you to sign for a total that nobody has added up, and you are the person whose name goes on it.

Conway's point was never that structure is destiny. It was that structure is a choice you make early, usually without noticing, and then live inside. The agent estate is being designed right now, in approval meetings, one reasonable yes at a time.

Somebody should be counting.