Your app owns the state

A multi-tenant app cannot treat agents as fixed config. Instructions, tools, and models vary by tenant, by plan, and by user. If those definitions are registered into an agent runtime, every variation becomes a record to provision, and every product change becomes a migration for each agent instance. For an app with thousands of users, this turns into a big pain.

nvoken avoids this by design.

Composed per request

Your app composes the spec from its own database on every invocation, so tenant customization is just a query. nvoken stores sessions, running turns, and optional encrypted provider credentials — not agent definitions. There is nothing to register, sync, or migrate when you update your app with new agent customizations.

The boundary

Your app — source of truth	nvoken — execution state
Agent definitions & versions	Sessions & message history
Users, tenants & plans	Running turns & checkpoints
Integrations & credentials	Optional encrypted provider keys
Orchestration & product data	Usage & traces

Agent behavior arrives with each request as the execution spec; nothing is provisioned or registered first. Every tool with side effects executes on your side of the boundary — either as a recoverable host tool call or as a signed callback to your endpoints.

Why it matters

Two decisions are hard to reverse once agents are wired into your product: where the runtime runs and who owns your state. Many "open source" agent runtimes are open clients to closed infrastructure — the SDK is permissively licensed, but the part that runs your agent cannot leave the vendor's cloud, and your state lives in their system.

nvoken is bring-your-own-key, Apache-2.0 end to end, and built for embedding in a multi-tenant app. It runs anywhere you can put a binary and a Postgres URL: a laptop, your cloud account, or an air-gapped network.