Multiple agents work safely together when each has a narrow role and its own identity, every handoff passes through one governing layer, and no agent can approve another's work where your controls require separation of duties. Each action meets the acting agent's own bounds, however it arrived. People keep the irreversible steps and the decisions where agents disagree.
What changes when there is more than one agent?
With one agent, risk sits in what that agent does. With several, risk also sits in the gaps between them: what one passes to another, who trusts whose output, and who is accountable for the combined result.
Three new failure modes appear. Errors spread, because one agent's mistake becomes the next agent's input. Authority leaks, because an agent with narrow rights can ask one with broader rights to act. And accountability blurs, because no single agent did the harmful thing; the chain did.
Which controls address which risks?
| Risk | Control |
|---|---|
| One agent's error spreads downstream | Receiving agents treat other agents' outputs as claims with a source, not settled facts |
| A narrow agent uses a broad one to act | Delegated work runs at the lower of the two agents' authority |
| The same person-equivalent drafts and approves | Separation of duties enforced between agents, not just between people |
| Agents pass work in circles | Limits on hops, retries and re-opening tasks |
| Nobody can reconstruct what happened | One task id across every agent, one append-only record |
| A faulty agent keeps working while others depend on it | Drop its depth at once; downstream agents see its outputs held |
| Agents from different builders behave inconsistently | One governing layer for all of them |
That last row applies when agents come from several suppliers, a case covered in whether AI agents from different vendors can work together.
What should agents do, and what stays with a person?
Agents should each do one role well: capture, match, prepare, check, draft. They may hand work to each other through the governing layer and act on each other's outputs within their own bounds.
People should keep three things. First, any step that cannot easily be undone, such as releasing a payment or closing an account. Second, decisions where two agents reach different conclusions. Third, the design of the chain itself: which agents may pass work to which, and at what depth.
What does this look like in an accounts payable team?
Take a mid-sized distributor running three agents in accounts payable. A capture agent reads incoming invoices and extracts the fields. A matching agent compares each invoice with its purchase order and goods receipt. A payment-prep agent assembles approved invoices into a payment run.
The capture agent's output reaches the matching agent stamped as extracted from a supplier document, which is external. The matching agent may match within tolerance at depth 3. It may not accept a changed bank account that appears on an invoice; that is held for a person. The payment-prep agent builds the run, but releasing it is depth 4 and it is certified only to depth 3, so a finance manager releases each run. The matching agent and the payment-prep agent are separate, so no single agent both validates an invoice and pays it.
When the capture agent starts misreading one supplier's new invoice layout, its next certification run clears no depth and it drops to depth 1. The matching agent sees no new extractions from it and the queue holds; nothing incorrect reaches the payment run.
Should agents query shared data directly? Sometimes, for read-only analysis, but with care. Several agents querying the same warehouse can each pull more than their role needs and combine it in ways no one intended. The safeguards are set out in how to let an AI agent run queries on your data warehouse safely.
What does the platform layer have to do?
- Give each agent its own identity and role.
- Route every handoff through one point that applies the receiver's bounds; the formats involved are described in how agent-to-agent protocols work.
- Carry provenance across every handoff.
- Enforce separation of duties between agents.
- Keep one record with one task id.
For banks in the EU, the operational resilience angle is covered in the EU AI Act and DORA together for AI agents in banks. The full design is in the governed agentic operating system guide.
Where Pryme fits
In Pryme, every agent's actions meet the minimum chain: role scope, certificate, sources, your limits and the platform guardrails, with the lowest bound deciding. Orchestrators coordinate at depth 5 but pass on no more authority than they hold. Every verdict across every agent is filed in one append-only record.
Questions people ask
How many agents is too many?
There is no fixed number. The test is whether each agent has a role you can describe in a sentence and certify on real cases. If you cannot, roles are overlapping.
Should agents check each other's work?
Yes, where the second check is truly independent: different sources, different role. Two agents built on the same model reading the same data are not an independent check.
Who is accountable when a chain of agents gets it wrong?
Your business, through the people who own each agent's role and the chain's design. The record shows which agent and which bound decided each step, which is how accountability is traced.