Some jobs are too big for one agent. Producing a competitor analysis means researching several companies, summarising each, and assembling a comparison; doing all of that in a single agent stretches it thin and makes failures hard to isolate. The answer is to chain agents: let a few specialised agents each own a piece, and coordinate them. Done well, this is how agents handle genuinely complex work. Done carelessly, it turns one reliable agent into a tangle of brittle parts.

This tutorial covers when to chain agents, how to wire them sequentially or in parallel, how to design the handoffs that make or break a chain, and how to test the whole thing. It assumes you can already build a single chain of steps from how to build a multi-step agent workflow, and it applies the orchestration theory from AI agent orchestration explained.

One agent or many

The first decision is whether you need more than one agent at all, and the default answer is no. A single well-built agent with the right tools handles most tasks, and every agent you add brings coordination overhead, more latency, more cost, and more places to fail. The bar for chaining is simple: the task has distinct sub-jobs that need different skills or tools, and trying to do them in one agent makes it unreliable.

Competitor analysis clears that bar. Researching a company, summarising findings, and assembling a comparison are genuinely different jobs, and a single agent switching between them loses focus and context. A weekly status email does not clear the bar; it is one job and one agent. When in doubt, start with one agent, and split only when you can point to a specific sub-job that the single agent keeps getting wrong. The single-versus-many trade-off is laid out in single agent vs multi-agent.

Sequential vs parallel

Once you have decided on multiple agents, there are two ways to chain them, and the choice follows the structure of the task. Sequential chaining runs agents one after another, where each depends on the output of the one before. Parallel chaining runs independent agents at the same time and combines their results at the end.

When to run agents in sequence

Use sequential chaining when a later step genuinely needs an earlier result. A research agent must finish before a writing agent can summarise its findings; there is no way to parallelise a true dependency. Sequential chains are easy to reason about because the flow is linear, but they are only as fast as the sum of their parts, and a failure early in the chain blocks everything after it.

When to run agents in parallel

Use parallel chaining when sub-tasks are independent. Researching three competitors is three separate jobs with no dependency between them, so three agents can run at once and a coordinator merges their findings. Parallelism cuts wall-clock time sharply, but it adds the work of fanning out the tasks and fanning the results back in, and you have to handle the case where one branch fails while others succeed. Most real chains mix both: parallel where tasks are independent, sequential where they depend on each other.

Designing clean handoffs

The handoff, the moment one agent passes work to the next, is where multi-agent systems most often break. If the research agent passes a wall of raw notes and the writing agent expected a structured summary, the chain fails not because either agent is bad but because the boundary between them was undefined. A clean handoff specifies exactly what is passed, in what shape, and what the receiving agent can assume about it.

Make the handoff a contract

Treat each handoff as a contract, the same way you would a function's inputs and outputs. The research agent promises "a list of findings, each with a source and a one-line summary"; the writing agent relies on exactly that. When both sides agree on the shape, either agent can be improved or replaced without breaking the other. This is the same discipline as the per-step checks in a single workflow, scaled up to agent boundaries, and it draws directly on the patterns in AI agent handoff patterns.

Sharing context

Chained agents need to share some context, but sharing too much is as damaging as sharing too little. Pass the entire history to every agent and you blow up cost, slow each step down, and bury the relevant facts in noise, the lost-in-the-middle problem from AI agent context window management. Pass too little and the receiving agent lacks what it needs. The rule is to pass the slice each agent requires and nothing more.

Who owns the shared state

In a well-designed chain, one component owns the shared state and decides what each agent sees, rather than every agent reading and writing a common blob. That owner is usually the orchestrator. Centralising the state keeps the workers focused on their job and makes the system easier to debug, because there is one place to look when context goes wrong. The mechanics of who-holds-what across steps are covered in AI agent state management.

Adding an orchestrator

Beyond two or three agents, you want a coordinator. An orchestrator is an agent whose only job is to manage the others: it breaks the goal into sub-tasks, hands each to the right worker, decides what runs in sequence and what runs in parallel, merges the results, and handles failures. The workers stay simple and specialised; the orchestrator carries the complexity of coordination. This is the orchestrator-worker, or supervisor, pattern.

Keep the orchestrator thin

The temptation is to let the orchestrator also do real work, but that muddies its job and makes the whole system harder to follow. Keep it thin: it routes, sequences, and assembles, while the workers do the actual tasks. A thin orchestrator with focused workers is far easier to debug than a fat one that both coordinates and does. The deeper coordination patterns, including how supervisors avoid becoming bottlenecks, are in AI agent multi-agent coordination.

Testing a chain

Test a multi-agent chain from the inside out. Prove each agent alone first, so you know the worker is sound. Then test each handoff, feeding the upstream agent's real output into the downstream agent to confirm the contract holds. Only then run the full chain on safe test data, watching for the failure that hides between agents rather than inside them. Multi-agent bugs love the gaps, so the gaps are where your testing should concentrate.

Watch the failure between agents

The hardest multi-agent failures are not crashes; they are silent context losses where the chain completes but the output is subtly wrong because something was dropped at a handoff. Catch these by checking the final result against the original goal, not just confirming each agent ran. Once the chain behaves on test data, the go-live gate is the same as for any agent, covered in how to test an agent before going live.

Frequently asked questions

When should you chain multiple agents instead of using one?

Chain multiple agents only when a task has distinct sub-jobs that each need different skills or tools, and one agent juggling them all becomes unreliable. If a single well-built agent can hold the task, use one. More agents add coordination overhead, latency, and cost, so reach for chaining last.

What is the difference between sequential and parallel agent chaining?

Sequential chaining runs agents one after another, where each depends on the previous result. Parallel chaining runs independent agents at the same time and merges their outputs. Use sequential when steps depend on each other, and parallel when sub-tasks are independent, like researching three competitors at once.

What is an agent handoff?

A handoff is the moment one agent passes work to another, including the data and context the next agent needs. A clean handoff defines exactly what is passed and in what shape. Most multi-agent failures happen at handoffs, where context is lost or the receiving agent gets something it cannot use.

How do chained agents share context?

They share context through an explicit hand-off payload or a shared store that each agent can read. The key is to pass only what the next agent needs, not the entire history, which keeps each agent focused and controls cost. An orchestrator usually owns the shared state and decides what each worker sees.

Do buyers need to chain agents themselves?

No. On a platform like Gravity, the builder decides whether a task needs one agent or several and wires the chain. You describe the outcome. Knowing how chaining works still helps you judge whether a complex agent is built sensibly or has been over-split into fragile parts.

Three takeaways before you close this tab

Sources