> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stateset.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Console Agent Pipeline

> How an agent request flows through the console — validation, sandbox execution, SSE streaming, and the risk ladder that gates writes.

# Console Agent Pipeline

Agent interactions route through `/api/ai/agent-chat` and stream back over **Server-Sent Events**.
The pipeline's job is to get a request into a sandbox safely and stream what happens.

## The pipeline

```
requireAuth() ──▶ verify chat ownership ──▶ resolve sandbox auth
                                                    │
                          load chat context ◀────────┘
                                  │
                          run in sandbox runtime
                                  │
                          stream events over SSE
```

1. **Validate the session** with `requireAuth()`.
2. **Verify chat ownership** for the org — a valid session for the wrong org is still a rejection.
3. **Resolve sandbox auth context** and credentials.
4. **Load chat context** and recent messages.
5. **Run the agent** in the [sandbox runtime](/stateset-sandbox/stateset-sandboxes).
6. **Stream events** as they happen.

Steps 1–3 are all authorisation, in widening scope: is this a real session, does it own this chat,
and what may it reach. A failure at step 2 is the interesting one — it means a legitimate user
reached someone else's conversation.

## SSE event types

| Event                 | Meaning                      |
| --------------------- | ---------------------------- |
| `thinking`            | Reasoning in progress        |
| `message`             | Assistant output             |
| `tool_call`           | The agent is invoking a tool |
| `tool_result`         | What the tool returned       |
| `metrics`             | Token usage and timing       |
| `status_changed`      | Session state transition     |
| `error`               | Something failed             |
| `done` / `stream_end` | Terminal                     |

<Tip>
  Handle `error` and `stream_end` as separate cases. An `error` may be followed by `stream_end`, so
  treating either as "the stream is over" without distinguishing them loses the reason it ended.
</Tip>

## The risk ladder

Tool calls are classified, and the classification decides whether a human confirms. This is the
mechanism, not a policy setting:

| Classification | Level | Confirmation |
| -------------- | ----- | ------------ |
| `read`         | 0     | —            |
| `write`        | 1     | —            |
| `unknown`      | 2     | —            |
| `financial`    | 3     | **Required** |
| `destructive`  | 4     | **Required** |
| `bulk`         | 5     | **Required** |

Confirmation is required at **level 3 and above**.

<Warning>
  An unrecognised tool classifies as `unknown` at level **2** — below the confirmation threshold. So a
  tool the classifier doesn't know about executes without a human, and the safe-looking default is not
  actually fail-closed for novel tools.

  If you add a tool that moves money or deletes data, make sure it classifies as `financial`,
  `destructive`, or `bulk` rather than relying on the default.
</Warning>

## Confirmation tokens

A sensitive tool call emits a confirmation event rather than executing. The client returns a
`confirmation_token`, and only then does the action run. Tokens are single-use, so a captured token
can't be replayed to authorise a second action.

## Guardrails

Tool calls are validated against policy before execution, backed by
[NSR guardrails](/stateset-nsr-decisions). The console's risk ladder is the coarse gate; NSR is
where per-action authorisation with a cited proof happens.

## Related

* [Console Overview](/stateset-console/stateset-console-overview)
* [Console Auth Flow](/stateset-console/stateset-console-auth-flow)
* [Sandboxes](/stateset-sandbox/stateset-sandboxes)
* [Decision gate](/next-temporal/policy-engine)