Skip to main content
The Runtime is the execution engine of Agent Platform. It receives messages from users and systems, executes agent logic, invokes tools, manages conversation state, and returns responses. Every agent interaction — regardless of channel or deployment environment — passes through the Runtime.

​
How a Message Executes

When a user sends a message, the Runtime processes it through a structured pipeline before returning a response. The cycle repeats until the agent produces a final text response or reaches the iteration limit. The default is 10 tool call iterations per turn, configurable in the agent’s execution settings.

​
Channels

The Runtime accepts messages from the following channels: Realtime (WebSocket or persistent connection): Async / webhook (inbound event, outbound REST): Channel connections are configured per project in Studio under Settings → Connections. Each connection maps a channel to its authentication credentials, routing rules, and channel-specific options.

​
Tool Execution

Tools extend agent capabilities. When the LLM requests a tool call, the Runtime dispatches it to the appropriate executor and returns the result to the reasoning loop.

​
Execution Pipeline

When a tool executes, the Runtime processes it in sequence:
  1. Resolves the tool binding from the deployment configuration.
  2. Validates inputs against declared parameter types before the call.
  3. Makes the external call with the appropriate authentication.
  4. Processes the result — available in conversation context for reasoning agents, or as session variables for agents with steps.
  5. Handles errors using ON_ERROR handlers: retry logic, fallback responses, or escalation triggers.
Tool execution also enforces timeouts, categorizes errors, and retries automatically on transient failures. For setup and configuration, see Tools Overview.

​
Session Management

Each conversation is represented as a session. A session stores the conversation history, variables, agent state, and execution metadata.

​
Session Lifecycle

Sessions time out after 24 hours of inactivity. Conversation history is retained for 90 days.

​
Conversation Window and Compaction

The Runtime maintains a sliding window over the conversation history to control how much context is sent to the LLM on each turn. The default window is 40 messages. When the window fills, the Runtime can compact older turns into a summary rather than discarding them. This preserves context from earlier in long conversations without increasing token usage. Compaction is disabled by default and can be enabled in Runtime Config in Studio.

​
Concurrency

The Runtime uses a configurable strategy to handle multiple messages arriving within the same session:

​
Multi-Agent Orchestration

The Runtime executes multi-agent topologies defined in ABL. When routing rules match, the Runtime transitions the active thread to the target agent, forwards context, and manages the return path.

​
Thread Hierarchy

When a supervisor hands off to a specialist, the Runtime creates a thread within the existing session — not a new session. Threads form a stack: handoffs push new threads, completions pop back to the parent. The user experiences one continuous conversation regardless of how many agents participate. Each thread maintains its own conversation history and gathered variables, but can read data from parent threads. For configuration, syntax reference, and examples, see Multi-Agent Orchestration.

​
Observability

Every execution path emits structured trace events. Traces are accessible from the Sessions page in Studio. Each session also captures summary metrics: total messages, runtime cost, token consumption, response latency, tool latency, and model usage breakdown. For details on navigating sessions and traces in Studio, see Sessions and Runtime Diagnostics.

​
Rate Limits

The Runtime enforces per-tenant rate limits on a rolling 1-minute window. When a limit is exceeded, the Runtime returns HTTP 429. The response includes a Retry-After header (seconds to wait) and X-RateLimit-Remaining. Contact your account team to adjust limits for your plan.

​
Limits Reference

​
Troubleshooting

Agent stops responding mid-conversation Open the session in Studio and check the Traces tab. Look for an error event or a tool_result with a non-200 status. Tool failures that aren’t handled by an ON_FAILURE block can cause the reasoning loop to stall. Earlier context is missing in long conversations Once the conversation window fills (40 messages by default), older messages are no longer sent to the LLM. Enable compaction in Runtime Config to preserve earlier context as a summary rather than dropping it. Tool calls return unexpected results Check the tool_call and tool_result trace events in Studio for the exact request sent and response received. Verify that the tool’s auth profile and endpoint are correct in Settings → Connections. HTTP 429 — Too Many Requests The Retry-After header tells you how many seconds to wait before retrying. If you hit limits consistently during evaluation, check whether multiple concurrent test sessions are sharing the same tenant quota. Agents route to the wrong specialist HANDOFF rules evaluate top-to-bottom and the first match wins. Check rule ordering in the Supervisor — overly broad conditions placed above specific ones will capture requests before the intended rule is reached. See Orchestration Troubleshooting.

​
See Also