An agentic mesh is five pieces of plumbing, not a product

The short version

• An agentic mesh is shared infrastructure for many agents: discovery, identity, policy, transport and audit, held in one place instead of inside each agent.
• The cost a mesh removes is not compute. It is the duplicated credentials, bespoke wiring and missing audit trail that accumulate once you have more than two agents.
• A service mesh moves requests between deterministic services. An agentic mesh moves work between components that can be confidently wrong, so recording and evaluation are part of the layer, not an add-on.
• Below about three agents, a mesh costs more than the coupling it removes.
• The first thing to build is not the mesh. It is a per-agent credential and a traced record of every tool call.

What is an agentic mesh?

It is the shared layer underneath several agents, holding the things that would otherwise be duplicated inside each one: how agents and tools are discovered, who an agent is when it acts, what it is permitted to do, how work travels between components, and what gets recorded afterwards. Five concerns, moved out of the agents and into one place. That is the whole idea.

The name is borrowed from service mesh and data mesh, and it carries the same argument. Once you have more than a couple of components, the difficult part stops being any individual component and becomes the relationships between them. Nine agents wired directly to each other is not nine problems, it is up to seventy two directed edges, each with its own credentials, its own retry behaviour and its own idea of what counts as a failure.

Nobody sells you a mesh. You can buy parts: a gateway, a tracing backend, a registry, a policy engine, a queue. The parts that matter most are decisions rather than software, such as which agent may act on behalf of which user, and what an agent is allowed to remember. Those do not arrive in a package, because they are specific to your organisation.

What problem does an agentic mesh actually solve?

It solves the questions you cannot answer after something goes wrong. Three agents in production, each with its own API key, its own retry loop and its own log format. Finance asks why last week cost four times the week before. Support asks which component told a customer their policy covered something it did not. Both questions need one ordered record across three systems, and nobody built it, because when there was one agent the answer was obvious.

The second problem is permission creep across edges. The moment agent A can call agent B, anyone who can reach A has, in effect, the permissions of B. With two agents that is one relationship somebody thought about. With six it is thirty, and whoever is deciding them is usually doing it in prompt text, where a decision is only a suggestion. A mesh exists so that the answer lives somewhere a model cannot talk its way past.

The third problem is duplicated effort nobody notices. Two teams build the same reconciliation agent. A third team calls the older one. The tool descriptions drift apart. None of this shows up as an outage, which is why it runs for months.

What are the five parts of an agentic mesh?

Discovery, identity, policy, transport and observability. Discovery is the register of what exists and what it is for. Identity is who is acting, the human or the agent, and on whose behalf. Policy is which caller may invoke which tool for which user. Transport is how work moves and what happens when a hop fails. Observability is the ordered record of what happened, including what it cost.

Most teams already have weak versions of all five, scattered across a codebase. A README is a registry. A shared service account is an identity model, just a poor one. The question is never whether you have these things. It is whether they live in one place you can change, or in nine places you have to find first.

Where each part shows up when it is missing

How is an agentic mesh different from a service mesh?

The difference is how the components fail. A service mesh moves requests between deterministic services whose errors are loud: a timeout, a 500, a refused connection. An agentic mesh moves work between components that fail quietly, returning a confident and wrong answer with a 200 attached. Infrastructure built for loud failures will report that everything is healthy while the output is nonsense.

That changes what the layer has to carry. Status codes and latency are not enough, so inputs and outputs have to be recorded, which immediately raises a retention question the service mesh never asked. Contracts are semantic as well as structural: 'returns a refund decision' is a promise about meaning, and no type checker verifies it, so the only real contract is an evaluation set that runs when either side changes.

Retries change too. Retrying an idempotent read costs a little latency. Retrying an agent that already sent the email, issued the credit or filed the ticket costs something you cannot take back. In a system of agents, idempotency belongs at the tool boundary, keyed by an action id the tool recognises as a repeat, because the layer above will retry and the model will not remember that it already succeeded.

When is an agentic mesh the wrong thing to build?

