When one agent isn't enough
A single agent juggling research, coding, writing, and reviewing all at once tends to lose the thread — its context fills with mixed concerns and its tool selection gets muddled. Multi-agent systems split the work across several specialised agents, each with a focused role, a small toolset, and its own context. A common shape is an orchestrator (or manager) agent that decomposes the goal and delegates sub-tasks to worker agents — a researcher, a coder, a critic — then assembles their results.
Specialisation helps, but coordination costs. Agents must pass results cleanly, avoid duplicating work, and reconcile disagreements — and every extra agent multiplies tokens, latency, and the number of ways the whole thing can go sideways. Reach for multiple agents when a job has genuinely distinct sub-roles; for a linear task, one well-built agent with a good loop is simpler and usually better.
Orchestration frameworks: the wiring
You could hand-write the loop, the tool dispatch, the memory store, the retries, and the agent-to-agent message passing. An agent orchestration framework gives you these as reusable parts so you write the logic of your agents, not the plumbing. Frameworks typically supply: a loop runner, a tool registry, memory backends, structured handoffs between agents, and observability — traces and logs that let you see, after the fact, exactly what each agent thought and did.
Frameworks and the Model Context Protocol complement each other neatly: MCP standardises how an agent connects to a tool, while the orchestration framework standardises how agents are run and coordinated. Together they let you assemble a system from interchangeable tools and reusable agent patterns instead of one tangled bespoke script.
Shipping agents to production
A demo agent and a production agent differ enormously. In production every loop is real money and real latency, tool calls touch real systems, and untrusted inputs from the web are constant attack surface. The robustness from Guide 4 — bounded loops, error recovery, grounded reflection — becomes mandatory, and you wrap the whole thing in monitoring so you notice failures before your users do.
An MLOps lifecycle loop: deploy, monitor, detect drift, retrain, then redeploy.
- Set hard limits — max steps, timeouts, and a spend cap — so no single run can run away.
- Keep dangerous tools behind a human-in-the-loop gate; let only safe, reversible actions run unattended.
- Treat all tool and web output as untrusted data to guard against prompt injection.
- Log every thought, action, and observation; evaluate the agent on real tasks before and after each change.
- Roll out gradually — shadow runs and a small slice of traffic first — and watch the traces closely.
Where this is heading
You now have the whole arc: an LLM agent is a model in an observe–think–act loop; tool use and function calling give it hands; ReAct, planning, and memory give it method; reflection, recovery, and human oversight give it reliability; and multi-agent orchestration scales it up. Each layer trades raw autonomy for control, and the engineering job is to choose how much of each a given task actually needs.
The honest frontier: today's agents are impressive yet brittle — strong on short, well-scoped tasks, shakier the longer and more open-ended the goal. The craft is not chasing maximum autonomy but matching the agent's reach to the task's stakes, and building in the loops, limits, and human checkpoints that let you trust it with real work.
Why longer agent loops grow brittle: end-to-end success is the product of each step's reliability, so it falls off fast as the number of steps n grows.