Build sequential workflows for dependent steps

Learning objective

Build a sequential workflow when ordering and dependencies are correctness requirements. This lesson focuses on linear execution, data handoffs, and failure behavior rather than parallel, graph, or model-driven orchestration.

Core idea

Treat a sequential workflow as a chain of typed gates. Each stage must:

1. start only after its predecessor succeeds;
2. receive an output that satisfies an explicit contract; and
3. produce the precondition for the next stage.

The sequence is a correctness mechanism, not merely a scheduling preference. If stage C requires a value from B, and B requires a validated result from A, the orchestrator must enforce A → B → C. Do not rely on a model to infer that order.

Google Cloud’s agentic design-pattern guidance defines the sequential pattern as specialized agents executing in a predefined linear order, with one agent’s output serving as the next agent’s input. Use it for structured, repeatable processes whose route does not change between runs.

How it works

Define the dependency chain

For every stage, specify its required inputs, outputs, success condition, and permitted side effects. Add an ordering edge only when:

• a later stage consumes data produced by an earlier stage;
• an earlier stage establishes a required invariant, such as validation;
• business or security policy forbids a later action before an earlier check;
• two side effects must occur in a prescribed order.

Then place the stages in one fixed list. In Agent Development Kit (ADK), a SequentialAgent runs its subagents in their declared order. The workflow agent controls that order through predefined logic rather than another model call. The subagents can still use models, so their content can vary even though their execution order does not.

Make handoffs explicit

Do not make the next stage recover input from prose. Give each stage a named output with a defined schema, and validate required fields before starting its consumer. Prefer immutable stage outputs, such as validated_invoice, over one shared object that every stage edits.

ADK sequential subagents share the same invocation context. A subagent can use an output_key to place its result in state, and a later subagent can read that key. The ADK state documentation distinguishes temporary invocation state from state that persists across invocations. Use a durable store or persistent session service when the workflow must survive a process restart; ordering alone does not provide durability.

Define failure before the happy path runs

For each stage, choose one explicit result:

• success: validate the output and continue;
• retryable failure: retry that stage within a limit;
• non-retryable failure: stop the sequence and return a typed error;
• compensated failure: run a defined recovery action for an earlier side effect, then stop.

Never let a missing or malformed prerequisite become an empty prompt for the next agent. Fail closed at the boundary. Record the workflow ID, stage name, attempt number, input reference, output reference, and status so that operators can reconstruct the trajectory.

Retries require special care. A timed-out action might have completed even when the orchestrator did not receive its response. Make side-effecting operations idempotent where possible: repeating the same request has the same effect as running it once. An idempotency key can help a service recognize a duplicate. Apply bounded retry policies that distinguish idempotent from non-idempotent steps. Google Cloud Workflows documents this distinction in its retry guidance.

Key distinctions and trade-offs

A sequential workflow improves predictability and auditability. It can reduce orchestration cost because a model does not choose every transition. The trade-off is rigidity: stage latencies accumulate, and one slow or failed stage blocks all downstream work. Extra stages also add model calls and handoffs.

Strict order is not the same as deterministic output or transactional execution. Model-based stages can produce different valid outputs for the same input. A sequence also does not automatically provide exactly-once delivery, rollback, durable checkpoints, or safe retries. Build those properties explicitly when the business process requires them.

Architecture / decision scenario

An accounts-payable system processes emailed invoices with four specialists:

1. The extraction agent converts the document into a structured invoice.
2. The validation agent checks required fields, arithmetic, and vendor identity.
3. The matching agent compares the validated invoice with its purchase order and receipt.
4. The recommendation agent prepares an approval package from the validated invoice and match result.

The team chooses a sequential workflow because every stage establishes a precondition for the next. Matching unvalidated fields could associate the wrong purchase order. Preparing a recommendation before matching completes could omit a discrepancy.

Each stage writes a separate typed result. The orchestrator validates it and records completion before invoking the next stage. If extraction is uncertain, the sequence stops with a review-needed status. If a read-only matching call fails transiently, the orchestrator retries it within a bound. It does not restart extraction or duplicate a downstream approval action.

Running all four agents in parallel would reduce latency but violate data dependencies. A graph would add unnecessary control-flow complexity because the successful route is always the same. If future policy introduces different paths for purchase-order and non-purchase-order invoices, that change is a signal to reconsider the linear design.

Common exam traps

• Choosing parallel execution because it is faster when later stages require earlier outputs.
• Assuming a fixed execution order makes model-generated content deterministic.
• Passing handoff data only through natural-language history instead of a named, validated contract.
• Retrying the whole sequence after one timeout and duplicating completed side effects.
• Treating shared in-memory or invocation state as a durable checkpoint.
• Choosing a sequential list for a process that requires conditional branches or joins.
• Adding agents for steps that deterministic code or validation can perform more reliably and cheaply.

What to remember

• Use a sequence when order is part of correctness, not merely presentation.
• Model each stage as a gate with explicit inputs, outputs, and success criteria.
• Let fixed orchestration choose the next step; do not delegate required order to a model.
• Stop on invalid prerequisites, and design bounded, idempotency-aware retries.
• Deterministic control flow does not guarantee deterministic outputs, durability, or exactly-once side effects.

Knowledge check

References

• Google Cloud Architecture Center, Choose a design pattern for your agentic AI system
• Agent Development Kit, Sequential template workflow agent
• Agent Development Kit, State: The session’s scratchpad
• Google Cloud Workflows, Retry steps