Customers define agents and run them on your platform. Isolate tenants, meter and bill accurately, sandbox their tools and cap runaway spend while models and machines fail.
How it works
›A run is a loop, so it lives on a queue and an agent-runtime worker fleet; the API only accepts it. Load is counted in internal requests (model calls, tool calls, state writes), not in customer calls.
›Tenants share fleets, so every limit, queue and counter is per tenant, and big tenants can move to dedicated fleets. One tenant must never be able to slow or bill another.
›Tools are customer-defined and therefore untrusted. They run in a sandboxed tool-runner fleet with no ambient credentials and a controlled way out to the network.
›Every billable action becomes an immutable usage event in an event log, aggregated into a time-series store and reconciled, so the invoice can be defended.
›Models and machines fail: a hosted provider, a tool runner, the primary of the run-state store. Capacity, fallbacks and spares are sized for the loss.
What you'll build
The platform API and its data model
Queue, agent-runtime workers, LLM gateway and hosted models
A sandboxed tool-runner fleet and a run-state store
Usage metering into a time-series store, and an approval queue
A limiter and breakers against a noisy tenant flood
A design that survives a provider outage, a lost tool runner and a lost state-store primary