Multi-agent orchestration patterns.

The session

Multi-agent orchestration patterns.

Multi-agent orchestration is what happens when one agent is not enough. A single agent can plan and execute a single task. When the work splits — research, then draft, then review, then send — the natural shape is multiple agents, each owning one stage. The shape of the orchestration is the difference between a system that works and a system that has three agents all stuck waiting for each other.

The three patterns that work in production are: relay (agent A passes a result to agent B, B to C, and so on), parallel (multiple agents work on different parts of the same task at the same time, and a coordinator merges the results), and supervisor (a supervisor agent dispatches work to worker agents, observes the results, and decides what to do next). Each pattern has a different latency profile, a different failure profile, and a different cost profile. The right pattern depends on the work.

Relay is the simplest. The work is sequential. Each agent does its part, hands off to the next. The latency is the sum of the agents. The failure mode is a single agent breaking the chain — the system stops. The fix is a checkpoint: each agent writes its output to durable storage, and the next agent reads it. The system can be resumed from any checkpoint. Relay is the right pattern for workflows where each step genuinely depends on the output of the previous step (a research agent that hands a brief to a writing agent that hands a draft to a review agent).

Parallel is the fastest. Multiple agents work on independent parts of the same task, and a coordinator merges. The latency is the slowest agent, not the sum. The failure mode is inconsistency between the parallel agents — they disagree about the format, the assumptions, the level of detail. The fix is a shared schema for the outputs and a coordinator that validates every output against the schema before merging. Parallel is the right pattern when the work decomposes cleanly into independent parts (a research agent producing background, a data agent producing statistics, an interview agent producing quotes, all merging into a single brief).

Supervisor is the most flexible. A supervisor agent owns the goal, the plan, and the worker dispatch. The supervisor can change the plan mid-execution if a worker fails. The supervisor can re-task a worker with a different prompt if the output is wrong. The latency depends on the work. The failure mode is the supervisor getting stuck in a loop — dispatching the same work, getting the same wrong result, dispatching again. The fix is a hard limit on retries and an explicit escalation to a human after the limit.

In Netwit Agentic OS, all three patterns are first-class. A blueprint can be relay, parallel, or supervisor, and the runtime tracks the orchestration state, the audit trail of which agent was called when, and the cost of each call. The audit trail is what makes the system auditable in a regulated environment — the regulator can ask "who decided this" and the answer is the agent ID, the prompt, the model, the tool calls, the result, and the human who approved.

The patterns that fail in production are: tightly coupled agents that share state (one agent's state corrupts the other's), agents that call each other recursively (infinite loop), and agents with overlapping responsibilities (both agents try to do the same work, you get conflicting outputs). The fix to all three is explicit contracts: the handoff between agents is a typed message, the recursion is bounded, and the responsibilities are disjoint.

The session walks through each of the three patterns with a worked example (a customer-support workflow, a content production workflow, a financial reconciliation workflow), the production failure modes, and the audit trail each pattern produces. The recording and the example blueprints are sent to all registrants.