Multi-Agent Systems: Delegation, Handoffs, and Verifiable Collaboration

A multi-agent system is not a prompt sent to more workers. It is a costed control strategy with authority and merge risk: who decides to delegate, what a subtask may observe, who can write which artifacts, how the team hands off, resolves conflicts, cancels, and recovers, and who accepts the outcome in an independent environment. Without these boundaries, “the team is stronger” usually just means more tokens, broader authority, or more retries.

1. When Collaboration Is Worth It, and When It Is Only More Expensive

Judge task structure before choosing parallelism. MAS-Orchestra characterizes tasks by depth, horizon, breadth, parallelism, and robustness; in its controlled setting, its multi-agent gains depend on task structure, verification protocol, and orchestrator and worker capability rather than holding universally. Anthropic’s multi-agent research system describes using an orchestrator-worker design to widen independent context capacity for open-ended research. That is engineering experience from a particular system, not evidence that every task deserves more agents.

Minimal counterexample. When a capable single agent can finish a task from the same initial state with the same tools and total budget, extra workers cannot be called a “collaboration gain” merely because total calls rose. Report a gain only when time to independently accepted terminal state falls, or verified outcome improves without increasing total resources.

2. What A2A Does: Describe Tasks and Artifacts, Not Replace Governance

The A2A specification organizes interoperation between independent agents around Agent Cards, stateful Tasks, Messages, Artifacts, streaming, and push notifications. It lets a client discover a remote agent’s declared capabilities and follow a long task’s lifecycle and deliverables. A2A is an application-level protocol for agent-to-agent collaboration, whereas MCP is an interoperability protocol for agent-to-tool use. Neither establishes that a remote agent is trustworthy, its output is correct, or it is authorized to take any business action on a user’s behalf.

An Agent Card is particularly a capability declaration, not a result certificate. The specification recommends HTTPS, avoiding public secrets, and verifying signatures when present. Identity, authorization, scopes, invocation policy, and auditing remain deployment responsibilities. The host-side capability grants, pre-commit interception, and sidecar verifier in Agent Tool Governance apply to every agent-delegation hop as well.

3. Express Each Delegation as a Delegation Ticket

“Please look into this” is not an auditable delegation. Before sending work, the root agent creates a ticket; the worker runs only within its boundary.

Every ticket, grant, cancellation, and artifact digest belongs in an append-only trace. A worker’s prose can be useful evidence, but it is not final truth. Each return should label at least claim, evidence_refs, artifact_refs, uncertainty, side_effects, and remaining_authority. The parent can then distinguish “a worker says it is complete” from “an independent verifier confirms backend state.”

4. Handoffs, Merges, and Acceptance: A Team Is Not One Large Chat History

Multi-agent handoffs should carry stable artifacts and bounded, interpretable context, not concatenate every transcript into the next prompt. For parallel research, workers can return source tables, experiment records, or read-only artifacts. On shared workspaces, one owner should retain write and merge authority while other workers submit patches or advice. For external effects, request, approval, execution, and acceptance can be held by different roles, but they must not share one unlimited credential.

MAESTRO exports framework-agnostic traces plus latency, cost, and failure signals, and its multi-agent cases find that architecture can drive resources, reproducibility, and cost-latency-accuracy trade-offs more than backend model or tool choice. MAFBench likewise reports substantial latency, planning, and coordination differences from framework-level choice under its controlled comparison. They are scoped preprint evidence, but jointly show why team comparisons cannot omit traces and full configuration.

5. Collaboration Needs Its Own Evaluation, Not Only Final Accuracy

CalBench gives a necessarily multi-agent case: each participant keeps a private calendar and must reach a verifiable coordination outcome without fully sharing information. It measures realized cost, communication efficiency, fairness, and privacy leakage together. NRT-Bench uses a multi-role team and replayable multi-turn attacks with an objective termination signal when a critical safety function is lost. These examples show that a team-run completion must be joined by safety, communication, and failure attribution measurements.

At minimum, fix the base model, tool set, environment, task distribution, hidden evaluator, and total token / wall-clock / worker-time budget, then compare:

1. Single agent: one full context and the same total resources, the actual capacity baseline.
2. Sequential decomposition: the same agent or root policy executes subtasks serially, separating decomposition from parallelism.
3. Parallel team: declare orchestrator, worker count, tickets, roles, merge policy, and shared state; total resources, not per-worker resources, stay equal.
4. Ablations: remove artifact contracts, narrow authority, parent review, or cancellation, then measure their effect on outcome, privacy, duplication, and safety.

Report verified_success, cost_per_verified_success, time_to_acceptance, tokens/calls/worker-time, delegation_depth, duplicated work, merge conflicts, unsupported claims, authority violations, secret/private-state leakage, false blocks, recovery, and run-to-run variance together. SABER’s stateful coding-workspace safety evaluation also shows why a single-turn refusal score cannot replace measuring the consequence of action sequences.

6. Multi-Agent Safety: Responsibility Does Not Disappear Through Delegation

Each worker output, shared memory, Agent Card, tool result, and handoff document can be untrusted input. Delegation also fans a parent’s authority, time, and cost across execution paths, so risk is not limited to a malicious worker. Safe Bilevel Delegation formalizes runtime delegation safety as a constrained bilevel optimization problem, but the version checked labels its empirical protocol as planned evaluation. It is theoretical input for making delegation degree and accountability explicit, not evidence of a proven practical system.

Safety tasks should include at least these adversarial controls: forged or stale Agent Cards; prompt injection in worker messages; insufficient evidence requesting a merge; escalation from a low-risk read to high-risk write; delegation cycles; late artifacts after cancellation; private information copied into team messages; and cross-agent workflows whose UI appears complete while the backend did not commit. Each needs a paired benign task, so a team cannot buy a fictional safety score by refusing everything.

7. How It Returns to the Core Five

This note complements Agent Tool Governance: tool governance constrains one external action, while this note constrains agent-to-agent delegation, messages, and merging. For durable state and recovery, see Long-horizon agents; for the core-five overview, see Five Research Threads; for adjacent directions, see Hot Agent Directions.