How it works Control what AI knows and
Control what AI knows and
what agents can do.
Tenure sits between your application and the model. It adds the right memory, removes tools the agent should not use, and checks every returned action before it reaches your systems.
Memory shapes the decision. Policy decides whether that decision can become an action.
One request path 01 Identify Resolve the caller, memory scope, and agent policy. 02 Inject memory Inject approved context relevant to this request. 03 Filter tools Hide capabilities outside the active policy. 04 Call the model Send the governed request to the provider. 05 Check evidence Verify the action, arguments, and preconditions. 06 Release or block Return safe actions and withhold everything else. Memory Policy Preconditions
Context goes in. Governed actions come out.
One authenticated token tells Tenure which memory the caller may receive and which agent policy it must enforce.
→
→
→
→
→
What should the model know?
Only active, relevant context from data scopes this token is allowed to access.
What may the agent do?
Only reviewed tools, arguments, and actions attached to its identity.
What must be true first?
Required evidence from earlier steps must exist before a dependent action continues.
How memory works 01 02 03 04
Tenure turns useful context into governed memory.
Conversations, documentation, code context, and direct input can become structured beliefs. Each belief keeps its source and scope, so Tenure can decide when it belongs in a request.
Capture
Learn decisions, facts, preferences, constraints, and open questions from the sources you choose.
Structure
Store a compact belief with type, source, scope, confidence, and history instead of a transcript dump.
Govern
Review, edit, approve, reinforce, supersede, or keep a belief out of model context.
Inject
Supply only active memory allowed for this caller and relevant to the current turn.
ORGNever send customer secrets to third party tools.
TEAMPlatform APIs use structured error envelopes.
PROJECTPayments migration targets PostgreSQL 18.
USERPrefer detailed explanations with examples.
agent:code-reviewer
Three beliefs are eligible.
Organization, team, and project memory can enter the request. User persona memory stays out because this token cannot access it.
Memory helps the model reason with the right context. It does not grant authority. Agent policy separately decides what the model may do.
How enforcement works
Tenure controls both sides of the model call.
Before the model runs, Tenure adds approved memory and removes forbidden tools. After the model responds, Tenure checks every structured action again.
Application supplies
fetch_customerKEEPgenerate_emailKEEPdelete_customerREMOVEexport_databaseREMOVE→
Model sees
fetch_customerVISIBLEgenerate_emailVISIBLE→
Tenure decides
generate_emailCHECKdelete_customerBLOCKAdd approved context
Only memory that is relevant, active, and allowed for the token enters the request.
Hide forbidden tools
Capabilities outside policy are removed before inference. The model never sees them.
Check returned actions
Tools, arguments, and required evidence are verified before release to your runtime.
When an action is blocked, your team chooses what happens next. Tenure can return a hard error, or hand the rejection to your own application logic for retry, fallback, or rerouting to a different agent.
Required evidence 01 02 String · matches customer_id sent to generate_email Boolean · must equal true String · non-empty, any observed value 03 RELEASED BLOCKED CONFIGURABLE
Allowed does not always mean allowed yet.
A policy can require an earlier tool call to return specific evidence before the next action is released. Tenure calls these requirements preconditions. Each check verifies three things: that the field is present, that its type matches what was observed, and that its value satisfies the rule your team approved.
Fetch the customer
fetch_customer The agent calls the required capability first.
→
Verify the result
customer_idMATCHactiveEQUALStierVALID→
Release the next action
generate_email The action continues only when every enabled check passes.
Required evidence exists
The dependent action can continue to your runtime.
Required evidence is missing
Tenure withholds the action before it reaches your runtime.
Your team chooses the checks
Proposed preconditions can be turned on or off in the draft policy.
Most tools ask whether an action is allowed. Tenure also asks whether the agent has established everything required to perform it.
From observation to enforcement 01ObserveRecord tools, calls, inputs, and results, and track which available tools were never invoked. 02DraftPropose capabilities and preconditions. 03ReviewChoose what is allowed and required. 04PublishAttach the policy to an agent token. 05EnforceApply it to every request. Observed exposure Observed use Reviewed policy
Start with what the agent actually does.
Tenure records the tools an agent sees, the calls it makes, and the results returned between steps. It turns that behavior into a draft policy your team can review.
→
→
→
→
What could the agent use?
See every tool the application made available to the model, and which of those capabilities were never invoked during observation.
What did the agent do?
See calls, arguments, outputs, and evidence passed between steps.
What should remain possible?
Choose allowed capabilities and enable or disable proposed preconditions.
Built to be inspected Memory record Observation record Enforcement record
See what the model knew and why an action was allowed.
Tenure records memory and enforcement as the request happens. You do not have to reconstruct the decision after something goes wrong.
What entered the request?
See which beliefs were injected, their source and scope, and why they were eligible.
What did the model know?What did the agent attempt?
See available tools, invoked tools, arguments, outputs, and evidence paths, and drill into the exact observation behind any summarized frequency.
What did the agent try to do?Why was it released or blocked?
See identity, policy version, capability decision, precondition result, and outcome.
Why did Tenure make this decision? Works across agents and models
Change the framework without rewriting the rules.
Tenure runs on the model request path instead of inside one agent framework. The same memory scopes, tool policy, preconditions, and audit rules apply instantly to any traffic using standard OpenAI and Anthropic protocols.
Custom agent Agent framework Application code AI client
→
Supported ingress OpenAI and Anthropic protocols Normalize requests and returned actions.
→
Tenure Memory and policy gateway Resolve context, filter tools, verify evidence, and record decisions.
The full picture
One request path answers six questions.
Who is making this request?Token identity
What should the model know?Scoped memory
Which tools should it see?Capability policy
What did the agent try to do?Observation
Has the required evidence been established?Preconditions
Why was the action released or blocked?Enforcement audit
Memory gives the model the right context. Policy limits its authority. Preconditions verify what must be true before that authority can be used.
Get started
Put memory and enforcement on the same request path.
Give every AI request the right context, observe what agents actually do, and enforce reviewed policy before actions reach your systems.