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.
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

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.

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.

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.

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. The console’s risk ladder is the coarse gate; NSR is where per-action authorisation with a cited proof happens.

Related

• Console Overview
• Console Auth Flow
• Sandboxes
• Decision gate