Skip to main content
AIR separates hosted orchestration from private tool execution. The hosted runtime owns the durable agent loop; your worker owns access to your systems.

​
Core objects

​
Run lifecycle

1

Your application creates a run

AirClient sends the agent API ID, input, trusted context, and optional webhook settings using an app key.
2

AIR snapshots the active configuration

The run is bound to one agent version so later configuration changes cannot alter an execution already in progress.
3

AIR calls the model

Output chunks are recorded as durable events and published live. Each request, response, token count, latency, and cost is recorded in the trace.
4

AIR queues approved tool calls

If the model requests an allowed tool, the run waits while an outbound worker claims the task.
5

AIR resumes durably

The tool result enters the transcript and the run continues until it succeeds, fails, or is cancelled.

​
Live output and replay

The console and Python SDK consume the same ordered run-event stream. AIR saves each event in Postgres before publishing it through Redis:
  • Redis delivers new events immediately to connected subscribers.
  • Postgres remains the source of truth and replays events a subscriber missed.
  • Each sequence number lets a reconnecting client continue without losing or duplicating output.
Redis is the live delivery path, not the permanent record. A console or SDK client can therefore join after a run starts, reconnect after a network break, or inspect a completed run and still receive the recorded event sequence.
AIR run trace with model response, usage, cost, and configuration snapshot

The trace makes model behavior, cost, and the immutable configuration auditable.

​
Why tools start pending

A worker discovers capability; it does not grant policy. Newly registered tools start awaiting approval until a project owner reviews their description, schema, timeout, source, and write capability. An agent version can only call tools explicitly included in that version.