Context Governance at Scale
The OS-Paged Context Engine handles the technical lifecycle: what loads, what gets evicted, what passes validation. It produces an immutable manifest for every call. But the manifest tells you what the model saw. It does not tell you whether it should have seen it.
Production agents that handle money, health data, or customer PII need a governance layer above the pipeline. Access control, retention policies, deletion rights, multi-tenant isolation. These are governance problems, not engineering problems. And the industry has not solved them.
The Manifest Is Not Enough
An audit manifest records: trace ID, artefact list, token count, degradation tier, commit status. If a compliance officer asks “what did the agent access?” you can answer. That’s table stakes.
The harder questions:
- Should the agent have had access to that customer’s payment history during a routine support query?
- The artefact was loaded from a shared scope. Three other agents also read it. One of them serves a competitor’s account. Is that a data leak?
- The agent’s response was committed to memory at confidence 0.85. Six months later, the customer invokes GDPR Article 17. Do you delete the artefact, the memory derived from it, or both?
These questions have no clean technical answer. They require policy, and policy requires architecture.
When This Pattern Is Overkill
Not every agent needs governance. Here’s the decision tree:
Skip lifecycle management entirely if:
- The agent is single-session. No memory persists. Standard RAG is sufficient.
- The corpus is small and static (fewer than 100 documents, updated quarterly). Triage and paging overhead exceeds the benefit.
- The agent is read-only. Never writes to its own memory. No compounding hallucination risk.
Use the technical pipeline but skip governance if:
- The agent handles non-sensitive data. Productivity tools, code assistants, research summarisers. No PII, no financial data, no health records.
- Single-tenant deployment. One company, one agent, no cross-customer context risk.
You need the full governance layer when:
- The agent handles PII, financial data, or health records
- Multiple agents share a context store across customers or tenants
- You operate in a regulated industry (healthcare, insurance, financial services)
- The agent persists context for months and customers have deletion rights
Here’s the falsifiable claim: by 2028, any agent system handling PII without an auditable context manifest will fail compliance review in regulated industries.
GDPR and the Tombstone Problem
A customer requests deletion under GDPR Article 17. You purge their artefacts from the context store. The manifests that referenced those artefacts still exist in the audit log. The agent’s behaviour was shaped by context that no longer exists.
Two approaches, neither clean:
Purge completely. Delete artefacts, delete manifests, delete any memory derived from those artefacts. The agent’s future behaviour changes because the context that shaped prior decisions is gone. If Agent B’s response was informed by Agent A’s output, which was informed by the deleted customer data, do you cascade the deletion?
Tombstone. Replace artefact content with a deletion marker: “Artefact deleted per GDPR request, [date].” Manifests remain intact for audit. The agent knows something was here but not what. This preserves audit trail integrity but may not satisfy strict interpretation of “right to erasure.”
The honest answer: I don’t know which is correct. The legal interpretation of “erasure” applied to derived AI context is untested in European courts. What I do know is that you need the manifest layer to even have this conversation. Without an audit trail, you cannot comply with a deletion request at all.
Compliance as Architecture
Enterprise buyers in healthcare, financial services, and insurance ask one question first: can you prove what the agent accessed?
The context manifest maps directly to compliance frameworks they already understand:
| Compliance Requirement | What It Maps To |
|---|---|
| SOC2 audit logs | Context manifest (trace ID, artefact list, timestamp) |
| HIPAA access logs | Manifest + agent_scope (who accessed what) |
| GDPR Article 15 (right of access) | Manifest query: “all artefacts accessed for customer X” |
| GDPR Article 17 (right to erasure) | Artefact deletion + manifest tombstoning |
| PCI-DSS data isolation | agent_scope + namespace isolation per tenant |
But agent_scope alone is not sufficient for multi-tenant isolation. In the current implementation, scope is a string tag. No encryption boundary, no policy engine, no access control list. A developer who writes agent_scope="global" on a PII artefact has just leaked it to every agent in the system.
Production multi-tenant context isolation requires: namespace enforcement (scope is a hard boundary, not a suggestion), policy-as-code (which scopes can read which artefact types), encryption at rest per tenant, and audit logging on every cross-scope access attempt.
What I Don’t Know Yet
The technical primitives for context governance exist: manifests, scopes, commit gates, audit logs. What doesn’t exist is the organisational trust model.
When an agent makes a decision based on six months of accumulated context, who is accountable? The engineer who built the pipeline? The data team that ingested the artefacts? The compliance officer who approved the retention policy?
Kubernetes solved compute governance by making infrastructure declarative. You declare what you want, the system ensures it. Context governance needs the same shift: declare what the agent should access, and the system enforces it. We’re not there yet.
The technical pipeline is built. The infrastructure argument is established. The governance layer is the missing piece. I’m building it in the open, and I don’t have all the answers.