We have reached the point where we need to stop calling everything an AI agent.

For the last couple of years the recipe has been the same. Take a large language model, give it access to some enterprise data, bolt on a few tools and APIs, and announce that you have built an agent. To be fair, the results are genuinely impressive, and I am not going to pretend otherwise. We use this stuff every day. But if we are honest about what most of it actually is, it is a smarter version of Google. You ask a question, the system finds some information, the model interprets it, you get an answer. We have made search conversational, we have made it considerably more intelligent, and we have given it hands. That is not nothing. It is also not the end game.

What is starting to happen now is more interesting, and it breaks the problem in a way most organisations have not thought about yet. We are building networks of expertise.

Look at what Salesforce actually had to build

Salesforce is a useful example, because the interesting part of Agentforce is not the model. It is everything they were forced to construct around it.

Atlas evolved into an asynchronous, event-driven, graph-based architecture in which every agent is defined by state, flow and side effects, and where deterministic execution sits alongside probabilistic reasoning.¹ Their engineering team has been blunt about why: letting a model reason its way through an enterprise workflow, unaided, is not good enough. So they externalised the reasoning into design-time graphs and called the result guided determinism.²

That is a significant admission from a vendor whose marketing department would much rather talk about AI employees. The model is powerful. The model cannot be the entire system. You need structure, state, control, specialised capability, and a record of what happened. Increasingly you need a record of why it happened, which is the part almost nobody has solved.

Note also where Salesforce landed on scale. They did not build one enormous agent that knows everything. They decomposed workflows into focused subagents managed by finite state machines, with explicit handoff and delegation between them, because the single-giant-agent model falls apart under enterprise load.² That is the beginning of something much bigger than Salesforce.

Because the next step is obvious

If one agent can be an expert in something, why would anyone build one enormous agent that has to be an expert in everything? Why not an expert in release management, and another in compliance, and another in customer behaviour, and another in architecture, another in financial risk, another in security? Then let them work together.

That is the direction the interoperability protocols are already taking us, and this is worth being precise about because the two get muddled constantly. MCP handles the relationship between an agent and its tools, data and resources. A2A handles the relationship between agents, letting independent agents discover one another, delegate work and exchange results without exposing their internal implementation to each other.

A2A is also further along than most people realise. Google donated it to the Linux Foundation in June 2025, and by its first anniversary it had more than 150 supporting organisations, integration across the Google, Microsoft and AWS platforms, and production deployments in supply chain, financial services, insurance and IT operations.³ Salesforce was one of over fifty launch partners.⁴ This is not a whiteboard concept any more. It is shipping.

And once you have networks of agents, you no longer have one AI making a decision. You have a system of AIs making a decision. That is where the enterprise conversation is about to change, and in my experience most organisations are nowhere near ready for it.

So who actually made the decision?

Picture an organisation running thirty or fifty specialised agents. A customer issue arrives. One agent investigates the customer. Another pulls their commercial history. Another assesses contractual obligations, another examines operational data, another assesses risk, another checks regulatory exposure. They exchange information, they challenge each other, one delegates a question to another. Eventually something near the top of that network emits a recommendation: proceed.

Fine. Now ask the only question that matters in a regulated environment.

Why?

Not "what did the final agent say", which is trivial. I mean: what did it know, which data did it use, what version of that data existed at the time, which agent produced the information it relied upon, and what evidence did that agent use? What assumptions entered the chain? Was any of it changed afterwards? Did another agent disagree, and if so how was that disagreement resolved, and by what authority? What happened between the original evidence and the final recommendation? And can anyone reconstruct all of that in eighteen months, when the auditor asks, and the people involved have moved on?

If the answer is no, then congratulations. You have built a black box of black boxes. One opaque system is a manageable problem. A network of them making consequential decisions on behalf of your organisation is a different category of problem entirely, and it is the sort of thing that turns into an audit finding, a regulatory notification or a very uncomfortable executive conversation.

Evidence has to run through the chain, not hang off the end of it

We have traditionally treated evidence as something you attach to a decision once it is made. Here is the report, here is the document, here is the data that supports the recommendation. That is half the problem at best.

Evidence needs to exist throughout the intelligence chain. We need evidence about the organisation, and we also need evidence about the machine's understanding of the organisation, which is a completely different artefact. What information was available. What knowledge was derived from it. What interpretation was applied. What expertise was brought to bear. What conclusion was reached. What was finally done about it.

So instead of this:

Data  -->  AI  -->  Decision

the shape you actually need is this:

Evidence
   |
   v
Knowledge
   |
   v
Expertise
   |
   v
Assessment
   |
   v
