Multi-Agent Orchestration Patterns: Moving Beyond Basic Prompt Chains

Prompt chains — a fixed sequence of LLM calls — are brittle. Real workflows branch, loop and fail. Multi-agent systems promise flexibility, but without structure they become unpredictable and expensive. The answer is explicit orchestration patterns with typed state.

Pattern 1: Supervisor and workers

A supervisor agent routes tasks to specialized workers (retrieval, SQL, code execution) and aggregates results. Workers have narrow tool sets, which reduces error surface and simplifies permissions.

Pattern 2: Planner–executor

A planner produces a structured plan; an executor carries out steps deterministically, calling the LLM only where judgment is needed. Re-planning occurs on failure.

class State(TypedDict):
    goal: str
    plan: list[Step]
    results: dict[str, Any]
    attempts: int

graph.add_node('plan', planner)
graph.add_node('execute', executor)
graph.add_node('verify', critic)
graph.add_conditional_edges('verify', lambda s: 'done' if s.ok else 'plan')

Pattern 3: Critic / verifier

A separate agent — ideally with different instructions or even a different model — validates outputs against schemas, business rules or retrieved evidence. Deterministic checks (JSON schema, SQL dry-run) should run before LLM-based critique.

Memory management

• Working memory: the typed state object passed between nodes.
• Episodic memory: summaries of prior runs retrievable by similarity.
• Semantic memory: curated facts in a governed knowledge store.

Guardrails and observability

Cap iterations and token budgets per run, require human approval for irreversible actions, and trace every step with inputs, outputs and tool calls. Replayable traces turn agent debugging from guesswork into engineering.