There's no shortage of agent frameworks, and they're genuinely good at what they do: on a laptop, you can wire together a planner, a few workers, and a reviewer in an afternoon. The trouble starts when you try to run that crew for real users, around the clock, and discover that the framework was the easy part.
The framework ends where production begins#
A library that orchestrates agents in your process doesn't, by itself, give you any of the things production demands. Where do runs live when the process restarts? How do you resume a job that died halfway? How do you meter cost, stream progress to a UI, retry a flaky tool, or pause for a human without holding a thread open for an hour? Those aren't framework features; they're infrastructure.
- Durable, resumable runs that survive a restart.
- Observability — per-step traces you can actually debug from.
- Cost controls and usage metering.
- Tenant isolation and credential security.
Why we built a runtime instead#
You can build all of that yourself around a framework. A lot of teams do, and they spend months on it instead of on their product. We think the orchestration belongs behind an API — a managed runtime that owns the state, the persistence, the observability, and the security — so the framework-shaped part stays a one-line call and the hard part is someone else's job. Frameworks make agents easy to start. A runtime makes them safe to depend on.