Research-backed calculator guide

Agent Workflow Orchestration Cost: State Machine, Queue or In-Code Loop?

Compare workflow orchestration cost across state machines, queues, and in-code loops using transition, replay, retry, and durability assumptions you can audit.

What “state machine versus code” actually compares

A state machine represents progress as explicit states and transitions. A managed service can persist history, pause, resume, retry, and expose execution details. AWS Step Functions, for example, says Standard Workflows charge for each state transition, including additional transitions created by retries. Its Express Workflows instead charge for requests and duration, with duration rounded to 100 ms and memory billed in 64-MB chunks. ^[1]

An in-code loop keeps the control flow in a function or worker. That can remove a separate orchestration meter, but the function still needs a policy for timeouts, partial success, idempotency, retry backoff, and a crash after step two but before step three. “Free orchestration” therefore means “no separate coordinator price in this estimate,” not “free execution.”

A queue chain sits between those choices. Each hop can make work independently retryable and horizontally scalable, but the bill now includes message operations, queue retention, consumers, dead-letter handling, and observability. Queue count is not a universal unit: providers and configurations differ, so use the relevant vendor price sheet rather than borrowing a Step Functions rate.

The business question is also different from the implementation question. A state machine can coordinate a process while a separate domain state machine tracks whether an order is paid or shipped. Conversely, workflow-as-code can provide durable orchestration without asking developers to maintain a large JSON or YAML transition graph. The architecture should make the failure and cost boundaries explicit.

A practical cost model for agent workflows

Start with one execution trace, not an average monthly bill. Count every coordinator event that can be charged: start and finish events where the provider counts them, task states, choice branches, waits, map iterations, callbacks, retries, and replays. Then record how often each path occurs. A happy path is not a monthly average if errors, human waits, or fan-out dominate production traffic.

For a provider-neutral worksheet, use these columns:

1. Volume: executions per month, fan-out items per execution, and expected failed or retried executions.
2. Durability unit: transitions, actions, messages, requests, or worker seconds.
3. Published rate: the vendor’s unit and region, with the date checked.
4. Task spend: model tokens, API calls, functions, containers, storage, logs, and review labor.
5. Reliability overhead: retries, replay, duplicate delivery, compensation, dead-letter processing, and recovery tests.
6. Operational value: history, pause/resume, exactly-once or at-least-once semantics, auditability, and time saved maintaining the mechanism.

Azure Durable Functions illustrates why “steps” alone are not enough. Microsoft documents that on the Consumption plan each orchestrator replay is a separate billable invocation, while billing pauses during an await or yield. It also identifies storage transactions and Durable Task Scheduler actions as separate cost areas. ^[3] A design with few business activities can still be expensive if it wakes and replays frequently.

Worked cost example

Assume a document-triage agent runs 1,000,000 executions per month. Each successful run has 12 Standard-style state transitions, and 8% of runs incur one additional retry transition. This is an estimate for comparison, not a vendor quote. It excludes model tokens, tool APIs, worker compute, data transfer, storage, and logs.

For AWS Step Functions Standard, the published US East example rate is $0.000025 per state transition, with 4,000 free transitions per month. ^[1]

• Base transitions: 1,000,000 × 12 = 12,000,000
• Retry transitions: 1,000,000 × 8% × 1 = 80,000
• Total transitions: 12,080,000
• Less stated free tier: 12,080,000 − 4,000 = 12,076,000 billable transitions
• Estimated Standard coordinator cost: 12,076,000 × $0.000025 = $301.90 per month

For Express, use the published $1.00 per million requests plus $0.00001667 per GB-second, and assume each run is billed at 64 MB for 0.5 seconds. ^[1] The request line is $1.00. The duration estimate is 1,000,000 × 0.5 × (64/1024) = 31,250 GB-seconds, or about $0.52. The estimated Express coordinator total is therefore $1.52 per month under these assumptions.

The large difference does not mean Express is automatically correct. AWS’s own comparison notes that Express is limited to five minutes and uses at-least-once execution, while Standard supports longer-running workflows and exactly-once semantics for the relevant execution model. ^[2] A payment or approval flow can cost more to repair after a duplicate or lost step than it costs to coordinate durably.

The same arithmetic changes sharply with a map. If each execution fans out to 100 items and the inner path adds two billable transitions per item, the additional 200 transitions per execution would add 200,000,000 transitions at one million executions. At the stated Standard rate, that is $5,000 before the free tier, assuming every item follows that path. Batch small items inside a task only if doing so preserves the required retry, visibility, and isolation properties. Otherwise the apparent saving merely moves risk into a larger, harder-to-retry unit.

When each option makes economic sense

