Writing › AI context control plane
Architecture
Enterprise AI needs a context control plane beneath every model request. Not a tool the agent can choose to call. A layer every request has to pass through.
Tenure research · ~9 min read
The assumption nobody states out loud
Open almost any architecture diagram for an AI coding agent today and you will find the same shape. The model sits at the center. Around it, a ring of tools it can reach for: a ticketing system, a memory store, a compliance check, an audit log. The diagram looks complete. It is missing the detail that determines whether any of it actually works: every one of those tools 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 they say governance. Access control that depends on the agent remembering to check access is not access control. An audit trail that exists only when the model chooses to write to it is not an audit trail. A coding convention that the model follows when it happens to recall 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 useful for optional actions. Governance is not optional. Treating both as the same kind of model-invoked tool makes the system look extensible while leaving the most important controls dependent on the model's cooperation.
A tool a model can choose to call is optional input. Governance that matters cannot be optional. The two are currently built the same way, and that is the problem.
The category
The missing layer is the AI context control plane: the infrastructure that decides what context an AI request is allowed to carry, what memory it can use, what policy applies, and what gets 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 is not an MCP server. Those sit beside the model as capabilities the agent may invoke. A context control plane sits in the path of the request. It can govern, enrich, scope, and audit the request before the model ever sees it.
Tenure starts with memory because memory is the first unavoidable primitive of this layer. Every serious AI workflow eventually needs durable state: what was decided, what changed, what was superseded, who approved it, what scope it applies to, and why it was injected. If that state lives inside one app, every other app loses it. If it lives behind a tool call, the model 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 memory and state beneath every model request.
The problem in the wild
A coding agent can produce a diff, run a test, and report that the task is done. The harder question, the one a lot of engineers are now asking out loud, is what happens after. Someone still has to know what changed, why it changed, whether the right files were touched, what was tested, what was skipped, and whether the result is safe to trust. That is not a code generation problem. It is a review and trust problem.
A separate group is approaching the same wall from the orchestration side, building systems that explicitly refuse to let an agent's own "done" signal count as authority. The agent produces a claim. Something else, observing the actual state of the repository, the tests, and the review, decides whether that claim holds. That is a real and reasonable design. It also quietly admits the thing it does not solve by itself: someone still has to define what good means for a given repo, and keep that definition from drifting out of sync with what the agent was actually told.
A third group is rethinking memory itself along the same axis, arguing that most agent memory today is something you query after the fact, and that the more valuable version is something the agent has to reconcile before it acts and correct as part of acting. Different vocabulary, same underlying complaint: the thing that is supposed to keep an agent honest is currently positioned as optional, late, or both.
Three different entry points. One structural cause. Nobody arrived at it from the same angle, which is usually a sign that the problem is real rather than a framing exercise.
The infrastructure precedent
A container does not ask permission before it sends a packet. It does not call a tool to check whether it is allowed to talk to another pod. The network policy is not a service the container can invoke if it remembers to. It is enforced underneath the workload, at a layer the workload cannot opt out of. The workload does not cooperate with the policy. The policy does not need it to.
In infrastructure, many controls begin as application-level conventions before they become enforcement layers. That shift matters because "the app should remember to check" is not a security property. It is a hope.
The same move is now available for agents. Almost nobody is positioned to make it because almost everything in this space is built as a tool the agent calls rather than a layer the request cannot get around.
Governance as a tool the agent calls
User request
→
Model
→
Governance tool, maybe called
→
Model proceeds either way
Enforcement is conditional on the model's cooperation. There is no structural floor.
Governance as the layer beneath the request
User request
→
Proxy enforces, logs, scopes
→
Model never sees a way around it
Enforcement does not require the model's awareness or consent. There is a structural floor.
Why app-level governance breaks
The average enterprise AI environment will not be one model, one assistant, or one agent. It will be a mix of coding tools, chat clients, internal agents, CI workflows, notebooks, ticketing systems, support workflows, and model providers. Each one will accumulate its own context. Each one will have its own memory model. Each one will make different assumptions about what it knows and why it knows it.
That is manageable while AI usage is personal and experimental. It becomes a governance problem the moment AI participates in real work. A team decision made in one tool should not disappear when a developer switches clients. A policy correction should not depend on being manually copied into every agent. A stale architectural fact should not keep resurfacing because one application remembered it and another one did not.
App-level memory creates islands. Tool-call memory creates optional recall. Enterprise AI needs neither. It needs a shared, governed substrate for context that can sit below the tools and above the models.
The future of enterprise AI is not one app with better memory. It is many apps sharing one governed context layer.
Why memory comes first
Policy without memory is brittle. Audit without memory is incomplete. Evaluation without memory has no durable view of what the system believed at the time. The layer underneath AI requests needs state because real organizations are made of accumulated decisions, exceptions, preferences, corrections, and rules.
That state cannot behave like a pile of semantically similar notes. A system that remembers "the connection pool cap is 20" and later remembers "the connection pool cap is 50" has not solved memory if both facts can keep returning forever. It has created a permanent read-time cleanup problem. Every future reader has to notice the conflict again.
Governed memory moves that work into the substrate. Facts need scope. Corrections need provenance. Superseded beliefs need to be marked as superseded. The current value needs to be available without forcing every model request to rediscover the history from scratch.
This is why Tenure treats memory as state, not search. The point is not to retrieve more nearby text. The point is to know what the system currently believes, why it believes it, where that belief applies, and whether it is still allowed to influence the next request.
Where Tenure fits
Tenure sits between AI clients and model providers. That position matters. It means context injection, scoping, audit trails, and memory governance do not depend on the model choosing to call a tool. They happen before the request reaches the model.
In practice, this lets teams use the AI tools they already use while giving the organization a shared layer for governed context. A developer can work in VS Code, Cursor, Cline, Continue, Open WebUI, or another client, while the memory and policy layer remains consistent underneath. The client can change. The model can change. The governed state does not have to disappear with either one.
That is the difference between a memory feature and a context control plane. A feature improves one application. A control plane gives the organization one place to decide what AI is allowed to know, remember, use, and prove.
MCP lets a model call tools. Tenure governs the request before the model sees it.
The test
The simplest test for this category is not whether a product says governance, memory, policy, or audit. The test is whether the system requires the agent's cooperation to work.
If the model has to remember to call the memory tool, memory is optional. If the model has to remember to call the policy checker, policy is optional. If the model has to remember to write an audit event, the audit trail is optional. However good those tools are, they are still downstream of the model's discretion.
A context control plane has a different contract. The request enters governed infrastructure before it reaches the model. Identity, scope, memory, policy, provenance, and audit can be attached outside the model's decision loop. The model does not need to know the enforcement happened. It also does not get to skip it.
If it needs the agent's cooperation, it is a tool. If the request cannot get around it, it is infrastructure.
Where this goes
None of this means tool-calling is the wrong abstraction for everything. Fetching a file, querying a database, opening a ticket, or running a build can all be discrete actions that a model invokes when needed.
The argument is narrower and more important: anything that has to be true regardless of what the model decides cannot live at the same layer as an optional tool. Access control. Audit trails. Memory scope. Supersession. The rules generated code has to conform to before anyone trusts it. These cannot depend on the model deciding to ask.
The people asking what happens after the diff, the people refusing to let an agent's "done" mean done, the people rebuilding memory around write-time correction instead of read-time lookup, are all describing the same missing layer from different rooms.
The category is becoming visible now. Tenure is building it from the bottom up: governed memory and state first, then the broader control plane for context, policy, provenance, audit, and evaluation across enterprise AI requests.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。