Deterministic execution order with shared session state flowing data between specialized sub-agents via output_key and template variables.
The Sequential Agent Pattern — Deep Dive · 5 minsTranscript8 entries
Instructor:A single agent handles everything, but it can't guarantee execution order. When step two depends on step one's output, that unpredictability becomes the real problem, and the sequential pattern exists by hard-wiring the pipeline. And you're about to see exactly how. Let's understand using a very simple problem. A trip request comes to the orchestrator. Unlike a single agent, this one doesn't decide the order, it enforces it. Every single time, no variation. Here's the thing, the orchestrator isn't even an LLM,
Instructor:it's a workflow primitive that just walks through some agents. In the particular given order, the food finder always first, the transport agent always second, that's the determinism, and that's the whole point. Without knowing what restaurant we are visiting, we cannot plan our transport, and that's the whole idea of sequential. So the food finder goes out and searches for restaurants matching your criteria. Now here's a critical detail, it writes the output to the session state using an output_key.
Instructor:That's how the data gets to the next stage. The transport agent picks up the original request plus the food result from the session state. It's in the instruction as a template variable. In this stage, food_results, and the framework swaps that placeholder with the real data before the LLM ever sees that. The orchestrator assembles the final trip plan. Once both specialists are done. Predictable, traceable, and reliable, but you can't skip steps or reorder at runtime, and that's the trade-off.
Instructor:So what do you get, in simple words? Deterministic execution, same input, same path every time, observability. You can trace exactly which stage it runs, what it wrote, where it wrote, and focused prompts. Each agent gets a tight, narrow instruction instead of its own bloated mega-prompt. There are many good examples we can think of, such as loan applications, governmental processes. They all do deserve sequential execution. However, there are many use cases where a simple agent could be sufficient.
Instructor:But a sequential agent does provide certain guarantees over a single agent. Let's see that in practice. So here I've got this in VS Code, and I'm going to execute a simple example. The server is already running. So this is our sequential agent server, which is for food finder and transport, and handled by the orchestrator. And the client is going to call the code for this particular example available on GitHub. You can clone this folder and try it yourself. So I'm just running a client, and it's going through.
Instructor:Well, that's finished. So based on what we want, it identified the food recommendation and based on that, it has just come back with some transport plan. By the way, this is just to demonstrate a pattern. So it's not a full-featured example that someone can use straight into a traveling website. However, this is a very good stepping stone to understand the pattern and then build on top of it. The current example uses Ollama.
Instructor:It is a very minimal LLM, just to demonstrate and understand the learning pattern and its purposes. But here's the cost. The pipeline runs every stage every time, even if this step isn't needed for a particular input. There is no branching. It's A, B, C, not X, then Y, etc. In that kind of routing, you need a coordinator, and the latency and total time is the sum of all stages with no overlaps. If your substeps are independent and speed matters, maybe parallel is a better fit.
Instructor:That's the sequential pattern in its nature: deterministic, observable, reliable, and it costs you flexibility and speed. Next time we'll see parallel agents, where you can trade the strict order for concurrent execution on independent subtasks. Thank you.
Learning Objectives5
Define the sequential agent pattern and explain deterministic execution order
Describe how shared session state enables data flow between pipeline stages via output_key
Identify the trade-off between reliability and flexibility that sequential pipelines introduce
Recognize when sequential is the correct choice versus single agent or parallel architecture
Evaluate failure modes: rigidity, inability to skip steps, latency accumulation
Setup Instructions
0/3
Clone the repository
Clone the course repository to your local machine to follow along with the code examples.
bash
git clone https://github.com/nilayparikh/tuts-agentic-ai-examples/tree/main/agents/mono/agent-design-patterns-1/02-sequential-agents
cd $(basename https://github.com/nilayparikh/tuts-agentic-ai-examples/tree/main/agents/mono/agent-design-patterns-1/02-sequential-agents)
Create a virtual environment
Create an isolated Python environment for the project dependencies.
bash
python -m venv .venv
source .venv/bin/activate # or .venv\Scripts\activate on Windows
Install dependencies
Install all required packages from the requirements file.
How do sequential agents share data between steps?
Through shared session state. Each sub-agent writes its output using an output_key parameter. The next sub-agent reads that value via template variables (curly braces) in its instruction prompt. This acts as short-term memory within the pipeline.
Q
Can a sequential pipeline skip a step conditionally?
Not natively. The SequentialAgent always runs all sub-agents in order. To add conditional logic, you need a coordinator agent or custom orchestrator that evaluates a condition and routes to different sub-agents based on the result.
Q
What happens if a sub-agent fails mid-pipeline?
Subsequent stages receive incomplete or missing data from session state. The pipeline does not automatically retry or skip. You need explicit error handling — either in the sub-agent's instruction or through framework callbacks — to handle failures gracefully.
