Agents, where your models run.
The next layer of the same deployment: the agents themselves — long-running loops, tool calls, working state — executing inside the boundary that already serves your models. In development now, built on the plane that already ships.
An agent is traffic, tools and state. All three stay in.
Hosted agents leak by construction — every tool call and every intermediate thought transits someone else's infrastructure. Deploying them beside your models closes the loop.
The loop stays inside
An agent is a conversation between a model and your systems. When both live in the same boundary, that whole loop — every prompt, every tool result — runs on hardware you control.
Tools reach internal systems
Agents are only useful when they can touch your databases, your APIs, your files. Deployed inside, they reach them over your network — nothing gets proxied through someone else's cloud.
State never leaves
Working memory, artifacts, intermediate files — agent state lands in your storage, retained and deleted on your schedule, like every other byte in the deployment.
Same plane, same guarantees
Agent serving rides the inference plane that's already deployed: the same endpoint, the same keys, the same caps and audit log. One boundary, one set of guarantees.
What a digital workforce stands on.
Beyond the agent runtime, the pieces long-lived agents need — each one landing in the same boundary as everything above it.
Being designed with early teams now.
If your roadmap has agents that cannot run on someone else's cloud, we want your constraints shaping this layer. Deployments start with inference today; agent workloads join as the runtime matures.