Architecture

AI Workflow Design: Five Patterns for Multi-Step Agent Processes

By IdeaBosqueLast updated: September 1, 2026

Key takeaways

MCP tool calls through OpenAI reached 98x their January level by August 2026, more than doubling in August alone (AAIF) — a single user request now triggers a workflow of many calls, which makes workflow design, not prompt design, the production discipline.
Gartner predicts AI inference costs per agentic workflow will increase more than fivefold through 2028 — per-token prices fall while per-workflow costs rise, because agentic workflows consume orders of magnitude more tokens than chat.
The MCP roadmap reworked Tasks into an official extension (SEP-2663) and added Multi Round-Trip Requests (SEP-2322) so multi-step flows survive on stateless servers — the protocol now assumes work runs long and spans rounds.
OpenAI states its misalignment monitors may pause "tasks in which an agent is running for an extended period," and API tasks stop rather than resume — a production workflow must be resumable from durable state, not from a live process.
A 38-tool RFQ module runs every one of these patterns in code — guard-enforced status transitions, idempotent hold release on a 15-minute TTL, and FX snapshots frozen at quote time.

MCP tool calls from ChatGPT users reached 98 times their January level by August 2026, according to the Agentic AI Foundation's usage analysis — and the calls more than doubled during August alone. Resend's MCP traffic tells the same story from the provider side: 106,719 calls in April, 1,062,650 in August. The protocol's own maintainers draw the operating conclusion in the new MCP roadmap: "Modern agentic workloads no longer fit the standard request-and-response pattern. Loops can run for longer, servers can push streamed results, and there is a clear need to steer work mid-flight."

The chat was never the hard part. The workflow is: the fan of catalog lookups behind one RFQ, the approval that must arrive before an ERP write, the supplier API that times out mid-quote, the currency rate that must not drift between pricing and booking. Gartner projects per-workflow inference costs will rise more than fivefold through 2028 even as per-token prices fall, because agentic workflows reason, negotiate, and re-question themselves across many calls. This article defines the five workflow-level patterns that decide whether a multi-step agent process holds up under that load — fan-out, checkpoints, compensation, durable state, and measured branching — and grounds each in a working RFQ implementation that registers 38 MCP tools against a GraphQL backend.

The workflow is the unit you design. The diagram below compresses the five patterns into one minute: the parallel read fan-out, the serialized write spine with its two human gates, the typed compensation on failure, and the durable-state rule that ties them together.

Pattern 1: Fan out reads, serialize writes

The first workflow decision is the shape of the dependency graph. Most multi-step agent processes are mostly parallel: an RFQ needs price tiers from three supplier catalogs, batch availability for five line items, and the customer's segment — none of which depends on the others. Serializing those steps multiplies latency by step count and multiplies the blast radius of any single timeout. The correct default is to fan out every independent read in parallel and serialize only the write chain, where each step consumes the previous step's output.

The write chain in a quoting workflow is strictly ordered for a business reason, not a technical one: request confirmed → quote created → availability held → installments scheduled. Our RFQ engine enforces this with operation guards in code — a RequestOperationGuard refuses to create quotes from an unconfirmed request, and a QuoteOperationGuard refuses item modifications once a quote passes its editable window. The workflow pattern is the same across systems: parallel reads behind a batch loader, a narrow serialized spine for state-changing writes, and the guards in code rather than in the prompt. An agent that "decides" the ordering each run is a workflow with no invariants.

Pattern 2: Human checkpoints are states, not prompts

The second pattern governs where the human sits. In a prompt-only design, "ask the user before submitting" is a suggestion the model may follow or not. In a workflow design, the checkpoint is a durable state: the process halts in a named status, persists everything needed to continue, and only a human action transitions it forward. The distinction became operationally urgent on September 1, when OpenAI disclosed that its production misalignment monitors can automatically stop potentially unauthorized activity — and honestly flagged the cost: safeguards "can occasionally flag legitimate activity as potential cyber misuse... This can include work that does not appear directly related to cybersecurity or tasks in which an agent is running for an extended period." In ChatGPT and Codex, users are asked to review the paused task; on the API, the task stops.

A workflow built for that world treats the pause as a designed state, not an exception: the run record shows what completed, what is pending, and what the resume path is. Our RFQ engine's two convenience tools — confirm_request_and_create_quotes and confirm_quote_and_create_installments — exist precisely because the human gate sits between them: a human confirms, then the multi-step mechanical work runs as one audited call. Camunda's survey of 1,150 senior IT leaders found 71% of organizations use AI agents but only 11% of use cases reach production; the workflows that cross that gap are the ones where an approval is a status the system can sit in for hours, not a sentence in a system prompt. The runtime-layer mechanics of enforcing checkpoints live in Loop Engineering: Why the Agent Runtime Is the New Middleware; the workflow pattern is deciding, before anything ships, which steps halt for a human and what state the process resumes from.

Pattern 3: Every forward step needs a compensation path