When you have fewer than about three agents running, which is most teams. With two agents, the mesh is a function call and one log table. Building a registry, a policy engine and a transport layer before that means choosing the shape of your infrastructure before you know the shape of the work, and the specifics only appear in production: which tool gets hammered, which handoff produces the bad answers, which boundary someone actually tries to cross.

Guessed infrastructure gets routed around. A platform team ships the mesh, a product team needs one thing it does not do, and within a month there are two paths for everything and the audit trail covers the quieter one.

Available budget makes this easy to get wrong in the expensive direction. Deloitte's 2025 survey of 548 decision-makers at director level or above, at organisations with at least US$500 million in annual revenue, reported digital budgets rising while investment strategies may need recalibration. Money being available is not the same as a mesh being the next thing to build.

What does the published evidence say about multi-agent adoption?

It says large enterprises expect to do more of it, and very little about what is running today. Salesforce and MuleSoft's Connectivity Benchmark projects multi-agent adoption to surge 67% by 2027, and argues that a unified architecture is key to success. The study is 1,050 IT leaders at manager level or above, at organisations with at least 1,000 employees across nine countries, surveyed in October and November 2025. It is a careful record of expectation, which is a different quantity from deployment, and the architecture argument also describes what its publisher sells. That does not make it wrong. It means the figure belongs in a paragraph about intent, not in a business case.

KPMG's Q3 2026 AI Pulse, covering 314 US-based C-suite and business leaders at organisations with annual revenue of $1 billion or more, reports confidence growing in governance, accountability and workforce adoption. Again the population is very large companies. The US Census Bureau's Business Trends and Outlook Survey, which asks about AI use across any business function, found the biggest users are firms with at least 20 employees. If you are smaller than that, the published picture is not describing you.

What nobody is measuring is architecture. The 2026 Stack Overflow Developer Survey drew 30,903 valid responses from 169 countries, with 17,464 answering its question on AI tool usage, and like every developer survey it records which tools people use, not whether anyone runs a registry and a policy layer in front of them. There is no published number that tells you whether to build a mesh. The evidence for that is your own call graph and your own incident reports.

What breaks first when agents start calling other agents?

Cost and loops, usually in the same incident. Agent A asks B for clarification, B asks A, and the pair burn tokens politely for as long as you let them. The fix is not a better prompt. It is a hop budget and a spend ceiling enforced outside the model, by whatever routes the call, because a model cannot be relied on to count its own hops.

Then shared memory. One agent writes a conclusion into a store another reads as established fact, and 'the system remembers' quietly becomes 'the system repeats'. Memory needs a writer, a scope and an expiry, decided per agent rather than per system.

Then tool descriptions. The description is the interface, so when the tool changes and the text does not, calls fail in a way that reads like model error and gets debugged as one. Treat descriptions as code: versioned and tested alongside the tool.

Then silent degradation. A sub-agent returns nothing useful, the caller summarises anyway, and the answer arrives fluent and empty. Every handoff needs a way to say 'I have nothing', and every caller needs to treat that as a result rather than as prose to paraphrase.

How do you move towards a mesh without building one?

One concern at a time, starting with whichever one cost you money or credibility most recently. Each of the five parts can begin as something small and unglamorous that takes an afternoon, and the small version tells you whether the real version is worth building.

After a quarter of that, the parts that need real infrastructure are the ones you keep working around by hand. That list is usually shorter than five, and which items are on it depends on your own system, which is the reason to find out rather than assume.

Where to start

1. Give every request a trace id that survives handoffs, and write one log line per tool call. A single table is enough to begin with.
2. Give each agent its own credential instead of the shared service account, so the audit log names something more specific than the application.
3. Put tools behind one gateway, so the permission check happens in a place a later feature cannot forget.
4. Write the registry as a file in the repository: agents, owners, tools, and who may call whom. A list somebody maintains beats a service nobody queries.
5. Make every tool that changes the world idempotent, keyed by an action id, so a retry at any layer above is safe.
6. Report cost and failure per edge rather than per system, because the edge to fix first is the one that is actually expensive.