Yes, technically, and it is already common. Agents from different vendors can exchange tasks through shared protocols, APIs or a common work queue. Doing it safely is the harder part. Each vendor brings its own permission model, and the gaps between them are where authority leaks. One layer above all of them has to hold identity, limits and the record.
Why is the technical part the easy part?
Agents talk through ordinary interfaces. One agent posts a task with inputs; another picks it up and returns a result. Open message formats for agent-to-agent exchange exist, and where they do not, a shared work queue with a clear task schema does the same job. Getting a screening agent from one vendor to accept a case from an onboarding agent built by another is an integration project, not a research problem.
What no protocol settles is whether the receiving agent should act on what it was sent. A message from another agent is a claim. It arrives with whatever confidence the sender had, which may rest on facts the receiver cannot see.
Where do multi-vendor setups go wrong?
Three failure patterns recur.
Mismatched permissions. Vendor A's agent may be configured to approve refunds up to a limit. Vendor B's agent may have no concept of limits at all. When A asks B to "complete the refund", B's settings decide, and B's settings were never designed with A's in mind.
Laundered facts. Vendor A's agent reads a customer email claiming a new bank account. It summarises this as "customer bank details updated" and passes it on. Vendor B's agent now holds what looks like a settled fact. The external origin has disappeared in the handoff.
Split records. Each vendor logs its own part. Reconstructing why money moved means stitching together several logs in different formats, with different clocks and identifiers, and hoping nothing fell between them.
What should each agent do, and what stays with a person?
| Activity | Agents may do | Stays with a person |
|---|---|---|
| Pass a task to another vendor's agent | Yes, through the governed layer with a task id | Deciding which vendors' agents may exchange work at all |
| Act on another agent's output | Only within the receiver's own certified depth | Anything the receiver is not certified for |
| Change customer data on another agent's say-so | Draft the change for review | Approving changes that arrived from outside |
| Move money based on a chain of agents | Prepare the payment | Releasing it, unless the receiver is certified at depth 4 and the facts are not external |
| Resolve a disagreement between vendors' agents | Flag and hold | The decision |
What does this look like in a bank?
Take a bank using one vendor's onboarding agent and another vendor's sanctions-screening agent. The onboarding agent collects a business customer's documents and posts a screening task. The screening agent returns "no match" with a reference.
Under a governed layer, that result arrives stamped with its source: which agent produced it, under which certificate, from which list version. The onboarding agent may record the result and move the case on, because recording a screening result is within its role. It may not open the account if the screening agent's certificate has lapsed, because the platform checks that before the next action. And if the screening agent returns a possible match, neither agent decides. The case is held for a named analyst.
For an EU bank, both vendors are ICT third-party providers, which brings obligations covered in the EU AI Act and DORA together for AI agents in banks. UK firms face a parallel set, set out in UK GDPR and FCA rules together for AI agents.
What does the platform layer have to do?
- Give every agent its own identity, regardless of vendor, so each action is attributable.
- Route every cross-agent handoff through one point that checks the receiver's bounds before it acts.
- Carry provenance across the handoff, so a fact that started as a customer's unverified claim is still marked that way three agents later.
- Keep one record, with one task id spanning every vendor's part.
- Apply the lowest bound. If vendor A's agent may act at depth 3 and vendor B's at depth 2, the joint action runs at depth 2.
The principles behind this are set out in how multiple AI agents work together safely, and the wider design in the governed agentic operating system guide.
Questions people ask
Do agents from different vendors need to use the same model?
No. The model behind each agent is that vendor's choice. What has to be common is the layer that checks actions and keeps the record, not the model that proposes them.
Can we make one vendor responsible for the whole chain?
You can contract for it, but accountability for the outcome stays with your business. A single vendor's assurance also covers only its own agents, not how they behave when another vendor's agent feeds them.
Is it safer to buy every agent from one vendor?
It reduces integration work and splits records less. It does not remove the need for limits, holds and evidence on your own cases, and it ties every capability to one vendor's roadmap.