This is a starter post. Replace this content with your own. It’s here to show the frontmatter fields (title, description, date, tags) and general structure a technical post can follow.
The core question
Before picking an orchestration pattern, the real question is: how much autonomy does this task actually need? Most production failures I see come from teams reaching for a fully autonomous multi-agent loop when a single well-scoped agent (or even a deterministic pipeline with one LLM call) would have been more reliable and easier to debug.
Common patterns
1. Single agent, tool-augmented
One model, a fixed set of tools, a loop until it produces a final answer or hits a step limit. Simple to reason about, simple to evaluate, and usually the right default.
Use when: the task has a clear success condition and a bounded set of tools.
2. Planner–executor
A planning step decomposes the task into subtasks; a separate execution loop (often a simpler, cheaper model) carries each one out. This trades some latency and cost for better decomposition on multi-step tasks.
Use when: tasks are long-horizon and benefit from an explicit plan you can inspect or edit before execution starts.
3. Supervisor with specialist sub-agents
A coordinating agent routes work to specialist agents (e.g., a research agent, a code agent, a writing agent), each with its own tools and context. Powerful, but failure modes compound: a bad handoff between agents is harder to catch than a bad tool call.
Use when: the specialists have genuinely different tool sets or context requirements, not just different prompts.
What actually determines reliability
In practice, orchestration topology matters less than:
- Tight tool contracts: clear inputs/outputs, explicit error states the model can act on.
- Observability: being able to see every step, tool call, and intermediate state, not just the final output.
- Bounded autonomy: step limits, budget limits, and human checkpoints at the right places.