Multi-Agent Communication Patterns for Survivable Harnesses

Building production-grade AI agent harnesses means confronting the complexity of multiple agents interacting in shared environments. As we move from single-agent prototypes to multi-agent systems, the harness becomes the critical layer that enforces reliability, observability, and cost discipline. This post covers three foundational communication patterns—worker delegation, team-mode review, and supervisor loops—and translates them into concrete engineering decisions. The site tracks related research papers separately; here we focus on the practical harness mechanics.

Worker Delegation Contracts

Delegation is the most basic multi-agent pattern: an orchestrator farm out a unit of work to a worker agent. Treat each delegation as a strict tool contract. The orchestrator calls a tool (e.g., assign_task) whose input schema defines the task spec, context window, and expected output format. The worker must respond within a bounded time and schema. If the response is malformed, the harness should immediately classify it as a contract violation, not a soft failure.

Observability starts at the delegation boundary. Every call carries a unique trace ID that propagates across the worker’s execution. Capture latency, token consumption, and the response size. This data feeds directly into cost budgets and alerting thresholds. For eval isolation, each delegation should be idempotent: replaying the exact same input must produce the same output (or a repeatable failure). Store the full request and response pair in a trace store—this is what makes later replay and debugging possible without live agents.

Retry budgets are non-negotiable. Define how many times a delegation can be retried before the harness promotes the error to a supervisory decision. A common pattern is to retry on timeout or transient failures, but not on schema violations. Always instrument the retry count in the trace. The failure taxonomy for delegation includes: timeouts, schema violations, resource exhaustion (e.g., context window overflow), and semantic reject (worker explicitly refuses). Each category maps to a distinct handling path in the harness.

Team-Mode Review

When multiple agents collaborate on a single artifact, review becomes a necessary pattern. A reviewer agent validates the work of a producer against a set of assertions or ground truth. Design the review interaction as another tool contract: request_review passes the artifact, the review criteria, and a pointer to the conversation history. The reviewer returns a structured verdict (approved, changes requested, rejected) with evidence.

Review carries its own failure modes. The reviewer can produce false positives (approve bad work) or false negatives (reject correct work). These are semantic failures and are hardest to catch in production. The harness can mitigate this by running multiple reviewers or by using a separate eval model that samples review decisions offline. For observability, log every review decision along with the confidence score, if available, and tag it with the trace ID of the original delegation.

Eval isolation for reviews is subtle: the review itself must have no side effects. Never allow the reviewer to modify state. Store the review parameters and outcome for later replay—you’ll need them to debug a false negative without gating the whole pipeline. Retry budgets apply here too: if a review times out, decide whether to fall back to a default (approve?) or fail the task. Cost per review is often high because it doubles the LLM call count. Track it as a separate line item in your cost/latency dashboard.

Supervisor Loops

The supervisor pattern adds a control layer that observes multi-step workflows and decides when to adapt. A supervisor agent is not a worker; it is a state machine that polls task status, checks invariants, and issues interventions (e.g., reassign a task, escalate, abort). Keep the supervisor itself stateless—persist its decision history to the harness store so it can be replayed or recovered after a crash.

Supervisor loops introduce latency per cycle. If the supervisor polls every N seconds, that is N seconds of agent downtime. Design the polling interval as a configuration parameter governed by a circuit breaker: if the supervisor fails