Table of Contents
Build vs Buy for Agent Orchestration: When Temporal-Style Beats Managed
Most teams pick their orchestration layer by accident. The managed demo shipped in an afternoon, so managed won, and nobody wrote down why. Then month four arrives: a run hangs at step 4, the vendor log says the run is "in progress," and there is no trace telling you which tool call is blocked or why. The cost of that missing trace, not the price per run, is what should have driven the decision. Both paths run the agent cheaply. What you buy or give up is control over retries, secrets, egress, and the execution graph you can actually see.
Here is the decision made deliberately: managed is the right default while you are still learning what the agent should do. Self-hosted durable execution earns its keep once behavior is understood and you start hitting the walls managed platforms build around you. The rest of this prices that flip.
What "managed" actually means
The category is AWS Bedrock AgentCore, Google Vertex AI Agent Engine, and OpenAI's hosted Agents. No infrastructure to run, a consumption bill, vendor guardrails on retry and tool-call depth, and limited egress into your own observability stack. Both AWS and Google now bill the runtime the same way: per vCPU-hour plus per GiB-hour of the managed session, $0.0895 per vCPU-hour and $0.00945 per GB-hour on AgentCore as of August 2026, and Agent Compute plus Agent Memory on Vertex. AWS states the harness itself is free; you pay for the resources.
One correction worth making, because the vendor slides invite it: "Anthropic managed agents" is not a runtime you can buy. Anthropic ships a self-hosted Agent SDK plus Ode, an enterprise AI services firm that embeds engineers, not a hosted orchestration graph. If your shortlist has an "Anthropic ODE" column next to Bedrock and Vertex, delete it.
What the decks skip: the execution graph is opaque. Debugging a stuck run means reading vendor logs, not your own spans.
What "Temporal-style" actually means
Durable execution where the orchestration state lives in your infrastructure. Temporal is the reference implementation; the category also includes Inngest and Conductor, the Apache-2.0 workflow engine Netflix open-sourced and the community now maintains. The shared property: retry, timeout, and backoff are code you own, every step emits spans to your OTel collector, and the bill is infrastructure plus a durable-execution SaaS line if you choose one, not per-call vendor fees.
The trade is real. You now own failure modes the managed platform absorbed for you: clock skew across regions, zombie workers, and database migrations under a running workflow. That is the tax for holding the trace data and the retry logic.
The decision table
No "it depends" cells. Read your situation down the left; the middle names the path.
| Your situation | The call | Why |
|---|---|---|
| Under 5k runs/day, no infra engineer, compliance is a future item | Managed | The runtime bills sub-cent per session; a Temporal cluster buys you nothing yet |
| 5k to 50k runs/day, behavior still changing weekly | Hybrid | Keep the managed runtime, but start emitting your own traces so you can move later without a rewrite |
| Over 50k runs/day and agents lean on managed web search or memory | Self-hosted | The per-call add-ons compound; raw APIs behind your own runtime cost a fraction |
| Data-residency rule or a SOC 2 audit trail you must control | Self-hosted | You cannot hand an auditor a trace you do not hold, and managed egress leaves your VPC |
| You need retry, timeout, or backoff the managed SDK will not expose | Self-hosted | Retry policy is code on the durable-execution path; on managed it is a config ceiling |
| No engineer on staff has run a durable-execution cluster | Managed | The failure modes you would inherit need someone who has already seen them |
When managed wins
Prototype to first production run in under two months, no infra engineer to spare, run volume under 5k a day, compliance a future gate rather than a present one. The economics back this at low volume: AWS's own example puts a light agent session's runtime cost at a fraction of a cent, because runtime bills only actual CPU and memory per second. Below the scale where add-on fees compound, owning infrastructure is a cost with no return. Vendor lock-in is the acceptable trade for time-to-value.
When self-hosted wins
Volume crosses the point where the à-la-carte fees, not the runtime, drive the bill: managed web search at $7 per 1,000 queries, managed memory, gateway tool-call charges, and $0.006 per GB of VPC egress. You need full trace data to debug production failures. Your security team requires that no agent input or output leaves your VPC. Or you want retry logic the SDK will not give you: exponential backoff with jitter, dead-letter to PagerDuty, max-attempts keyed on error type. Temporal Cloud Essentials starts at $100/month for 1M Actions as of August 2026, with additional Actions at $50 per million falling to $25 at volume, and you pay your own worker compute on top.
The hybrid case
Some teams run managed for the live workload while building the self-hosted path in parallel. Rational, with one hidden cost: two orchestration mental models in the codebase at once. Set a cutover date before the hybrid phase starts. Without one, it drifts to permanent, and you are now maintaining both.
What your CFO will ask
The question is never "which is cheaper," because model tokens are the same bill on both paths (you call the same model either way) and they cancel out. The real delta is the orchestration overhead managed adds on top. Here is that layer at 50k runs a day, 1.5M runs a month, as a worked example. Actions-per-run depends on your workflow shape; a 10-step agent is roughly 20 Temporal Actions, so assume 30M Actions a month.
| Orchestration layer, 1.5M runs/month | Managed (AgentCore) | Self-hosted (Temporal Cloud + EC2) |
|---|---|---|
| Runtime / plan | ~$675/mo compute (sub-cent per session, AWS rates) | $500/mo Business + ~$1,140 for 30M Actions (Temporal tiers) |
| One web search per run | 1.5M x $7/1,000 = ~$10,500/mo | Your own search API, no per-call markup |
| Tool-call fees | Gateway InvokeTool $0.005/1,000 | None; it is your code |
| Worker compute | Included | ~$300 to $800/mo EC2 |
| Trace data for debugging | Vendor logs only | Full OTel into your stack |
The runtime is a rounding error on both sides. The managed premium lives in the add-ons, and web search is the one that scales linearly with your run count. If your agents lean on managed search, memory, or heavy egress, the crossover arrives fast; if they do not, managed stays cheaper than running your own cluster. Price your actual tool mix before you migrate.
What breaks first
Managed: observability, and it breaks the first time a run hangs in production. The vendor log tells you the run is active. It does not tell you that step 4 called a flaky internal API that is now 90 seconds into a silent timeout. You cannot attach a debugger to someone else's execution graph, so the incident runs long while you file a support ticket. Evals gate what runs, but orchestration decides what is visible to gate on, and managed decides that for you. How you wire eval harnesses assumes you can see the trace; confirm you can before you build the gate.
Self-hosted: the first major server upgrade that changes the workflow state format. Temporal workflows must be deterministic, so a code change to a running workflow can throw non-determinism errors unless you version it correctly, and a server upgrade that alters state serialization forces a migration while workflows are mid-flight. Clock skew between workers in a multi-region deployment surfaces the same week, as timers fire early or late against a drifting clock. Budget two sprint cycles for the migration, not one, and expect zombie workers the first week.
The verdict, by org profile
A solo platform team shipping its first agent: managed, every time. Runtime is sub-cent, and you have no one to run a cluster. A growth-stage team at 5k to 50k runs a day with behavior still moving: managed runtime, but wire your own OTel spans now so the migration is a lift-and-shift, not a rewrite. A team over 50k runs a day whose agents call managed search or memory, or who face a data-residency rule: self-hosted on Temporal or Conductor, and staff the one engineer who has run durable execution before you cut over. The harness decision sits one layer up from this one, and the CI gate sits one layer down; get the full path in the pillar. The mistake is not picking managed. It is picking it without knowing which wall you hit next.