Your company runs twelve AI agents. Half of them work alone

Here is the most quietly damning statistic of 2026: the average enterprise now runs about twelve AI agents, and roughly half of them work alone.

Not "work badly". Work alone. Each one has its own context, its own credentials, its own memory of what happened, and no way to tell the other eleven anything. The support agent does not know what the sales agent promised. The scheduling agent cannot see the invoice the finance agent just raised.

If that arrangement sounds familiar, it should. We spent the 2010s building exactly the same thing out of SaaS subscriptions, and we called it the integration problem.

How you end up with twelve

Nobody plans this. It assembles itself, one reasonable decision at a time.

Support buys a helpdesk with an AI resolver included. Sales gets an agent bundled into the CRM at no extra cost. Marketing trials a content tool. Someone in operations wires up a workflow automation over a weekend and it quietly becomes load-bearing. Every one of those was individually justified, cheap, and fast to show value.

The bill arrives later, and it is not the subscriptions. It is that the context is now scattered across twelve systems that cannot read each other, and the only component that can see all of it is a human being copying between tabs.

The tax you are already paying

Three costs, in the order people notice them.

Duplicated context. Every agent needs to be told who the customer is, what they bought and what went wrong. Twelve agents means twelve places that fact is entered, drifts and goes stale. The version in the helpdesk and the version in the CRM disagree by Thursday.

No shared memory. An agent that resolved this exact issue last month cannot tell the one facing it today. Each conversation starts from zero, which is precisely the thing these tools were bought to stop.

Humans as middleware. The most expensive outcome. Your team becomes the integration layer — reading one agent's output, judging it, retyping it into the next. That work is invisible on any dashboard and it is where the promised savings quietly go.

Why it is happening now

Two forces, pulling in opposite directions.

Adoption got very fast. Ninety percent of professional developers now use AI coding agents at least weekly, and 68% daily. Agents moved from demo to workflow inside about eighteen months, and procurement moved faster than architecture — which is the normal order, and the reason the mess is normal too.

Meanwhile the fix arrived, but later. The Model Context Protocol has become the common standard for connecting agents to systems, with over 9,400 public servers and support from every major provider. The plumbing to make agents share context now exists. Most estates were assembled before it did.

So the gap is not technical any more. It is that nobody owns the estate.

What actually fixes it

The unwelcome news is that this is an old problem in new packaging, which means the old answers apply. They are less exciting than the tools that created the mess.

Name a source of truth per fact. Not per system — per fact. Where does "current subscription status" live? One place, and every agent reads it from there. Most estates cannot answer this question for their five most important facts, and answering it is most of the work.

Give agents identities, not credentials. An agent sharing a human's API key is unauditable by construction. When something goes wrong at 2am you need to know which agent did it, acting for whom, under what permission.

Standardise the connection. One server per system, spoken by any agent, is what MCP is for. It also means swapping a model or a vendor stops being a rewrite — and given how fast this market moves, that optionality is worth more than any individual tool.

Start with reading. Let agents share context before you let them act on it. The audit trail is cheap to build while the stakes are low, and impossible to add calmly once an agent is issuing refunds.

Treat them as services

The mental shift that helps most: stop thinking of agents as assistants and start thinking of them as services.

Services have owners. They have interfaces you can depend on, versions, permissions, and logs. When one misbehaves you can tell which one it was. None of that is novel — it is how we have built distributed systems for twenty years — and it is what agents are, whatever the marketing calls them.

We came at this from the product side rather than the enterprise side. Building Reword AI, we chose to have requests go from the browser straight to the model provider, never through our servers, because a tool that reads whatever you have selected on screen should not add another party to the transaction. The decision was about privacy, but the useful part was the discipline: being explicit about who holds the data and who is in the path.

Draw that boundary once, on purpose, and most of the awkward questions answer themselves. Leave it implicit across twelve agents and you will be reconstructing it during an incident.

Before you add the thirteenth

One exercise, and it takes an afternoon.

List every agent running in your business. For each one, write down what data it can reach, whose permissions it uses, and where its output goes. Then find the facts that appear in more than one row.

Most people are surprised twice: by how many agents are running, and by how much of the list is one person's weekend project that everything now depends on. That list is your architecture. It is worth having written down before it gets a new entry.