Zusammenarbeit mehrerer Agenten

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

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.