The third pattern is the one tutorials skip: what undoes a step. Long-running workflows fail mid-flight — a supplier API returns an error on line item four of five, a hold expires while the agent is pricing, a quote is approved but payment scheduling fails. A workflow without compensation chains converts each failure into manual cleanup. A workflow with compensation converts each failure into a typed, idempotent reverse operation.

The quoting implementation shows the anatomy. Availability holds expire on a 15-minute TTL, and the failure surface is enumerated as typed errors — HOLD_NOT_FOUND, HOLD_ALREADY_EXPIRED, AVAILABILITY_INSUFFICIENT — each mapping to a distinct recovery: re-check, re-acquire, or route to a human. Releasing a hold is idempotent, so a retry after a network partition cannot double-release, and confirming a hold never decrements twice. Tool calls wrap in a retry decorator with exponential backoff, and every call's status, duration, and payload (offloaded to object storage above 400KB) lands in an audit record. That is the pattern generalized: forward steps acquire resources; compensation steps release them; every compensation is safe to run twice. If your workflow cannot name the undo for each step, it does not have a workflow — it has a demo that has not met a supplier outage yet.

Pattern 4: Stateless protocol, stateful workflow

The fourth pattern resolves an apparent contradiction in the 2026-07-28 MCP specification. The spec removed protocol-level sessions and the initialization handshake (SEP-2575, SEP-2567) so servers scale horizontally without holding state, and the roadmap reworked Tasks into an official extension (SEP-2663) while Multi Round-Trip Requests (SEP-2322) replaced server-initiated requests so elicitation flows still work mid-task. The protocol is stateless; the workflow is the thing that carries state. Concretely: every request must arrive self-contained, and the workflow's state lives in durable, inspectable records — not in a server's memory.

That architecture choice is what makes the pattern above survivable. In our RFQ engine, the hold's hold_token and hold_expires_at sit directly on the quote line item, and the FX rate is frozen with a fx_rate_locked_at timestamp at quote time — snapshots, not live references. Any server instance can take the next request; a restarted process resumes from the record, not from RAM. And the Astra caveat makes resumability a platform-interaction requirement, not just crash tolerance: if a frontier-model safeguard pauses your 38-hour unattended run, the workflow that survives is the one that kept its state outside the process. We cover the deployment mechanics of the stateless spec in The MCP Stateless Protocol: What Changes for B2B Deployments; at the workflow level, the rule is simple — design as if any step can be the last one before a pause, and make the next step reconstructable from the audit trail.

Pattern 5: Branch on measured data, not model judgment

The fifth pattern governs conditional branches. A multi-step workflow contains decision points — is this line item profitable enough to quote, does this batch move slowly enough to flag, does this customer segment unlock a discount tier. Letting the model improvise those branches re-introduces variance into the one place deterministic behavior matters. The workflow answer is measured gates: the data carries the flags, and the branch reads them.

In the RFQ engine, each quote line item carries guardrail_price_per_uom and slow_move_item loaded from the batch record — so the branch "quote at list price" versus "flag for margin review" reads two fields instead of asking the model to estimate margin. Discount rules compose from four hierarchical scopes (global, segment, item, provider item) as data, not as reasoning steps. This is also where workflow design meets cost: Gartner's inference analysis warns that "routing a task to an agentic reasoning model increases provider inference costs by at least five times" versus a basic interaction, and recommends "highly optimized inference-tiering, routing and orchestration." A workflow that branches on stored flags reserves model reasoning for the steps that need it — pricing judgment, exception interpretation, negotiation drafting — and lets typed data decide the rest. The same discipline shows up in data platforms, where Dagster's orchestration context work treats materialization events as the operational context a workflow consumes rather than re-derives.

The five patterns, in one line each

Fan out reads, serialize writes — the shape is a business invariant, so encode it as guards. Checkpoints are states the system can sit in, because the platform itself will pause you. Compensation is a first-class step for every forward step, idempotent by construction. State lives in durable records, not in the protocol or the process. Branches read measured flags, reserving model reasoning for the steps that price it in. None of these patterns requires a framework migration; all of them require deciding, per step, who owns it — the model, the runtime, or a human.

A representative build

A mid-market tour operator running 200 group-booking RFQs a week across hotels, flights, and activities rebuilt its quoting workflow on these patterns. Reads fan out in parallel — five catalogs, batch availability, price tiers — through a single MCP module exposing 38 tools across 11 domain mixins, with each tool's schema typed and every call audited. The write spine serializes: request confirmed, quote assembled with FX locked at quote time, holds acquired with a 15-minute TTL and idempotent release, installment plans scheduled. Two human gates sit where the money commits — request confirmation and quote confirmation — and each gate is a persisted state the process can wait in for hours. When a supplier API times out mid-pricing, the typed error routes the line item to re-check rather than corrupting the quote. Quote turnaround dropped from three days of manual lookups to under four hours, with every write human-approved. The outcome is quoting capacity for a lean team, not headcount replacement.