Engineering
Your agent will subcontract to other agents
Yes, and it is already standardised: over 150 organisations behind A2A in one year. An expert agent is called like a tool, provided it keeps nothing about you.
Yes, and the subject has already left the laboratory. The protocol describing how one agent calls another went from fifty to over a hundred and fifty organisations in a year, it is integrated across Microsoft, AWS and Google, and it runs in production in logistics, insurance and financial services.
What is taking shape is not a new category of software, it is a market of callable competences. An agent that needs a sharp opinion on a narrow subject will not have to learn it or integrate somebody’s tool: it will call the agent that knows, the way you phone a colleague today.
What separates a tool from an agent you call
The difference fits in one question, and it discriminates better than it looks: am I invoking a capability, or am I handing over an execution?
MCP answers the first case. A function is called, it does one precise thing, it returns a result whose shape is known in advance. That is a connection, and it is what more than eight production deployments in ten look like today: one agent, several tool servers.
A2A answers the second. You describe a goal to another agent, which decides the steps for itself, may ask for clarification along the way, and returns a result whose trajectory you never saw. Discovery runs through an agent card, a document declaring what it can do and how to reach it, which is what makes a directory possible.
That difference is not a protocol subtlety, it is the point where liability moves. A tool that fails returns an error; an agent you handed an execution to returns a decision, and it took that decision with information you will never see.
Why this does not contradict “one agent, not twelve”
We wrote recently that one well-equipped agent beats twelve that do not talk to each other, and an attentive reader might see the opposite of what precedes. The contradiction does not exist, and clearing it up means naming precisely what the problem was.
What we hold against the twelve agents is not their number, it is that each one claims to know your company. Twelve agents installed by twelve vendors are twelve copies of your rules, your clients and your history, each ageing at its own rate and diverging without ever saying so.
An external expert agent is exactly the opposite case. It does not know your company, it is not trying to, and that is precisely what makes it usable: it holds a domain, not a version of your truth. It receives a question, returns an answer, and keeps nothing.
So the criterion runs like this, and the same sentence settles both situations: an agent that holds context about you has to be unique, an agent that holds an expertise can be called as often as you like. The first is a colleague, the second is a consultant you pay by the question.
What this looks like in a staffing firm
Take identity and reference checking, a subject that turned serious once candidate fraud changed scale. Maintaining in-house the competence needed to spot a fabricated identity makes no sense for a thirty-person company, and buying it as one more piece of software makes little more. Calling it on demand, only on the files that reach signature, is the shape that matches the need.
Take posting compliance in a country where you place two consultants a year. The rules change, you do not follow them, and nobody at your company reasonably could. An agent kept current by somebody whose job it is will answer better than yours, and it will answer the question asked without needing to know the rest of your business.
Take, finally, sharp technical qualification on a stack you rarely meet. This is not automating existing work, it is access to an opinion you could not previously afford, and it is the most interesting case precisely because it replaces nobody on your side.
What the three have in common is worth keeping, because it gives the selection rule. They are expertises too narrow to internalise, too fast-moving to freeze into software, and ones you were already buying from humans when you needed them.
What the protocols do not say, and that is the point
A careful reading of recent research on these protocols produces an uncomfortable list. Neither MCP, nor A2A, nor their competitors can express seven things: the limit of a delegation, liability, revocation of a granted right, the provenance of a piece of information, consent, duration constraints, and the escalation procedure.
They describe perfectly how two agents talk, in other words, and not at all what happens when the conversation goes wrong. A successful call is well specified; a call whose result is wrong, late, or founded on data it should not have used is not.
This is exactly the reasoning we applied to MCP, and it bears repeating because the enthusiasm is identical. A shared protocol is an exit criterion, not a buying criterion: it makes connection possible and decides nothing that matters. That a third-party agent speaks your language does not tell you whether to listen to it.
Four questions to ask before calling a third-party agent
What does it see? It sees what you send, which makes the shape of the call an architectural decision rather than an implementation detail. Sending a closed question with the strict minimum, or sending the whole file so it has the context, are two different systems and only one is defensible in front of a client.
What does it keep? The right answer is nothing. A third-party agent that memorises your calls becomes one more place where your truth exists, and you know what an unwatched memory costs. If it keeps things, it is no longer a consultant, it is a subcontractor, with the contract and the register that come with it.
Who answers to the client? You do, and the technical chain changes nothing. Your service contract does not recognise your suppliers’ suppliers, and the AI Act places real obligations on the deployer even when it built nothing.
How do you cut it off? This is the forgotten question, and the only one that counts on the day of an incident. If the answer involves calling a support line or changing a configuration you do not control, you do not have a stop button, you have an intention to stop.
What it does to the price, and why that is the hard part
A third-party agent bills per call, and a failed call bills too. You are therefore adding to your cost of goods a line whose volume depends on decisions taken by your own agent, already the hardest item to forecast.
A tension with what we argue elsewhere has to be acknowledged here. We write that the price should sit on the work delivered rather than on units consumed, and a chain of agents billing per call pushes mechanically the other way, because every link wants paying for what it consumes.
Our reading is that the tension resolves through scope rather than through the pricing model. A third-party agent called only on files that reach signature represents a predictable volume and a cost you can quote; the same agent called at every hesitation becomes a line nobody can budget. The discipline sits with the caller, and it will not come from the protocol.
What we decided for Balt
Three things, all of which follow from the above rather than from an intuition about the market.
We require compatibility without building on it yet. The protocol is ready and the governance is not, so the reasonable position is to be able to plug in an expert the day one exists and is worth it, not to plug one in for the announcement.
A third-party agent receives a question, never a file. It is a constraint we impose on ourselves when writing each call, and it has a real cost in answer quality that we accept, because the alternative amounts to letting client material leave without anyone having decided it should.
Finally, nothing a third-party agent produces goes out without a person releasing it. That is the rule that already covers everything leaving the company, and the fact that the sentence was written by somebody else’s agent is a reason to keep it rather than a reason to relax it.
What comes next is the question of trust between agents: how to know that the one you are calling is who it claims to be, and what you do when two agents have acted on the same file without seeing each other. No protocol answers today, and that is where the next generation of incidents will happen.
Frequently asked questions
What is the difference between MCP and A2A?
MCP describes how an agent connects to a tool: a function is called, it returns a predictable result. A2A describes how an agent hands a task to another agent, which decides for itself how to carry it out. The question to ask of any third party is therefore whether you are invoking a capability or delegating an execution.
Does a third-party agent see my data?
It sees what you send it and nothing else, which makes the shape of the call a design decision. Sending a closed question with the strict minimum and sending the whole file “so it has the context” are two different architectures, and only one of them survives a client asking about it.
Who is liable if a third party’s agent gets it wrong?
You are, in front of your client, and that is the short answer that counts. The AI Act places substantial obligations on the deployer even when it built nothing, and your service contract does not recognise your supplier’s suppliers. The technical chain is distributed, the commercial liability is not.
Should you adopt this now?
The protocol is ready and the governance is not, so the sound posture is to require compatibility without building on it yet. Treat it as an exit guarantee, exactly like MCP: what matters is being able to plug in an expert the day one exists, not plugging one in today.
Sources
- Linux Foundation, A2A protocol surpasses 150 organizations and sees enterprise production use in first year, April 2026linuxfoundation.org
- arXiv, Governance gaps in agent interoperability protocols: what MCP, A2A and ACP cannot expressarxiv.org
- Linux Foundation, Launch of the Agent2Agent protocol projectlinuxfoundation.org
Read next
Product
Twelve agents that do not talk to each otherA company runs twelve agents on average and half of them work alone. The right criterion is not how many you have, it is how many contexts you duplicate.Vision
The end of interfaces, not the end of softwareAt Supabase, 60% of new databases are launched by an agent, and probably 90%. What is dying is not the software: it is the access layer.Product
Should you require your AI agent to speak MCP?MCP is genuinely good news, but it is not a buying criterion. It is an exit criterion: what matters is the day you change tools.
