Certifying Multi-Agent Systems: A Practical Guide

Why single-agent assumptions stop working

A certification methodology built around a single agent implicitly assumes a bounded, observable scope of action: the agent receives an input, reasons over it within a defined context, and produces an output or takes a defined set of possible actions. Most of the evidence categories in a standard assessment, documented instructions, tested behaviour boundaries, human oversight checkpoints, map cleanly onto that shape. A multi-agent workflow breaks the shape in a specific way: the orchestrator agent's own documented scope may say nothing about what actions become possible once it delegates a sub-task to another agent that has tool access, data access, or permissions the orchestrator itself does not directly hold.

This is not a hypothetical edge case. Production patterns already in wide use include an orchestrator that plans a task and dispatches specialised sub-agents for research, drafting, and execution steps, a customer-facing agent that calls a separate backend agent with database write access to complete a transaction, and workflows that call third-party agent endpoints outside the deploying organisation's own infrastructure entirely. In each case, the combined system's actual capability is the union of what every agent in the chain can do, not merely what the entry-point agent's own instructions describe. An assessment that stops at the entry point has assessed a fraction of the system.

What changes across the seven dimensions

Three of this framework's seven dimensions carry most of the additional work in a multi-agent assessment. The remaining four apply largely unchanged, evaluated at each node in the chain rather than once for the system as a whole.

The Autonomy Envelope dimension requires the most significant adaptation. Where a single-agent assessment documents the boundary of one system's autonomous action, a multi-agent assessment must document the combined boundary across every agent in the chain, including which agent holds which permission and whether any combination of calls could produce an action outside what any individual agent was cleared for. An orchestrator with a narrow envelope that can nonetheless invoke a sub-agent with a broad one has, in practice, a broad envelope, and a certification that scores it narrow is not measuring the deployed system.

The Distribution Control dimension, which evaluates how outputs reach users and what controls exist over that path, extends to internal agent-to-agent distribution, not only the final output to an end user. An intermediate agent's output that is consumed directly by another agent, without a human or validation checkpoint in between, is a distribution event in the same sense a customer-facing output is, and it should be assessed with the same rigour: what could go wrong if this specific output is wrong, and what catches it before it propagates further down the chain.

The Governance dimension carries the accountability question specifically. A defensible multi-agent governance record names an accountable owner for the overall workflow outcome, not only for each individual agent, and documents the escalation path when a failure's root cause is ambiguous across multiple agents in the chain, which is the common case in practice. Our earlier analysis of the Governance dimension sets out the general evidence standard; for multi-agent systems, the standard additionally requires a documented map of which agent owns which decision.

Trust and Safety, Context Integrity, Product Maturity, and AI Integration apply in largely the same form at each node in the chain as they would to a standalone agent. The practical implication is that a multi-agent assessment is not four times the work of a single-agent one; it is a normal single-agent assessment repeated at each significant node, plus a genuinely new layer of chain-level analysis concentrated in Autonomy Envelope, Distribution Control, and Governance.

The orchestrator is not a shield

A recurring pattern this framework has observed in early multi-agent submissions is an attempt to present the orchestrator agent as the system under assessment while describing sub-agents and third-party agent endpoints as external tools, analogous to an API call, that fall outside the certification scope. This framing is sometimes accurate and sometimes is not, and the distinction matters. A genuine external tool call, for example a weather lookup or a currency conversion, returns bounded, low-consequence data and is reasonably treated as outside the core assessment. A sub-agent that itself makes judgement calls, holds independent tool access, or can take a consequential action is not a tool in this sense; it is a second system with its own risk profile, and describing it as a tool does not change what it can do.

The test this framework applies is functional, not architectural: does the called component exercise judgement or discretion of the kind the orchestrator itself exercises, or does it return deterministic or narrowly bounded data with no independent decision content? Components that exercise judgement are assessed as agents in the chain, with their own scope, permissions, and evidence requirements documented, regardless of whether the deploying organisation's internal architecture diagrams label them as tools, workers, or sub-agents. This mirrors the reasoning EU AI Act Article 25 applies to deployers who substantially modify or integrate third-party high-risk components: relabelling a component does not change the obligations that attach to what it actually does.

What agent-to-agent protocols add to the evidence base

Two developments in how agents technically call other agents are relevant to how tractable this assessment work is, though neither changes the underlying obligation. Anthropic's Model Context Protocol, released in November 2024, standardises how an AI model discovers and invokes external tools and data sources through a common interface. Google's Agent2Agent protocol, announced in April 2025 and subsequently contributed to the Linux Foundation for open governance, standardises discovery and task delegation between independent AI agents, including agents built by different organisations.

For certification purposes, the practical benefit of standardised protocols is not that they make multi-agent systems inherently safer; it is that they make the chain legible. A workflow built on a standardised protocol typically exposes, in a structured and inspectable form, which agents or tools a given agent can call and what permissions or data scope that call carries. That structured exposure is close to the raw evidence an Autonomy Envelope and Distribution Control assessment needs, which means a well-instrumented, protocol-based multi-agent system can in practice be easier to certify thoroughly than an equivalent system built on ad hoc, custom integration code where the actual call graph exists only in the engineering team's heads. Operators building new multi-agent workflows should treat this as a practical reason, among several, to prefer standardised protocols over bespoke integration where both are viable options.

A practical assessment sequence for multi-agent systems

The workflow this framework applies to a multi-agent submission starts with a call graph, not a questionnaire. Before any dimension scoring begins, the deployer produces a map of every agent, sub-agent, and third-party agent endpoint in the workflow, the permissions and data access each one holds, and the checkpoints, human or automated, that sit between them. Components that fail the judgement-versus-tool test above are added to the graph as agents in their own right. Only once this graph exists does the assessment proceed to score each node against Trust and Safety, Context Integrity, and Product Maturity individually, and to score the workflow as a whole against Autonomy Envelope, Distribution Control, and Governance using the combined picture the graph provides.

Where a component in the chain is a third-party agent outside the deployer's own infrastructure and cannot be directly assessed, for example a partner organisation's agent reached over a standardised protocol, the honest outcome is a documented scope limitation rather than an assumed pass. This is analogous to how a FRIA cannot be completed on a deployer's behalf by a certification body, a point covered in this site's earlier analysis of the FRIA overlap with certification evidence: some parts of a multi-agent chain's risk picture can only be documented by the party that controls that specific link, and a certification that papers over that gap is not more useful to an insurer or a regulator for having done so.

What to tell a compliance team or an underwriter honestly

The defensible position for a deployer running a multi-agent workflow is to present the call graph and the per-node evidence together, rather than a single scorecard that implies the whole system was assessed as one unit. An underwriter or a regulator reading a multi-agent submission should be able to see which links in the chain carry full evidence, which carry a documented scope limitation because they sit outside the deployer's direct control, and how the Autonomy Envelope and Governance scores were derived from the combined graph rather than from the entry-point agent alone. A submission built this way is more work to produce than a single-agent scorecard, and it is also the only version of the claim that survives scrutiny once a workflow is complex enough to need more than one agent in the first place.

For how this evidence feeds an underwriting submission once a multi-agent workflow is live, see preparing an AI agent underwriting submission on agentinsured.eu.