AI Governance Cannot Be a Tool Call | Tenure Platform<br>Project Resume Memory Modes PR Review<br>Editor Integrations<br>VS Code VSCodium<br>Compatible Clients<br>Mobile Open WebUI OpenClaw<br>Teams<br>Teams Overview Shared Memory AI Governance EU AI Act Compliance<br>How it works<br>Belief Merging Contradiction Handling Memory Modes AI Governance<br>Resources<br>Docs Writing Benchmark Paper GitHub
Install Free
Writing › AI context control plane<br>Architecture Governance cannot be a tool call
Enterprise AI needs a context control plane beneath every model request.<br>Not a tool the agent can choose to call. A layer every request has to pass through.
Tenure research · ~9 min read
TL;DR<br>Almost everything built on agents today treats governance, memory, and policy as tools the model can choose to invoke.<br>That shape breaks the moment something has to be true regardless of what the model decides.<br>The fix is not a better tool. It is a different position in the stack: beneath every request, not beside the model.<br>Tenure calls this the AI context control plane, starting with governed memory and state for enterprise AI workflows.
The assumption nobody states out loud If it depends on the model deciding to call it, it is not governance
Open almost any architecture diagram for an AI coding agent today and you will find the same<br>shape. The model sits at the center. Around it, a ring of tools it can reach for: a ticketing<br>system, a memory store, a compliance check, an audit log. The diagram looks complete. It is<br>missing the detail that determines whether any of it actually works: every one of those tools<br>only does something if the model decides to call it.
That is fine for a calendar lookup. It is not fine for the things people actually mean when<br>they say governance. Access control that depends on the agent remembering to check access<br>is not access control. An audit trail that exists only when the model chooses to write to it<br>is not an audit trail. A coding convention that the model follows when it happens to recall<br>the rule is not a constraint. It is a suggestion with good intentions.
This is the category error underneath a lot of AI infrastructure right now. Tool-calling is<br>useful for optional actions. Governance is not optional. Treating both as the same kind of<br>model-invoked tool makes the system look extensible while leaving the most important controls<br>dependent on the model's cooperation.
A tool a model can choose to call is optional input. Governance that matters<br>cannot be optional. The two are currently built the same way, and that is the problem.
The category Enterprise AI needs a context control plane
The missing layer is the AI context control plane: the infrastructure that decides what context<br>an AI request is allowed to carry, what memory it can use, what policy applies, and what gets<br>recorded before the request reaches the model.
This is not the same thing as an agent framework. It is not the same thing as a memory SDK. It<br>is not an MCP server. Those sit beside the model as capabilities the agent may invoke. A context<br>control plane sits in the path of the request. It can govern, enrich, scope, and audit the<br>request before the model ever sees it.
Tenure starts with memory because memory is the first unavoidable primitive of this layer.<br>Every serious AI workflow eventually needs durable state: what was decided, what changed, what<br>was superseded, who approved it, what scope it applies to, and why it was injected. If that<br>state lives inside one app, every other app loses it. If it lives behind a tool call, the model<br>can skip it. If it lives underneath the request path, it becomes infrastructure.
Tenure is the AI context control plane for enterprise teams, starting with governed<br>memory and state beneath every model request.
The problem in the wild People are already circling this from different directions
A coding agent can produce a diff, run a test, and report that the task is done. The harder<br>question, the one a lot of engineers are now asking out loud, is what happens after. Someone<br>still has to know what changed, why it changed, whether the right files were touched, what was<br>tested, what was skipped, and whether the result is safe to trust. That is not a code generation<br>problem. It is a review and trust problem.
A separate group is approaching the same wall from the orchestration side, building systems<br>that explicitly refuse to let an agent's own "done" signal count as authority. The agent<br>produces a claim. Something else, observing the actual state of the repository, the tests, and<br>the review, decides whether that claim holds. That is a real and reasonable design. It also<br>quietly admits the thing it does not solve by itself: someone still has to define what good<br>means for a given repo, and keep that definition from drifting out of sync with what the agent<br>was actually told.
A third group is rethinking memory itself along the same axis, arguing that most agent memory<br>today is something you query after the fact, and that the...