Orchestration patterns

How multiple agents (or one agent + many tools) coordinate to complete a task.

The four common patterns

1. Supervisor

One “manager” agent routes work to specialist agents. Used when the inbound query type is unpredictable.

Shipsy uses it for: every multi-agent deployment (BDO, Adani). The supervisor sits between channels and the specialist agents.

2. Sequential

A → B → C. Each agent’s output is the next agent’s input. Used when steps are ordered.

Shipsy uses it for: doc → extract → validate → reconcile pipelines (e.g. Nexa’s POD validation).

3. Parallel

Fan out → fan in. Multiple agents work on the same input simultaneously; an aggregator combines.

Shipsy uses it for: ensemble reasoning (rare today) and parallel data fetches behind a single response.

4. Human-in-the-loop

Agent acts when confident, escalates to human when not. Always present in production deployments.

Shipsy uses it for: every agent. See Guardrails.

Why we use LangGraph specifically

LangGraph models orchestration as a graph of states, not a chain of calls. That matters because agents loop, branch, wait for input, and return to earlier states. Chains can’t express that cleanly.

If you’ve used n8n or Zapier, LangGraph is conceptually similar — nodes + edges + state — but designed for LLM workflows specifically.

For the implementation, see Architecture and the agent-platform repo.

Anti-patterns

• One mega-agent that does everything. Hard to evaluate, hard to debug. Decompose into specialists with a supervisor.
• Agents calling each other recursively without a state limit. Will loop forever. Always set max-depth.
• Sequential pipelines where each step is itself an LLM call when it doesn’t need to be. Expensive and slow. Use a rule or a deterministic tool when you can.

Sources

• LangGraph docs
• See architecture sections of BDO and Carrix decks for live examples

Changelog

• 26 May 2026: Initial draft.