AWS, Google Cloud, Azure and Databricks ship strong building blocks: model hosting, code execution, scheduling, identity. None of them ships as one product the layer above, where the team that owns a process can write it, govern it and run it without an engineer, and take it to another cloud if they have to.
Each row is something we had to work out while building the same workflow on every platform. The answers for the other three are what we found, not what we would like to be true.
| Question | AgentFlow | Databricks Agent Bricks + Lakeflow | AWS Bedrock AgentCore | Google Vertex Agent Engine + ADK |
|---|---|---|---|---|
| How a workflow gets written | In plain English, in chat. The platform writes the spec. | Notebooks and job config | Python code | Python code (ADK) |
| Who writes it | The team that owns the process | Data engineers | Engineers | Engineers |
| What keeps the agent in bounds | The compiler. A step cannot reach a tool or a step it was not given. | The supervisor prompt | The system prompt | The system prompt |
| Triggers | One record: schedule or webhook, fan-out to 10 workflows, input mapping, retries | A job schedule, per workflow | EventBridge Scheduler, Rules, Pipes and IAM | Cloud Scheduler and Eventarc |
| Human approval | A step type: plan, freeze, approve, run, record | Outside the job | Step Functions, SNS, Lambda and the Slack SDK | Cloud Workflows and a long-running tool |
| Prompt caching per step | Built in | Model level only | Model level only | Model level only |
| Packaged skills | Built-in library; custom skills in progress | None | None | None |
| Where your workflows live | Your object storage, versioned | Notebooks in the workspace | An engineering git repository | An engineering git repository |
| Model choice | Any provider, per step, including models you host | The serving endpoints you host | The Bedrock catalog | The Vertex catalog |
| Where it runs | AWS, Google Cloud, Azure, OCI, sovereign clouds, on-prem | Databricks only | AWS only | Google Cloud only |
| First workflow in production | 1 to 3 days | Days to weeks | Days to weeks | Days to weeks |
What each platform gives you to build with. Measured tokens, time and cost for Databricks, AWS and Azure are on the Benchmark page. The benchmark workflow has not been built on Vertex.
Nothing here asks you to move data or re-point a catalog. Your tables, your object store and your semantic layer stay where they are. What changes is who decides the order of the steps, and what each step is allowed to do.
A Lakeflow job already gets the deterministic part right. What it does not give the business is the pen: the DAG is notebooks and job config, approvals live outside it, and per-run cost has to be reassembled from three billing tables.
The primitives are strong and the per-step telemetry is the best we measured. Assembling them into a governed workflow took Gateway, a harness, Code Interpreter, IAM and CDK, and around twenty-two blockers before the first clean run. Against the native harness the figures are 4.5x and 42x.
Managed hosting and a clean deploy story. The catch is attribution: for hosted code agents the portal reports zero tokens, and the real numbers only surface in a separate monitoring surface.
One agent, every tool, a message history that grows all run. On the workflow we measured, 93.6% of the input tokens were the loop re-reading its own history, and no step was fixed in advance.
Multipliers compare the tuned build of each runtime against the same workflow on AgentFlow, from the benchmark receipts. Where a vendor had several variants we used its best one. AgentFlow figures are provisional until the final receipt is attached.
If the work is open-ended, keep the agent loop. Research, exploration, a question nobody has asked before: a loop's freedom is the point. AgentFlow's own chat is there for the one-off questions too.
If engineers will always write and own the workflow, and it will only ever run on one cloud, that cloud's own tools may be enough. A Lakeflow job is already deterministic. AgentCore's per-step telemetry was the best we measured.
AgentFlow earns its place when the people who know the process are not engineers, when a wrong number has consequences, and when someone will ask you to prove how you got it.
An ordinary agent is kept in bounds by its prompt, and prompts get ignored. In AgentFlow a compiler fixes the path before the run starts. The wrong tool is not in the step's toolset, and the wrong step cannot be reached. For regulated and audited work, that difference is the whole point.
No. Your tables, your object store and your semantic layer stay where they are. Workflow specs, memory, run history and the audit log are written to object storage you own.
No. Route to Bedrock, Anthropic, OpenAI, Gemini, Azure OpenAI or an open-weights model you host, and choose per step. Heavy reasoning can sit on a frontier model while routine extraction runs on a cheaper one.
They are already in your storage, as versioned JSON documents you can read. Nothing about them is held in our systems.
At the lowest level we use primitives from LangGraph for ordinary agent mechanics. The compiler, the state graph, the determinism and the context handling are ours, built on top. That layer is the product.
We will rebuild it beside your team and put the two receipts next to each other.
Read the docsAn actual person replies, usually within one working day.