One workflow, built nine ways.
We built the same supplier-risk workflow on four AWS stacks, two Azure stacks, Databricks, a general agent loop, and AgentFlow. Same model, same data, a receipt kept for every run. All nine computed the same answer. The bills ran from $0.01 to $2.21 a run.
AgentFlow figures are provisional until the final receipt is attached. Multipliers are derived from each platform's own metering.
Same answer. Very different bills.
Every build reached the same numbers. What separates them is what each one spent on the way.
| AgentFlow | Databricks | AWS AgentCore, native harness | Azure AI Foundry | Agent loop | |
|---|---|---|---|---|---|
| Model tokens per run | 380 | 464 | 15,857 | 15,335 | 1,595,725 |
| Wall clock | 14.8s | 28s | 66s | 144s | 22.4 min |
| Cost per run | $0.01 | ~$0.11 | $0.11 | $0.11 | $2.21 |
| Steps that never call a model | 4 of 5 | 2 of 3 | 5 of 6 | 6 of 8 | 0 of 4 |
| How a workflow gets written | plain-English chat | notebooks and job config | Python, CDK, IAM | Python, azd deploy | Python |
| Who writes it | the team that owns the process | data engineers | cloud engineers | cloud engineers | engineers |
| Model choice per step | any provider, per step | endpoint per task | Bedrock catalog | Azure catalog | one model per loop |
| Human approval step | a step type | external | Step Functions, SNS, Lambda | external | prompt-level only |
| Audit trail | immutable ledger, built in | MLflow traces, system tables | execution history, CloudWatch | App Insights spans | conversation log |
| Runs where | AWS, Google Cloud, Azure, OCI, sovereign, on-prem | Databricks | AWS only | Azure only | wherever hosted |
The AgentCore column is the native-harness build. The same stack tuned with Step Functions ran at 8,289 tokens, 75 seconds and $0.07; every multiplier on these pages uses that tuned build. Billing basis differs by vendor: per token for the AWS and Azure rows, DBUs plus tokens for Databricks. Wall clock is the whole run, trigger to delivery. AgentFlow figures: provisional until the final receipt is attached.
How we ran it.
A supplier-risk review. Extract about ten thousand rows of delivery, quality and SLA data. Compute the risk measures. Analyze them. Build a report with charts. Deliver it.
The model, the data and the expected output. The computed result was verified identical on every build, at the data layer.
Four on AWS (AgentCore with its native harness, AgentCore with Step Functions, Bedrock Flows, Strands Graph), two on Azure (AI Foundry, MAF), one Databricks Lakeflow job, one conventional agent loop, and AgentFlow.
Where a vendor offers more than one way to build it, we built more than one. Headline multipliers use each vendor's best-tuned build, not its worst.
Token counts, wall clock and billed cost come from each platform's own metering. Billing differs by vendor: per token for the AWS and Azure rows, DBUs plus tokens for Databricks. Wall clock is the whole run, trigger to delivery, not the model call.
We logged every blocker on the way to a first clean run: about twenty-two on AgentCore, five on Azure AI Foundry, a catalog unlock on Databricks. On AgentFlow it was one prompt, then tuning in chat.
The method and all run receipts are available on request. Ask and we will walk you through them on a call.
You pay for what the model reads.
Across every runtime we measured, the spread came from one thing: what got fed to the model. Feeding a report step the full ten-thousand-row extract instead of the computed aggregates moved the same workflow, on the same platform and the same model, from 8,289 tokens to 613,978. Routing chart images through the model rather than storing them and passing a handle did the same again.
- extractruns as code
A query you already have. Pinned SQL, executed as written.
- transformruns as code
Arithmetic in Python. The numbers come from code, not from a model.
- analyzecalls a model
Reads the aggregates and writes the finding. This is the judgment, and this is what you pay for.
- reportruns as code
Fills the finding and the charts into the template.
- deliverruns as code
Posts to Slack or email under the run id.
The lever is not the vendor and it is not the model. It is whether the fixed work in a workflow is allowed to charge you model prices for running. AgentFlow settles that before the run starts: a step whose work is fully determined is rewritten to run as code. The rows and the image still reach the report; they are assembled by a step that runs as code at delivery, never replayed through a model.
A loop re-reads its own history.
A loop carries its whole history into every turn, so each new step pays for every step before it and the curve bends upward. A compiled graph hands each step only the inputs it declared, so the line stays straight. On the measured run, the loop spent 1,595,725 tokens and 93.6% of its input was the loop re-reading its own history.
A cent is small. A thousand runs a day is not.
The same workflow, a thousand times a day, for a year. Per-run cost from the receipts, multiplied out. Nothing else assumed.
| Build | Cost per run | Cost per year at 1,000 runs a day |
|---|---|---|
| AgentFlow | $0.01 | $3,650 |
| AWS AgentCore, tuned with Step Functions | $0.07 | $25,550 |
| AWS Bedrock Flows · AWS Strands Graph | $0.09 | $32,850 |
| Databricks · Azure AI Foundry · AgentCore, native harness | $0.11 | $40,150 |
| Azure MAF, self-hosted | $0.54 | $197,100 |
| Conventional agent loop | $2.21 | $806,650 |
Cheap only counts if it is right.
From a live chat deployment, scored on 719 cases by the customer's own LLM judge. Accuracy and latency are tracked build over build, not claimed once.
Questions about cost
Why is it cheaper than a single agent with every tool?
Each step is compiled into its own small agent with only its own tools and instruction, so the context stays short and prompt caching applies per step. Steps that do fixed work are compiled to code and call no model at all. A single agent carries its whole history into every turn: on the workflow we measured, 93.6% of what the loop sent to the model was its own history.
Can we predict what a run will cost before we commit to it?
Yes, and that follows from the path being fixed. The steps are known in advance and most of them don't call a model, so cost per run is a number you can see while you write the workflow and hold to afterwards. It does not vary with how long an agent decides to think.
Does it get cheaper the more we run it?
It is designed to. Once a workflow has a few runs behind it, the platform analyzes them and proposes changes, most often a cheaper model on one particular step, with the expected effect on cost and latency at the same accuracy. You decide whether to take it, step by step.
How accurate is it in practice?
On a production chat deployment evaluated against 719 cases and scored by the customer's own LLM judge, the current build passes 94.7% against a bar of 90%. Median response time is 7.81 seconds, 9.39 at p90, down from 33.1 seconds four weeks earlier.
Will you run this benchmark on our workflow?
Yes. That is what the proof of concept is for. Bring a workflow you already run, on whatever you run it on, and we will rebuild it beside your team and put the two receipts next to each other.
Ask for the receipts.
Every number on this page has a run behind it. We will open them on a call and go through any one you like.
Read the docsAn actual person replies, usually within one working day.