Agent runtime

Every agent you deploy on the platform is a self-contained service. The build process compiles your agent's instructions, skills, tools, channel connections, and security policy into a single container image, and a shared agent runtime executes all of it. You never operate the runtime directly — the console and CLI manage it for you — but understanding what it does helps you reason about what your agents can and cannot do.

What the runtime provides

When an agent receives a request (from a user, a channel like Slack, or a workflow step), the runtime drives an LLM-powered loop: it presents the agent's available tools to the model, executes the tool calls the model makes, feeds results back, and returns the final response. Around that loop it enforces the controls you configure on the platform:

• Skills and tools define what the agent is capable of doing.
• Egress control restricts which external hosts the agent may reach — deny-all by default.
• Approvals can pause sensitive tool calls until a human approves them.
• Memory keeps multi-turn conversations coherent and can persist knowledge across sessions.
• Scheduling runs recurring tasks without a user prompting the agent.
• Audit events record everything security-relevant the agent does and stream it to the platform's Security area.

Because all of this is baked into the agent at build time, two agents in the same workspace can have completely different capabilities and network permissions — each agent's policy travels with it.

In this section