Sessions & durability

Sessions and durability are the stateful spine of an agentic product. This is the part that most teams underestimate, and the part nvoken is built to own.

Sessions

A Session is the ordered message history — including tool call inputs and results — resolved by your session key. Per-Session serialization means concurrent turns cannot interleave one conversation. Your app never manages message arrays or replays history; it references a Session by key and nvoken keeps it ordered.

Durable turns

Admission survives API crashes, restarts, deploys, and client disconnects. A lease protocol ensures exactly one worker drives a turn at a time. If that worker disappears, the same Invocation is requeued and a replacement continues from its last committed model or builtin checkpoint. Uncommitted provider work may run again — the contract is at-least-once at the provider boundary and exactly-once at the durable boundary.

Streaming that survives disconnects

Generation and event streams can drop and rejoin; the transport is never the source of truth. A stream retries only before its first event is committed, so consumers never see duplicate events, and durable frames carry resume cursors so a reconnecting client picks up exactly where it left off.

History management

• Forking branches a conversation from any point.
• Compaction checkpoints summarize history against a token threshold while keeping the full transcript recoverable, including mid-turn compaction of the in-flight working set.
• Retention governs how long durable state is kept.

Recovery

Clients recover authoritative state two ways: by durable ID (GET /v1/invocations/{id}/result) or by a scope-bound cursor that pages the canonical transcript. Hosts can also drain fixed-cut incremental recovery snapshots or tail the same state over resumable SSE. See The contract for the read surface.