← Back to Echo
AgentEcho

Skill · Version 1.0.0

Multi-agent coordination

Structures agent collaboration around clear handoffs, bounded parallelism and isolated ownership so partial results can be integrated reliably.

multi-agent-coordination

See how it helps

When is it useful?

Use it when several agents share a task and ambiguous responsibilities could create conflicting edits or lost work.

What does it help you do?

  • Defines assignment inputs, ownership and completion contracts.
  • Isolates parallel writers through disjoint files or separate workspaces.
  • Bounds delegation and surfaces partial failures without hiding completed results.

Try asking this

Coordinate frontend and backend workers with explicit file ownership and integration checks. Give both workers the same API contract and disjoint file ownership. Integrate their outputs with a real request, and report a failed subtask without hiding completed work.

Detailed documentation

Read the skill’s original instructions, examples and checks in their authored language.

Details…Show less

Multi-Agent Coordination

Reach for multiple agents only when a task genuinely benefits from context isolation (keeping noisy exploration out of the lead agent's context), parallel execution across independent units of work, or distinct role/tool specialization. Every additional agent boundary introduces handoff latency, token overhead, and coordination failure modes.

Coordination Patterns & When to Use Them

Pattern Topology Best Fit Key Guardrail
Single Agent + Rich Tools 1 loop Cohesive sequential tasks sharing tight state Default choice until context or parallelism demands splitting
Orchestrator / Subagent (Hierarchical) Lead $\rightarrow$ bounded workers $\rightarrow$ Lead Parallel codebase research, isolated module implementation, independent verification Subagents return structured summaries + artifact references, never raw 50k-token transcripts
Phase Pipeline (Sequential Handoff) Planner $\rightarrow$ Implementer $\rightarrow$ Reviewer/Tester High-assurance workflows where generation and verification must have independent incentives Enforce a typed handoff artifact at every phase gate
Parallel Evaluators / Voting Fan-out to $N$ reviewers $\rightarrow$ aggregator Security/architecture review, high-stakes diff verification Deduplicate findings and resolve conflicts deterministically

Typed Handoff Contracts

Never hand off work between agents with vague conversational prose ("see above and finish the rest"). Every delegation and return message must carry a self-contained contract:

  1. Delegation Request (TaskAssignment):
    • objective: Exact deliverable expected from the subagent.
    • scope_boundaries: Files, directories, or services the worker may read and modify—and what is explicitly off-limits.
    • context_refs: Pinned file paths, design decision IDs, or schema references so the worker reads authoritative sources directly rather than relying on lossy telephone-game summaries.
    • acceptance_criteria: Concrete verification command or output schema required before reporting completion.
    • budget: Maximum turns, wall-clock timeout, and allowed tool set.
  2. Completion Report (TaskOutcome):
    • status: completed | partial | blocked | failed.
    • summary: Concise synthesis of findings or changes made.
    • evidence: File paths + line numbers, test execution output, or commit/diff references.
    • open_risks_or_blockers: Unresolved questions or dependencies that require orchestrator action.

Concurrency, Isolation & Anti-Loop Rules

  • Workspace & write isolation: Never allow two parallel agents to edit the same files in the same working tree simultaneously. Assign disjoint file ownership sets or isolate concurrent writers in separate git worktrees / branched workspaces, followed by an explicit merge-and-test phase.
  • Bounded delegation depth: Enforce max_delegation_depth (typically 1 or 2 levels) and forbid circular delegation (A -> B -> A) to prevent runaway recursive agent spawning.
  • Partial failure handling in fan-out: Use bounded concurrency (Semaphore / worker pool) with per-worker timeouts (Promise.allSettled). If 1 of 5 parallel research workers times out, surface the 4 completed results plus an explicit gap notice so the lead agent can decide whether to retry the failed shard or proceed.
  • Role-based addressing: Address capabilities and roles (the architect, the reviewer, the backend developer) in workflow contracts rather than hardcoding fragile personal names so team rosters can evolve without breaking orchestration logic.

Included files 1

  • SKILL.md