How nvoken works

One successful Turn start means nvoken has durably accepted the work. The runtime resolves every execution coordinate once, in one admission transaction:

1. the exact Agent revision or inline behavior;
2. the tenant and optional actor user;
3. an optional MemorySpace;
4. an optional Conversation;
5. narrowed limits, provider credentials, authorization, and idempotency;
6. one immutable effective-behavior snapshot owned by the Turn.

Only then is work queued. Execution never follows an Agent's mutable current pointer, so publishing a new revision cannot alter a queued or running Turn.

Admission is recoverable

The HTTP API accepts work with POST /v1/turns and returns 202. The TypeScript facade exposes the same boundary through agent.start() or client.inline(...).start().

Give every logical start a stable idempotency key. If a response is lost, retry the exact request or recover by the returned Turn ID. A client timeout proves only that the caller stopped waiting; it does not prove admission failed and it does not cancel the Turn.

Stored and inline behavior share one execution path

Use an Agent when behavior should be stored, named, versioned, and reused. Use client.inline(...) when behavior belongs to one call site. Both become the same immutable effective behavior before execution begins.

const runner = client.inline({
  instructions: "Classify the request.",
  model: "anthropic/claude-sonnet-5",
});
 
const result = await runner.run("I was charged twice.", { tenant: "acme" });

Postgres is the execution authority

Turn status, claims, leases, checkpoints, tool waits, transcript watermarks, and settlement are durable. Streaming is a view of that state, not the owner of it. Reconnect a stream or read /v1/turns/{turn_id}/result to reconcile.