Decision
   |
   v
Action

   with provenance running the full length of it

Every meaningful step needs a trail back to whatever established it. Not just the last one.

"Trained on organisational data" is doing a lot of work in that sentence

This is why that phrase makes me twitch whenever it appears on a slide. Which organisational data? From when, in what state, under which version, and has it changed since? Was it authoritative, or was it the spreadsheet somebody maintained on their own laptop until they left? Was it already an interpretation of something else?

If we are going to build machines that hold expertise about an organisation, then the organisation has to be able to establish what that expertise actually consists of. Otherwise we have inserted another opaque layer between the enterprise and its own information, and charged ourselves a licence fee for the privilege. That is not intelligence. That is just a more expensive black box.

Evidence for the decision, and evidence of the decision

There is a distinction here that I think is going to matter enormously, and it is one almost nobody separates properly.

You need evidence to make a decision. You also need evidence of how the decision was made. They are not the same thing.

Say an AI determines that a software release should proceed. The first chain tells you the code changed, the tests passed, the security checks passed, the approvals exist and the target environment is healthy. That is evidence for the decision, and most mature delivery teams can already produce it.

The second chain is the one nobody has. Which information did the system consider? Which knowledge did it rely on? Which specialist agents did it consult, what did each of them recommend, and where did they conflict? What did the orchestrator choose to trust, and on what basis? What was excluded? What was simply unknown at the time and quietly treated as fine?

That is evidence of the decision. Both matter, and as these systems take on more autonomy the second one starts to matter more than the first. When a release goes wrong, nobody is going to be satisfied by "the agent network recommended it".

The protocols do not currently carry any of this

Here is the uncomfortable part, and it is not just my opinion. A 2026 preprint by Kang and Diponegoro looked specifically at what MCP, A2A and ACP can and cannot express, and catalogued the gaps: no standardised way to express who authorised an action, no accountability chain across delegated work, no delegation or permission-inheritance semantics, and insufficient support for reconstructing why a decision was reached. Their conclusion is that these protocols were built to prioritise functional communication over governance expressiveness.⁵

That tracks with how the protocols are built. An A2A Agent Card is a capability advertisement. It is a JSON document in which an agent describes what it claims it can do, so another agent can decide whether to hand it work.⁴ It is a menu. Nothing in it tells you what the agent actually did, what it relied on, or why it answered the way it did. Discovery is solved. Provenance is not.

We have standardised how agents find each other and pass work around. We have not standardised how anyone proves what happened.

None of this means the protocols are wrong. They are doing the job they were designed for, and doing it well enough that the industry has converged on them in about eighteen months, which is fast. It means the governance layer is missing, and right now that gap is yours to fill, not your vendor's.

Which is exactly the problem we build for

We spend our time in environments where somebody eventually has to answer for the outcome. Federal and state government, IRAP-aligned and FedRAMP-aligned delivery, regulated enterprise programmes. In those environments nobody has ever been impressed that the system sounded clever. The question is always whether you can show what it did, what it relied on, and prove it was allowed to.

There is a small irony worth mentioning here. When we ran the question behind this article through our own compliance tooling, it routed straight to a provenance control. Not a novelty AI control. Provenance, which is the same control family that governs knowing where a build artefact or a dependency came from. That is the correct answer, and it is telling. We already know how to do this for software supply chains. We have registers, version traceability, artefact hashes and signed evidence, because we learned the hard way that "the build worked" is not an answer. A decision chain across an agent network is the same problem wearing a different hat, and it deserves the same discipline: know what went in, record what was derived, keep the trail, and be able to reconstruct it later without relying on anyone's memory.

So that is what we push into the things we build. Judgement in the model, rules in code, workflow in the runtime, and provenance recorded at every step rather than assembled in a panic afterwards. Not because it is elegant, but because it is the only version that survives scrutiny.

We are not building smarter chatbots

We are building machine expertise. And machine expertise needs the same things human expertise needs before anyone sensible trusts it with something that matters. A basis. A history. A chain of reasoning. Evidence.

Which means the bar moves. "Can the AI answer this?" stops being the interesting question. What does it know, how does it know it, what did it do with that knowledge, and can we reconstruct why it decided what it decided? That is a very different standard from asking whether the chatbot gave a good answer, and it is the standard we are going to need, because the number of agents is going up, their autonomy is going up, and the consequences of their decisions are going up with them.

The next generation of enterprise AI will not be defined by how intelligent any individual model becomes. It will be defined by whether we can build networks of expertise that know what they know, can show where that knowledge came from, and can prove how they arrived at a decision.

Everything else is just a very confident guess with good grammar.