The loop runs on your hardware.
A place for the agent itself to live, inside the perimeter that already serves your models: sessions that last as long as the work, an isolated machine per run, and a budget and kill switch the runtime enforces rather than your code. In development now.
A home for the whole run, not just the call.
Today an agent loop is something you host: a box you keep alive, a harness you wire, a session you hope survives. The runtime makes that part of the deployment — running on the same hardware, behind the same boundary, under the same guarantees.
Sessions that outlast the turn
A run that goes for six hours will hold for six hours. Each agent gets a long-lived session that stays alive across the whole trajectory and idles to nothing between turns — no process of yours has to stay up to keep an agent breathing.
A machine per agent
Every agent gets its own isolated environment — a filesystem, a shell, tools, room to try things and fail. Right-sized per agent, sealed from every other run, and destroyed to the metal when it ends.
A hard cap and a kill switch
Every agent will carry a spend ceiling and an instant stop, enforced in the runtime rather than in your code. Overspend and it freezes itself; hit kill and its machine is gone. One rogue agent does not become an incident.
On the plane already deployed
The runtime stands on the inference layer inside your boundary. Same endpoint, same keys, same catalogue, same audit log — the agent loop is not a second deployment to approve.
The runtime is one layer of a stack.
Two pieces live inside this layer, and one layer sits above it. Each lands in the same boundary as everything below.
Being designed with early teams now.
If your agents cannot run on someone else's cloud, we want your constraints shaping this layer. Deployments start with inference today; the runtime joins the same footprint as it matures.