Twelve agents that do not talk to each other

One, well equipped, in the great majority of cases. Specialisation by agent looks clean on an architecture diagram and it produces in practice what companies are seeing today: twelve agents on average, half of which operate completely isolated from one another.

The figure that makes this worrying is not that one, it is the gap between intent and result. 71 % of businesses claim to have deployed agents, and only 11 % of the use cases planned the previous year actually reached production. The difference is almost never a model problem.

Where the twelve agents come from

Nobody chose them. They arrive through software: your support tool adds one, your office suite offers another, the sales team tries a third while finance switches on their vendor’s. Eighteen months later the company has twelve and has taken no architectural decision at all.

This is precisely the mechanism that produced SaaS sprawl ten years ago, with one difference that makes it worse. An isolated piece of software is a place you go to fetch information; an isolated agent is a place where you have to re-explain your context, and the load is paid on every use rather than once at install.

The symptom is recognisable without instrumentation. The moment somebody regularly copies one agent’s output into another’s input, you are paying two subscriptions to have a human do the integration work both vendors left aside, and that person is your compatibility layer.

Why specialisation costs more than it returns

The argument for several specialised agents is intuitive: each does less, so each does it better. The intuition holds as long as you look at an isolated task, and it stops holding the moment real work starts, because real work crosses the boundaries specialisation has drawn.

An ordinary request in a staffing firm touches the talent pool, the client file, the history of exchanges and the calendar. Split across four agents, it becomes four conversations, four contexts to rebuild and four chances to lose the piece of information that mattered. The specialisation gain is real on each segment and it is smaller than the cost of the seams.

We have already written the technical version of this finding: one agent well equipped with skills matches a multi-agent architecture on the tasks where they are seriously compared. The article you are reading is its organisational version, and it is harsher, because a boundary between two agents from two different vendors is not only technical: it is a boundary of contract, billing and liability.

The right criterion is not the number of agents

It is the number of places your context is copied. Context here means everything that makes an answer relevant at your company: your internal rules, your clients, the history of what has been done, the preferences of the people working with the tool.

Every copy of that context is a copy that will age at its own rate, and you already know how the reasoning ends: bad data costs more as the agent reading it gets better. Twelve agents with twelve contexts are twelve stores that diverge, and divergence never announces itself.

There is a second cost to duplication that shows up later and hurts more. Each agent holds a fragment of what happened, so no single one of them can answer a question about last quarter, and the person who could reconstruct the answer is the one who was in every conversation. You have automated the production of records while making the record itself unreadable.

So put the question differently when you evaluate a product. Not “what can this agent do”, but “what will I have to re-explain to it that I have already explained elsewhere”. If the answer is “everything”, you are not buying a colleague, you are buying a thirteenth place to maintain the truth.

What interoperability solves, and what it does not

MCP has improved the technical situation considerably, and it deserves credit for what it brings: connecting an agent to a tool has become a standard operation instead of a bespoke development. What remains untouched is the part that costs.

A shared protocol does not decide who holds the memory, nor what rights each agent has, nor who answers when two of them have acted on the same file within ten minutes. Those three are questions of architecture and organisation, they are not solved by an exchange format, and that is why we write that MCP is an exit criterion rather than a buying criterion.

There is a structural reason fragmentation persists despite protocols. Every vendor has an interest in their agent being the one that holds the context, because context is what makes switching tools expensive. Waiting for the market to solve this spontaneously means waiting for competitors to give up their best lock-in all at once.

How to go from twelve back to three

The usual advice is to rationalise everything at once, which never happens because each agent is attached to a piece of software somebody defends. The method that works proceeds by use rather than by tool, and it fits in three steps over a quarter.

Start by listing the ten most frequent requests from your teams, phrased the way they phrase them, without translating into features. “Where do we stand with this client”, “who do we have available on this technology”, “what was said at the last review”: these sentences cross the boundaries between tools, and that is exactly what makes them useful for judging.

Then look, for each one, at how many agents you have to ask to get the answer. A request needing three is a request none of the three handles, and it points at the place where context should be shared. That is half a day’s work and it produces a far more solid ranking than a feature comparison.

Finally, keep what is legitimately separate, and there always is some. An agent confined to a narrow domain, with no access to your data and no memory, poses no fragmentation problem because it does not claim to know your company: a coding assistant or a legal drafting tool falls into that category. What has to converge is what needs your context to be relevant, and nothing else.

What we take from this for our own product

We took the view of a single agent, present where the teams already talk to each other, with a memory that is not duplicated. That is not a choice of simplicity: building an agent that crosses the talent pool, the exchanges and the calendar takes more work than shipping four specialised ones, and it shows in our schedule.

The trade-off is real and we own it. A single agent is harder to improve, because an improvement has to hold across every case rather than one, and it is less impressive in a demo than an assistant that is very sharp on a narrow task. We judged that the demo was not what mattered in the sixth month.

The question that follows is scope, and it is a fair one. An agent that crosses everything is also an agent that could do too much, which brings us back to the only limit that holds: the one written into the product rather than politely requested.