AI Agent Multi-Agent Coordination Spec Skill
Use When
- An approved feature requires supervisor-worker, handoff, debate or another multi-agent topology.
Do Not Use When
- Do not use for a single agent, parallel independent jobs, or to justify extra agents without measured need.
Required Inputs
| Artefact |
Source or provider |
Required? |
Missing behaviour |
| Approved agent architecture, feature and action catalogue |
Phase 02/03 artefacts |
Required |
Stop if roles, authority or handoff outcome are undefined. |
| Latency, cost, privacy and failure constraints |
Product, security and platform owners |
Required |
Return a single-agent alternative when multi-agent evidence is weak. |
Workflow
- Read the named inputs and confirm their approval, version and unresolved decisions.
- Apply the decision rules below before drafting; stop on a missing authority, unsafe assumption or unresolved scope driver.
- Produce the Multi-Agent Coordination Specification through the existing domain procedure and load only the references needed for the chosen branch.
- Trace each material statement in the Multi-Agent Coordination Specification to an input, decision or explicitly qualified assumption.
- Verify the observable acceptance conditions, record unassessed checks, and hand the artefacts to their named consumers.
- If validation fails, recover by correcting the source decision or artefact and rerun the affected check; do not weaken the acceptance condition.
Outputs
| Artefact |
Consumer |
Observable acceptance condition |
| Multi-Agent Coordination Specification |
Agent, platform, security, evaluation and operations teams |
Exactly one topology is chosen; every role has bounded actions, message schema, context rule, budget, supervision, timeout and recovery path. |
Evidence Produced
| Evidence |
Consumer |
Acceptance condition |
| Source and decision trace |
Reviewer and downstream owner |
Each material statement cites an approved input, named decision or qualified open issue. |
| Completed verification record |
Release or phase gate owner |
Every applicable check records pass/fail; unavailable checks remain not assessed. |
Capability and permission boundaries
Read-only is the default for analysis, review, evaluation and planning. Read and search access to authorised project artefacts are required. Editing is limited to an explicitly requested project deliverable. Execution may run document, syntax or validation checks. Network access is used only for facts that require current verification. Do not publish, spend, change production, approve policy, or claim certification without explicit authority.
Degraded mode
If any required capability is unavailable, return the narrowest useful qualified Multi-Agent Coordination Specification draft plus a gap register showing the missing item, affected sections, risk and owner. Never convert an unassessed check into a pass.
Decision Rules
| Choice |
Action |
Failure or risk avoided |
| Roles need distinct permissions or expertise |
Use supervised workers with explicit handoffs |
Authority remains bounded |
| One agent can complete the task within limits |
Keep one agent |
Coordination cost and emergent failure are avoided |
Quality Standards
- Preserve repository terminology and trace every material choice to project context.
- Use deterministic acceptance conditions; replace vague quality claims with an observable check, threshold or named approval.
- Cover error, empty, edge, recovery and operational cases relevant to this skill.
- Verify standards, citations, APIs and package names before relying on them; qualify what cannot be checked.
- Stop release for a failed safety, security, legal, financial, accessibility or data-integrity gate.
Anti-Patterns
- Adding agents to appear advanced. Fix: show the measured need and single-agent comparator.
- Sharing all scratchpads. Fix: pass only typed handoff data allowed by policy.
- Allowing workers to spawn workers. Fix: centralise topology authority in the supervisor.
- Running debate without a round cap. Fix: set budget, stop rule and tie-breaker.
- Retrying a failed handoff blindly. Fix: use idempotency, timeout and escalation rules.
References
Core Instructions
Step 1: Declare the topology
Pick exactly one per feature:
| Topology |
When |
Trade-off |
| Single-agent |
task fits one role |
simplest; least observability cost |
| Supervisor-worker |
task decomposes into specialist sub-tasks |
strong observability; supervisor is the bottleneck and the source of policy |
| Debate (N-agent) |
task benefits from adversarial cross-check |
improves factuality; cost scales with N and rounds |
| Handoff chain |
sequential phases (retrieve → draft → verify) |
clear ownership; brittle to mid-chain failure |
Step 2: Declare the agent inventory and roles
Per agent role, declare:
- Role name.
- Bounded action-catalogue subset (the role may not call tools outside this subset).
- Memory access (which tiers, which keys).
- Planner template.
- Termination criteria for the role.
Step 3: Declare the scratchpad isolation rule
Default: each agent role has its own scratchpad keyed by (tenant_id, agent_run_id, agent_role). Cross-role sharing is permitted only via explicit handoff messages on the message bus, not via shared memory.
Step 4: Declare the supervision policy
For supervisor-worker:
- Review-before-act — supervisor approves every worker plan before any tool execution.
- Review-after-act — supervisor reviews after each worker step.
- Sample-review — supervisor samples N% of worker outputs.
State which policy applies at which autonomy level. Irreversible tools always require review-before-act regardless of overall policy.
Step 5: Declare the message-bus contract
Inter-agent messages carry: from_role, to_role, agent_run_id, payload_schema, handoff_token. The supervisor is the sole authority that issues handoff_token. Messages without a valid token are refused.
Step 6: Declare failure-mode handling
| Failure |
Handling |
| Worker exceeds budget |
supervisor aborts the worker; the run continues with reduced scope or terminates |
| Worker emits malformed handoff |
supervisor rejects; one retry; then abort |
| Debate fails to converge in N rounds |
terminate; emit abstain payload |
| Supervisor crashes |
orchestrator re-elects supervisor from the durable state |
| Worker proposes irreversible tool without approval |
dispatcher refuses; supervisor reviews; the worker is paused |
Step 7: Write the spec
Multi_Agent_Coordination_Spec.md sections: 1) Topology Verdict, 2) Agent Inventory & Roles, 3) Scratchpad Isolation, 4) Supervision Policy, 5) Message-Bus Contract, 6) Failure-Mode Handling, 7) ADR Seeds, 8) Traceability.
Standards
- OWASP LLM Top 10 (agentic addendum)
- Anthropic agent-engineering patterns
- AutoGen / CrewAI post-mortems
- ISO/IEC 42001 Clause 8
Resources
logic.prompt, README.md, references/ai-agent-multi-agent-coordination-spec-template.md.
1---2name: 15-ai-agent-multi-agent-coordination-spec3description: Use when two or more agents participate in one user task and need a bounded topology, role inventory, scratchpad isolation, supervision, message contract and failure handling; use agent architecture for the common single-agent runtime.4---5# AI Agent Multi-Agent Coordination Spec Skill6<!-- dual-compat-start -->7## Use When89- An approved feature requires supervisor-worker, handoff, debate or another multi-agent topology.1011## Do Not Use When1213- Do not use for a single agent, parallel independent jobs, or to justify extra agents without measured need.1415## Required Inputs1617| Artefact | Source or provider | Required? | Missing behaviour |18|---|---|---|---|19| Approved agent architecture, feature and action catalogue | Phase 02/03 artefacts | Required | Stop if roles, authority or handoff outcome are undefined. |20| Latency, cost, privacy and failure constraints | Product, security and platform owners | Required | Return a single-agent alternative when multi-agent evidence is weak. |2122## Workflow23241. Read the named inputs and confirm their approval, version and unresolved decisions.252. Apply the decision rules below before drafting; stop on a missing authority, unsafe assumption or unresolved scope driver.263. Produce the Multi-Agent Coordination Specification through the existing domain procedure and load only the references needed for the chosen branch.274. Trace each material statement in the Multi-Agent Coordination Specification to an input, decision or explicitly qualified assumption.285. Verify the observable acceptance conditions, record unassessed checks, and hand the artefacts to their named consumers.296. If validation fails, recover by correcting the source decision or artefact and rerun the affected check; do not weaken the acceptance condition.3031## Outputs3233| Artefact | Consumer | Observable acceptance condition |34|---|---|---|35| Multi-Agent Coordination Specification | Agent, platform, security, evaluation and operations teams | Exactly one topology is chosen; every role has bounded actions, message schema, context rule, budget, supervision, timeout and recovery path. |3637## Evidence Produced3839| Evidence | Consumer | Acceptance condition |40|---|---|---|41| Source and decision trace | Reviewer and downstream owner | Each material statement cites an approved input, named decision or qualified open issue. |42| Completed verification record | Release or phase gate owner | Every applicable check records pass/fail; unavailable checks remain `not assessed`. |4344## Capability and permission boundaries4546Read-only is the default for analysis, review, evaluation and planning. Read and search access to authorised project artefacts are required. Editing is limited to an explicitly requested project deliverable. Execution may run document, syntax or validation checks. Network access is used only for facts that require current verification. Do not publish, spend, change production, approve policy, or claim certification without explicit authority.4748## Degraded mode4950If any required capability is unavailable, return the narrowest useful qualified Multi-Agent Coordination Specification draft plus a gap register showing the missing item, affected sections, risk and owner. Never convert an unassessed check into a pass.5152## Decision Rules5354| Choice | Action | Failure or risk avoided |55|---|---|---|56| Roles need distinct permissions or expertise | Use supervised workers with explicit handoffs | Authority remains bounded |57| One agent can complete the task within limits | Keep one agent | Coordination cost and emergent failure are avoided |5859## Quality Standards6061- Preserve repository terminology and trace every material choice to project context.62- Use deterministic acceptance conditions; replace vague quality claims with an observable check, threshold or named approval.63- Cover error, empty, edge, recovery and operational cases relevant to this skill.64- Verify standards, citations, APIs and package names before relying on them; qualify what cannot be checked.65- Stop release for a failed safety, security, legal, financial, accessibility or data-integrity gate.6667## Anti-Patterns6869- Adding agents to appear advanced. Fix: show the measured need and single-agent comparator.70- Sharing all scratchpads. Fix: pass only typed handoff data allowed by policy.71- Allowing workers to spawn workers. Fix: centralise topology authority in the supervisor.72- Running debate without a round cap. Fix: set budget, stop rule and tie-breaker.73- Retrying a failed handoff blindly. Fix: use idempotency, timeout and escalation rules.7475## References7677- [Coordination template](references/ai-agent-multi-agent-coordination-spec-template.md)78- [Agent Architecture neighbour](../14-ai-agent-architecture-spec/SKILL.md)79<!-- dual-compat-end -->8081828384## Core Instructions8586### Step 1: Declare the topology8788Pick exactly one per feature:8990| Topology | When | Trade-off |91|----------|------|-----------|92| Single-agent | task fits one role | simplest; least observability cost |93| Supervisor-worker | task decomposes into specialist sub-tasks | strong observability; supervisor is the bottleneck and the source of policy |94| Debate (N-agent) | task benefits from adversarial cross-check | improves factuality; cost scales with N and rounds |95| Handoff chain | sequential phases (retrieve → draft → verify) | clear ownership; brittle to mid-chain failure |9697### Step 2: Declare the agent inventory and roles9899Per agent role, declare:100101- Role name.102- Bounded action-catalogue subset (the role may not call tools outside this subset).103- Memory access (which tiers, which keys).104- Planner template.105- Termination criteria for the role.106107### Step 3: Declare the scratchpad isolation rule108109Default: each agent role has its own scratchpad keyed by `(tenant_id, agent_run_id, agent_role)`. Cross-role sharing is permitted only via explicit handoff messages on the message bus, not via shared memory.110111### Step 4: Declare the supervision policy112113For supervisor-worker:114115- **Review-before-act** — supervisor approves every worker plan before any tool execution.116- **Review-after-act** — supervisor reviews after each worker step.117- **Sample-review** — supervisor samples N% of worker outputs.118119State which policy applies at which autonomy level. Irreversible tools always require review-before-act regardless of overall policy.120121### Step 5: Declare the message-bus contract122123Inter-agent messages carry: `from_role`, `to_role`, `agent_run_id`, `payload_schema`, `handoff_token`. The supervisor is the sole authority that issues `handoff_token`. Messages without a valid token are refused.124125### Step 6: Declare failure-mode handling126127| Failure | Handling |128|---------|----------|129| Worker exceeds budget | supervisor aborts the worker; the run continues with reduced scope or terminates |130| Worker emits malformed handoff | supervisor rejects; one retry; then abort |131| Debate fails to converge in N rounds | terminate; emit abstain payload |132| Supervisor crashes | orchestrator re-elects supervisor from the durable state |133| Worker proposes irreversible tool without approval | dispatcher refuses; supervisor reviews; the worker is paused |134135### Step 7: Write the spec136137`Multi_Agent_Coordination_Spec.md` sections: 1) Topology Verdict, 2) Agent Inventory & Roles, 3) Scratchpad Isolation, 4) Supervision Policy, 5) Message-Bus Contract, 6) Failure-Mode Handling, 7) ADR Seeds, 8) Traceability.138139## Standards140141- OWASP LLM Top 10 (agentic addendum)142- Anthropic agent-engineering patterns143- AutoGen / CrewAI post-mortems144- ISO/IEC 42001 Clause 8145146## Resources147148- `logic.prompt`, `README.md`, `references/ai-agent-multi-agent-coordination-spec-template.md`.
peterbamuhigire