Choose a managed state machine when durability is part of the requirement

Use a managed state machine when work waits for humans, timers, callbacks, or external events; when a run can outlive a worker; or when operators need a history of each step. A transition fee is easier to defend when it buys recovery and audit evidence. AWS also documents a pattern that combines a Standard parent with an Express child, keeping long waits in the durable layer while moving short, idempotent work to a high-throughput layer. ^[2]

Do not count “wait time” as free by default. The provider may stop compute billing while a workflow waits, but the workflow can still incur storage, polling, or replay-related costs. Read the selected service’s billing semantics and include them in the model.

Choose a queue chain when work is naturally message-shaped

Queues fit independent jobs, burst absorption, and consumers that can retry safely. Their cost model is often easier to reason about when one message equals one unit of work. It becomes harder when every hop emits several messages, visibility timeouts cause redelivery, or a dead-letter queue is treated as an afterthought.

For an agent, add the cost of duplicate tool calls and model calls. A retrying consumer can be cheaper than a state transition, yet more expensive overall if it repeats a large prompt or a non-idempotent side effect. Put the retry multiplier beside the downstream task price instead of burying it in the queue row.

Choose an in-code loop when the failure boundary is deliberately small

An in-code loop is a reasonable default for two or three short, sequential, idempotent operations that can be retried as one unit. It keeps deployment and local testing straightforward. It becomes a poor bargain when the process has long waits, branching approvals, fan-out, or a need to resume after a worker crash.

Price the loop honestly. Include the worker’s billed duration, memory, logs, retry attempts, checkpoint database, alerting, and the engineer-hours needed to operate it. If the loop has no durable checkpoint, mark that as a reliability exclusion rather than assigning it a zero dollar value.

How to avoid double-counting and false savings

First, define the boundary. If the state machine invokes a function, the state transition and function invocation are both real charges. AWS explicitly warns that other services called by a workflow create additional charges. ^[1] If a queue triggers a worker, message operations and worker compute both belong in the total. If a durable framework replays an orchestrator, replayed invocations belong in the estimate even when the business task itself does not repeat.

Second, model percentiles for reliability. An average run with 12 transitions is not enough if P95 runs branch into a 100-item map. Keep at least a base path, retry path, and fan-out path. For agent workloads, use token and tool-call counts from traces or invoices rather than assuming every run has the same prompt size. The AI API invoice reconciliation calculator can help compare estimated usage with billed rows after launch.

Third, separate architecture selection from provider selection. A state machine can be self-built or managed. A queue can be embedded in a workflow service or assembled from multiple products. Code can run in a serverless function, container, or long-lived worker. Compare the same reliability contract across options: maximum wait, delivery semantics, duplicate tolerance, recovery point, audit history, and operator response time.

For a complete spend view, pair this guide with the AI agent budget guardrail and P95 calculator. If you are still deciding whether orchestration belongs in the application or a platform, estimate the build-and-maintain work with the AI agent development cost estimator. The AI Agent Cost Calculator | Model Full Monthly Spend is the right next step when the coordinator is only one line in a broader agent budget.

FAQ

Is a state machine always more expensive than an in-code loop?

No. A managed state machine can have an explicit transition or action charge, while an in-code loop may have no separate coordinator meter. But the loop still pays for worker compute, logs, retries, persistence, and recovery engineering. For long-running or failure-prone work, those transferred costs can outweigh the visible state-machine line item.

How do I calculate workflow transition cost?

Multiply expected executions by the expected billable transitions on each path, add retry and fan-out transitions, subtract any documented free tier, and multiply by the published unit rate. Use a weighted average only after separately modeling high-cost paths. Do not use the number of business steps as a substitute for the provider’s actual billing unit.

When is a queue cheaper than a state machine?

A queue may be cheaper when each message represents a simple independent job, batching is effective, and the consumer can safely retry. Compare the full chain, including message operations, redelivery, retention, consumers, logs, and repeated model or tool calls. A lower queue price does not prove lower total workflow cost.

Do retries increase orchestration cost?

Usually, yes, but the unit varies. AWS states that each retry adds a state transition for Standard Step Functions. Microsoft documents a different mechanism for Durable Functions: orchestrator replays are billable invocations on the Consumption plan, while waiting itself is not billed as active orchestrator execution. ^{[1] [3]} Apply the exact rule for the service you use.

Can I combine a state machine with code?

Yes. A common hybrid is a durable parent for approval, timers, and recovery, with a short in-code or Express-style child for idempotent high-volume work. The boundary should be explicit about retries, duplicate delivery, timeout limits, and which component owns the audit history. AWS documents nested Standard and Express workflows as one example of this pattern. ^[2]