A multi-agent system can preserve every message and still lose task ownership, replay a completed write, or stop one worker while another keeps acting. Multi-Agent Testing reviews the coordination protocol across delegation, shared state, conflicts, ownership, termination, and traceability.
Multi-Agent Testing: trace a handoff
For each task or message, record the task ID, message or correlation ID, sender, receiver, parent delegation, scope, owner, shared-state version, and acknowledgment. Use the project’s real acceptance, rejection, and termination rules; do not assume delivery is exactly once.
| Handoff element | Evidence to look for |
|---|---|
| Delegation | The child receives a bounded task, permitted tools, and a clear owner. |
| Shared state | The message points to a version or artifact the receiver can actually access. |
| Ownership | Claim and commit follow the supplied atomic ownership or fencing protocol. |
| Acknowledgment | The sender can distinguish accepted, rejected, completed, and indeterminate work. |
| Termination | Stop requests reach all active children and leave an auditable terminal state. |
A duplicate delivery alone is not a defect if the protocol safely deduplicates it. Check whether stale messages can regain ownership, whether a lease-expired worker can still commit, and whether a retried task can duplicate side effects.
Worked example: research pipeline
Suppose a pipeline has planner, source-checker, writer, and reviewer agents. The source-checker reads an older policy version while the planner receives a newer requirement. Review the handoff payloads and shared-state versions: the writer should retain the conflict, and the reviewer should be able to identify which sources each claim used before any final decision is assigned.
If a child times out after making a side effect, distinguish completed work from unfinished and indeterminate effects before reassignment. Preserve the owner and evidence for each item. A stop request also needs acknowledgment and a terminal state; a parent’s timeout is not proof that every child stopped.
Choose failure scenarios from the protocol
Do not put every failure into one regression run. Select paths that can change ownership, state, or an external side effect, then inject one condition at a time. Run these checks with isolated or reversible test data; production writes are not a test mechanism.
| Scenario | Injected condition | What to observe |
|---|---|---|
| Duplicate handoff | Replay a message after the receiver acknowledged it | Whether the message ID is deduplicated, the repeated acknowledgment matches the original result, and a side effect is submitted twice |
| Shared-state change | Another agent updates the version after the receiver reads it | Whether the stale version is rejected, merged, or explicitly marked as a conflict instead of silently overwriting the newer value |
| Expired ownership | Pause a worker holding a lease, let another worker take over, then resume the first | Whether the old worker can commit with an expired token and whether the commit path checks current ownership or a fencing token |
| Timeout after a side effect | The write succeeds but its completion message is lost, so the parent retries | Whether the system reconciles a stable operation ID before retrying, reusing the result, or escalating an indeterminate state |
| Stop propagation | One child receives cancellation while other children are queued or calling tools | Whether each child’s request, acknowledgment, tool state, and terminal state can be inspected separately |
Change one condition per run and preserve the input task ID, message ID, state version, ownership token, tool operation ID, and final acknowledgment. This separates “duplicate but safely deduplicated,” “state change detected,” and “indeterminate result treated as failure and retried.” If the protocol does not define an outcome, record a contract gap, have its owner decide the expected behavior, and add the rule to regression coverage.
Record a MAT-## finding
For each coordination gap, identify the task or protocol rule, source, trigger, message and state version, expected concern, evidence status, impact and priority, owner role, close condition, and validation method. Include duplicate, stale, partial-failure, reassignment, and stop-propagation cases only where the supplied protocol makes them applicable.
Keep static design, candidate validation, and actual execution separate. A task graph or recorded message schema does not prove that an agent run followed it.
Related Skills
- AI Agent Testing: https://inaodeng.com/en/qaskills/ai-agent-testing/ examines an agent’s task behavior and trace.
- Agent Tool Testing: https://inaodeng.com/en/qaskills/agent-tool-testing/ checks tool-call contracts and side effects.
- Authorization Testing: https://inaodeng.com/en/qaskills/authorization-testing/ checks which subject may take which action.
Install and invoke
Install the individual Skill:
npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en --skill multi-agent-testingInvoke multi-agent-testing with the coordination protocol, task and message records, shared-state versions, ownership rules, and termination behavior. Start with a redacted trace:
Review these redacted multi-agent handoff records with multi-agent-testing.
Protocol and success conditions: [delegation, claim/commit, retry, cancellation, and termination rules]
Trace: [task/message/correlation IDs, sender/receiver, state versions, acknowledgments, tool side effects]
Scope: [agents, messages, and steps included or excluded]
List confirmed facts, conflicts, missing evidence, and candidate MAT-## findings. Separate static design from runtime results. Do not assume exactly-once delivery or claim that an unobserved child stopped.FAQ
Is duplicate message delivery automatically a defect? No. Check deduplication, ownership, and side effects against the project’s protocol. Do not assume exactly-once delivery or safe replay when evidence is missing.
Does a parent-task timeout prove every child stopped? No. Check each active child’s cancellation acknowledgment, tool state, and terminal record.
Source
Read the Multi-Agent Testing prompt: https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/multi-agent-testing/prompts/multi-agent-testing.md before use. It defines the MAT-## contract for ownership, partial-failure reconciliation, acknowledgments, and termination.