Tenure separates clients, agents, extraction, injection, and belief access. A trusted desktop client can manage memory directly. An automated agent can receive scoped context without becoming the memory administrator.
Your IDE, chat client, CI agent, background worker, and autonomous coding agent should not all have the same authority over shared memory. Some tools need to inspect and edit beliefs. Some only need context injected before a model call. Some should be allowed to extract candidate beliefs, but never manually mutate the belief store.
Once a memory layer is wired into an AI client or agent, access is often broad. The agent can use memory, but the boundary between using memory and administering memory is blurry.
Generate separate tokens for clients and agents. Limit what they can read, write, extract, inject, and which projects they can touch. Revoke or expire access when the tool changes.
Tenure makes the authority boundary visible. User-facing clients can be trusted with full belief management. Automated agents can be limited to chat, extraction, and injection.
For trusted user-facing tools like VS Code, Open WebUI, CLI tools, or an admin client.
For automated tools, background agents, CI agents, and agent frameworks.
Tenure runs in the request path. Before context reaches the model, the token determines which capabilities are available, which project scopes are eligible, and whether the request is allowed to use or create memory.
Create a client or agent token for a specific tool. Name it, choose its capabilities, restrict it to projects, and set an expiry date when needed.
Each request is checked against the token: chat access, extraction permission, injection permission, direct belief read/write access, and project scope.
When memory is injected, Tenure records which beliefs were supplied, where they were used, and why they were eligible for that turn.
If an AI answer looks wrong, you should not have to guess whether memory influenced it. Tenure records the scoped belief set supplied to each request, so memory use is inspectable instead of reconstructed after the fact.
Scoped tokens are the practical boundary between “my AI remembers things” and “our AI systems can safely use shared context.” They let teams adopt memory without handing every agent the keys to the belief store.
An agent can receive relevant memory in its prompt without being allowed to list, edit, or delete beliefs directly.
Your desktop client can manage memory. A background agent can be limited to extraction and injection.
Tokens can be limited to specific project scopes so customer, repo, and initiative context stays isolated.
Short-lived tokens make it easier to rotate tools, decommission agents, and remove stale access.
Per-turn audit logs show whether a belief influenced the request, instead of relying on guesswork after the model responds.
The same primitives become the foundation for role-based issuance, policy templates, SSO, SCIM, and audit/replay.
Scoped client and agent tokens, project restrictions, token expiry, and per-turn injection logs are useful even for one developer running multiple AI tools. Team and Enterprise plans add shared administration, identity-backed controls, policy workflows, and audit/replay across people and agents.
Start locally with scoped tokens and injection logs. Move to team governance when you need shared administration, identity controls, and policy-backed agent access.