Sessions and Execution

Session and Run Lifecycle

Agent Platform now uses one durable execution model across the CLI, dashboard, and public API:

• session for the long-lived conversation container
• run for one execution inside a session
• run_event for the durable event timeline

When you send a message in a session or create a run over the public API:

1. The control plane stores the input and creates a run.
2. A River worker loads the session transcript.
3. The worker resolves the current workspace and the user's role.
4. The worker builds the system prompt.
5. The worker resolves the hosted model configuration.
6. The worker calls the model, optionally with gateway-backed tools.
7. The worker appends durable run_event records for reasoning summaries, tool calls, output deltas, and terminal state.
8. The assistant reply and transcript snapshots are written back into session storage for compatibility and history views.

run_events are now the source of truth for streaming. The CLI and dashboard render from that event log instead of polling turn snapshots.

Durable State Today

Agent Platform persists these user-facing state layers today:

• Session transcript state in Postgres
• Run and run event history in Postgres
• Normalized tool call records linked to runs
• A small user profile record for display name, used during setup

There is not yet a general cross-scope memory graph for users, projects, or organizations. The durable memory that exists today is narrower and easier to reason about.

Hosted Model Requirement

Every interactive session ultimately depends on the platform-hosted model configuration. If hosted model access is not configured, session creation and run execution fail with HOSTED_MODEL_UNAVAILABLE.

The AP vault is not part of that model path anymore. It remains the encrypted store for integration credentials only.

That split matters in practice. If session creation fails because the hosted model path is unavailable, adding or editing an integration secret will not fix it.