Orchestration patterns: from a single loop to a graph | Cleon

"Orchestration" is just the answer to one question: when a request comes in, who decides what happens next? An agent that reasons, calls a tool, looks at the result, and reasons again is already orchestrating — that loop is a pattern, and for most jobs it is the only one you need. The patterns below are not a ladder you climb for sophistication points. They are answers to specific pressures — a job too big for one context, a step that must run deterministically, a request that should never have reached an agent at all — and each one buys its capability with cost, latency, and a wider failure surface.

The instinct from a slide deck is to reach for the most elaborate pattern. The instinct from production is the opposite: start at the simplest loop that could work, and only add structure when a real failure forces you to. This page covers the patterns that hold up, when each one fits, and what it costs you. The toolkit — Agentforce, LangGraph, the Claude API, MCP — is complementary; you compose these patterns with whichever instrument fits the job, you do not pick a camp (principle 7).

Single-agent loop

The default, and the one to beat. A single agent runs the reason → act → observe loop — the ReAct pattern: it reasons about the request, picks a tool, calls it, observes the result, and loops until it has an answer or hits a stop condition. One model, one context window, one set of tools, one place to look when it breaks.

When it fits: the overwhelming majority of agent work. If the task is one coherent job — answer a question over grounded data, complete a workflow with a handful of tools, draft something from context — a single loop does it with the least to go wrong.

Trade-off: lowest cost, lowest latency, highest debuggability — until the job stops fitting in one context. The loop degrades when the tool count grows past what the model can choose between reliably, when the task really has distinct phases that need different instructions, or when one context window can't hold everything the job touches. Those are the symptoms that justify reaching for more structure — not a desire to look sophisticated.

Supervisor / worker

One coordinator agent owns the request and delegates pieces to specialized sub-agents, each with its own narrower instructions and tools. The supervisor decides who does what, hands off the sub-task, collects the result, and decides the next move. The workers don't talk to each other — they report back up.

When it fits: a job that genuinely splits into specialties — a research step, a drafting step, a validation step — where keeping each worker's instructions and tools narrow makes each one more reliable than one agent juggling all of it. The supervisor holds the plan; the workers hold the focus.

Trade-off: every hop is another model call, so cost and latency climb roughly with the number of delegations, and the supervisor itself is a new failure point — a bad delegation decision misroutes the whole request. Worth it when narrow workers measurably outperform one overloaded agent; not worth it when you're just splitting one coherent job for the look of an org chart.

Multi-agent collaboration

Several agents with distinct roles working the same problem — not a single coordinator delegating down, but multiple agents contributing, sometimes critiquing or building on each other's output. This is the pattern that looks most impressive in a diagram and bites hardest in production.

When it fits: rarely, and only when one agent genuinely cannot hold the job — the problem needs distinct, simultaneous perspectives that don't collapse cleanly into a supervisor's plan. Most problems that look like they need a committee of agents are better served by one well-grounded agent, or by supervisor/worker with clear delegation.

Trade-off: this is where cost and failure surface grow fastest. Every agent is another context to get right, another set of tools to govern, another place the chain can break — and agents reasoning about each other's output compound errors instead of catching them. The latency is additive across the conversation, and the cost can run several times a single loop for the same task.

Graph-based orchestration

When you need deterministic control over a non-deterministic component, you stop letting the model decide the flow and you draw the flow yourself — as an explicit state machine. This is the LangGraph model: nodes (the steps — a model call, a tool call, a function), edges (the transitions between them, including conditional ones that branch on state), and a shared state object every node reads from and writes to as the run proceeds.

The point is control. A free-running loop decides its own next step every turn; a graph fixes the steps that must be fixed — validate here, branch there, always finish with this node — while still letting a node call a model where you want non-determinism. You get a replayable, inspectable path through the run instead of trusting the model to navigate every time.

When it fits: workflows with real structure — required steps, branching logic, retries, loops with a defined exit, a human-approval node in the middle — where "the model decides the order" is exactly the risk you need to remove. Once a job has more than a couple of decision points that must go a specific way, a graph turns implicit hope into explicit control.

Trade-off: the most control, the most upfront design. You define the nodes, the edges, and the state schema — more engineering before the first run than a loop ever needs. You spend that cost on purpose: when a step absolutely must run, or run in order, the determinism a graph gives you is worth more than the flexibility you give up.

Routing / handoff

Before any of the above, the cheapest move is often to not run an agent at all. A router classifies the incoming request and sends it to the right destination — a specific tool, a specialized agent, a deterministic workflow, or a human. The classification can be a small model, a rule, or a fast cheap call whose only job is to decide where the request goes.

When it fits: any system fielding a mix of request types where some don't need a full agent — an FAQ that a lookup answers, a request that belongs to a human, a category that maps straight to one tool. Routing keeps the expensive reasoning for the requests that actually need it, and it gives you a clean handoff to a person for anything the system shouldn't decide on its own (principle 9 — a human is accountable, and handoff is where that accountability gets a seam).

Trade-off: very low cost and latency for the routing step itself, and it reduces total cost by keeping work off the expensive paths. The risk is concentrated in the classifier: a misroute sends the request somewhere wrong, so the router's accuracy is the thing to evaluate hardest. A wrong route is cheap to run and expensive to be wrong about.

The managed-reasoning option: Atlas Reasoning Engine

Everything above assumes you own the planning loop. Agentforce offers the other shape: its Atlas Reasoning Engine is the managed planner — it handles the reason-and-plan step for an agent inside the Salesforce platform, deciding which actions and topics to use against governed data, so you wire up the tools, instructions, and grounding rather than the control loop itself. The trade-off is the usual managed-or-custom one: you give up some control over the loop and get planning, grounding to the Data 360 profile, and the platform's governance handled for you.

This is one instrument, not a rival to the rest. Atlas plans inside Salesforce where the work lives in the security model and needs governed, auditable actions; a LangGraph graph or a Claude API loop carries the work off-platform where you need a custom flow or a model Salesforce does not reach (principle 7). A real system often does both — Agentforce owning the in-platform actions, an external graph owning a step it can't — and they hand off to each other. The skill is composing them, not choosing one and defending it.

Choosing, briefly

Start at the single loop. Add a router when you're fielding request types that don't all deserve an agent. Move to supervisor/worker when narrow specialists beat one overloaded agent on a job that splits cleanly. Reach for a graph when a step must run deterministically or in a fixed order. Reach for multi-agent collaboration last, and only when you can name what one agent cannot do. Every step up the list buys capability with cost, latency, and failure surface — so take the step only when a real failure, not a diagram, is asking for it. None of this replaces the rest of the discipline: an orchestrated system still has to be grounded, evaluated, and traced, or the orchestration just fails in a more elaborate shape.

What is an agent — the model-plus-tools-plus-loop definition every pattern here orchestrates
Tools and actions — what the agents in these patterns actually call, and why each tool is a blast radius
External agents — the LangGraph and Claude API side, where graph-based orchestration lives
Agentforce agents — the managed side, where the Atlas Reasoning Engine plans for you
Debugging agents — how you trace a run once it spans more than one loop
Agent gotchas — the failure modes these patterns trade against
Agent Style Guide — the bar an agent clears before it ships
AI Engineering principles — compose the toolkit (7), a human is accountable (9), trace everything (11)

Reference: