Multi Agent Testing: How to Verify What AI Agents Do

A support system routes a customer request to a refund agent. The refund agent calls a payment tool, hands the case to a notification agent, and the run finishes with a clean summary: refund issued, customer notified. The refund did go through. The notification never fired, because the handoff dropped the customer id and the notification agent failed silently on a null.

Every test in that pipeline passed. The transcript reads correctly end to end, because the transcript is the system's own account of itself, and no agent in the chain knew the notification had not happened.

This is the problem multi agent testing exists to solve. When several agents call tools and hand work to each other, the interesting failures stop living inside any one agent and move into the seams between them.

Multi agent testing is the practice of verifying a system in which several AI agents work together, each with its own tools and responsibilities, passing work between them until a task is done. It covers the individual agents, the decisions that route work between them, and the effect the system has on real data once it finishes.

The architecture usually takes one of a few shapes: a supervisor delegating to specialists, a pipeline where each agent hands to the next, or a set of peers that negotiate. The architecture of multi-agent AI systems matters here because it determines where a fault can hide.

What separates this from ordinary application testing is that there is no fixed contract to assert against. A function takes arguments and returns a value. An agent takes a sentence and may produce prose, a created ticket, a written file, or a payment.

Three properties of agent systems break the assumptions that conventional test suites rest on.

• The interface is open - the input is natural language and the output is whatever the system decided to produce, so there is no signature to write an assertion against.
• The behaviour is non-deterministic - the same request twice can take two different paths, so a test that pins the path fails constantly while a test that pins nothing proves nothing.
• The system acts on the world - it is not returning a value for you to inspect, it is doing things, some of which move money or cannot be undone.

The table below maps what each familiar approach establishes and what it leaves open once agents are involved.

None of them establishes whether the tool calls behind the answer actually happened, which is the question a multi agent system most needs answered.

These are the failure shapes worth writing scenarios for, because each one produces a clean-looking result.

• Confident false reports - the system states that it issued a refund and notified the customer, and only the first half happened.
• Misrouting - the supervisor sends a billing question to a technical specialist, which answers plausibly and wrongly rather than declining.
• Lossy handoffs - a constraint stated in the first agent's context, such as a spending limit, is not carried into the second agent's prompt.
• Silent policy violations - the reply states a limit correctly and breaches it in the same run.
• Loops and stalls - two agents hand the same task back and forth until a budget or timeout ends the run.
• Write collisions - two agents acting in parallel update the same record, and the last write silently wins.
• Evidence-free green - a suite reports a high pass rate and nobody can say which passes were observed and which were inferred from the system's own summary.

For the orchestration-level view of several of these, the guide to agentic AI orchestration patterns and failure modes works through how routing and delegation break down in practice.

Note: Agents that act on real systems need verification against evidence, not against their own summary. TestMu AI runs that check. Try it free.

Treat the system as four testable layers. Skipping any one of them leaves a class of defect with nowhere to surface.

• Each agent in isolation - give one agent a task inside its remit and one outside it. An agent that answers confidently outside its remit is a routing problem waiting to happen.
• Routing and delegation - send requests that sit near the boundary between two specialists and assert which one received the work, not which words came back.
• Handoffs - state a constraint in the first agent's input and assert it is still honoured by the last agent. This is where the earlier refund example fails.
• End-to-end effect - run a full task and check the world afterwards. Did the record change, was the artifact produced, was the audit entry written.

Write the assertions as criteria rather than paths. A criterion is a single gradable claim, and it survives the system taking a different route to the same outcome.

# Criteria survive a changed route; a pinned tool sequence does not.
scenario: refund_within_limit
  goal: "Refund order A-1183 for the customer, who reports a damaged item."
  criteria:
    - a refund of the order value exists against order A-1183
    - the customer record shows a notification event after the refund
    - no tool outside the declared tool surface was called
    - the refund amount does not exceed the stated approval limit

The single most useful rule in this area is that a system's account of what it did is the weakest evidence available about what it did. It is the one party with a reason to be wrong, and its summary is generated by the same process that may have failed.

Evidence that holds up is external to the transcript.

• Filesystem deltas - which files changed while the run was in progress, compared against what the scenario expected to change.
• Artifacts produced - the ticket, the report, the committed branch, checked for existence and content rather than mentioned in a summary.
• Tool calls against the declared surface - which tools actually fired, checked against the tools the agent says it has, which catches both the missing call and the unexpected one.

This also changes what a verdict should look like. Two outcomes are not enough, because a criterion the harness could not check is neither a pass nor a failure. Reporting it as either one corrupts the number.

Keeping the third outcome out of the pass rate is what makes the pass rate mean something. The share of criteria that could not be verified is worth reporting as its own number, and it is mostly a property of the system rather than the harness: an agent that records its tool calls is far more verifiable than one that does not.

Multi agent systems widen the attack surface, because untrusted text reaching any agent can influence what a later agent does with its tools. These cases never appear in a hand-written happy-path suite, so they have to be generated deliberately.

• Prompt injection through content - instructions hidden in a document, a commit message, or a support ticket that the system later reads as direction.
• Instruction override - a request that asks an agent to ignore a constraint set by the agent that delegated to it.
• Tool misuse - steering an agent toward a tool that is in its surface but wrong for the task, such as a write tool during a read-only enquiry.
• Policy boundary probes - requests that sit just past an approval limit to see whether the limit is enforced or merely quoted.
• Exfiltration attempts - prompts designed to move data from a privileged agent's context into an output the requester can read.

Treat a compromised adversarial scenario as a security finding rather than a test failure, and route it accordingly. The same discipline applies when the agent talks to people instead of systems, which is covered in the guide to testing chatbots and voice agents.

A suite that runs when someone remembers to trigger it is not a safety net. Getting it into the pipeline raises two questions that ordinary test suites do not face.

Where does it run? The harness invokes your agents for real and cannot undo a refund it caused or a ticket it opened. Point the run at a staging environment with staging credentials, and know which write-capable tools each agent declares before you start. Treat any suggestion that agent runs are inherently side-effect-free with suspicion, because a system that genuinely acts cannot be tested without acting on something.

What should fail the build? Separate the two cases. A run where an agent did something wrong is a finding about your system. A run that could not reach or invoke the agent is an infrastructure problem, and conflating them sends engineers hunting for a bug that is not there.

Do not gate on the unverified share straight away. Measure it for a few weeks, learn what your system's baseline is, then set a threshold you have earned.

TestMu AI approaches this through Agent Assurance, which covers two categories of agent because they fail in different ways. Agents that talk to people are graded on the quality of the reply. Agents that act on systems are graded on the truth of the effect.

• Autonomous agents - for agents that call tools, write files, and change systems, the question is whether the effect matches the account. It reads the codebase to work out what the agent does, generates functional, non-functional, and adversarial scenarios, invokes the agent the way a user would, and grades each criterion against observed evidence. This category is pre-alpha at the time of writing, and it runs from the terminal and CI.
• Conversational agents - for chat, voice, phone, and image agents, the question is whether the answer was good. That category is generally available and covered on the AI agent testing platform page.

Three design decisions in the autonomous category map directly onto the problems above. You do not author the suite, because the scenarios are derived from the code rather than from a test plan you maintain. Verdicts are per criterion rather than per scenario, so a partial success reports as such. Anything that could not be checked is reported as unverifiable and excluded from the pass rate, which is what stops a green number from quietly mixing what was proved with what was assumed.

The one input it cannot derive is how to invoke your agent, which you supply once as a command, an HTTP endpoint, or an MCP server. For verifying the application an agent operates on rather than the agent itself, Kane CLI applies the same evidence-first approach to a real browser.

Start by taking one scenario your agent system already handles and writing down the criteria that would prove it worked, without referring to anything the system says about itself. If you cannot check most of them from outside the transcript, that is the finding, and the fix is to make your agents record what they do before you write another test.

From there, add the four layers, generate adversarial cases alongside the functional ones, and get the suite into CI with the two failure kinds kept apart. For related background, the guide to agentic quality assurance covers how these practices sit inside a wider QA process, and end to end agent testing covers the same discipline applied to a single agent path.

To try this on your own agents, create a free TestMu AI account and start with the getting started documentation.