Proof-Carrying Context: Why AI Agents Need More Than a Context Window

Imagine an agent preparing to refund an order.

The order database says ord_881 is the canonical order. The CRM says that order was merged into ord_992. Both records are fresh. Both passed source verification. Both are relevant to order_lookup.

A conventional RAG system has succeeded: it retrieved useful context. A coverage-based gate may also succeed: the required field order_lookup is present. The model now receives two polished, credible passages and is expected to reason its way to the truth.

That is exactly where a production system should stop.

The context is relevant but not sufficient. The runtime has evidence, but it does not yet have a decision basis. If the model selects one record because its wording is clearer, its position is earlier, or its source happens to match parametric memory, a systems conflict has been converted into an invisible model preference.

This is the foundational revision ContextOS needed.

The original thesis was that context should be compiled rather than pasted into a prompt. The stronger thesis is:

A CompiledContext should be a proof-carrying materialized view of the run’s current epistemic state—not a bag of relevant tokens.

“Epistemic” here does not mean hidden reasoning. It means the observable state of evidence: what is supported, what is missing, what conflicts, what was omitted, what resolution was applied, and which decision obligations may safely close.

This essay explains why the research frontier points in that direction, what changed in the ContextOS contract, what remains deliberately unstandardized, and how to evaluate the model without turning a new phrase into another unfalsifiable architecture slogan.

The foundational idea was right, but too weak

ContextOS began from a simple rejection of prompt-centric architecture. Production behavior does not come from a system prompt alone. It comes from the combination of instructions, tools, retrieved evidence, memory, user and agent identity, policy, budgets, session state, and the execution harness that composes them.

That position has become mainstream. Anthropic’s context-engineering account describes context as the complete token state presented at inference and emphasizes continual curation as an agent accumulates tools, results, and history. Its long-running harness work shows why compaction alone is not durable state management: a fresh session needs structured artifacts that preserve the state of work across context boundaries.

ContextOS made the next engineering move: context became a versioned compiler input and output.

ContextPack + RunContext + runtime evidence
  -> deterministic Context Pack Compiler
  -> CompiledContext

That move created useful properties:

• the input policy and source versions can be pinned;
• the output can be budgeted by bucket;
• tool exposure can be derived rather than merely described;
• evidence and memory can remain data_only rather than inherit instruction authority;
• omissions can be recorded;
• the same inputs can be replayed; and
• changes can be evaluated as release candidates.

But the first contract still treated evidence mainly as a set of eligible blocks. It asked whether required evidence was covered by admitted, current, verified items. That is better than RAG by similarity, but it leaves a hole: two individually eligible items can disagree.

The Knowledge Graph spec already said unresolved conflicts on required evidence must hard-fail. The reference compiler did not enforce that promise. The latest research makes this more than a documentation mismatch. It makes conflict state part of the foundational abstraction.

What the research frontier actually says

The useful signal is not that many papers now use the word “context.” The useful signal is that work across retrieval, memory, long-horizon execution, security, and provenance is converging on the same systems boundary.

Relevance is weaker than sufficiency

Google Research’s Sufficient Context work gives the cleanest starting point. It defines context as sufficient only when it contains the information needed for a definitive answer. Relevant context may still be incomplete, inconclusive, or contradictory.

That distinction changes the objective of retrieval. A relevance score asks whether a passage resembles the query. A sufficiency test asks whether the assembled evidence can support the decision. The paper’s analysis also found an uncomfortable failure mode: adding insufficient context can increase a model’s confidence and make abstention worse. In one reported setting, incorrect responses rose sharply when an open model received insufficient context rather than no context.

The production implication is not “use an LLM sufficiency judge everywhere.” The authors’ selective-generation method is useful research evidence, but a governed workflow needs deterministic obligations before an advisory learned rater. For a refund, those obligations might be identity_verified, order_lookup, and policy.eval. The runtime can prove whether each obligation is covered by eligible evidence; it should not ask the generator whether the prompt feels complete.

Models can notice conflicts and still fail to act on them

The ACL 2026 paper When Facts Change tests conflict between retrieved context and model knowledge for stable and recently changed facts. Its most important result for runtime design is not merely that temporal conflicts are hard. Larger models often detected the conflict and verbalized the temporal issue, yet that recognition did not reliably change the final prediction. Explicit prompting increased discussion of mutability without improving factual accuracy.

This breaks a common safety assumption: “If the model is told to check for conflicts, it will handle them.” Conflict awareness in generated reasoning is not conflict enforcement. If a required claim is contested, the runtime must keep the decision open until an explicit rule, authoritative refresh, or accountable reviewer resolves it.

Memory is becoming execution-state management

The memory literature is moving beyond the idea that history should be chopped into embeddings and recalled by semantic similarity.

MAGE, a June 2026 preprint, models long-horizon memory as a hierarchical execution-state tree. The active root-to-current path carries valid state; flawed branches can be isolated and work can resume from a known boundary. Under its evaluation, the design improved success while substantially reducing token use relative to tested baselines. The exact gains are benchmark-specific, but the architectural point travels: state dependencies matter more than surface similarity.

Remember When It Matters, another 2026 preprint, describes “behavioral state decay”: relevant goals, diagnoses, and open subproblems can exist in the history yet fail to influence the next action. A separate memory agent that selectively intervened outperformed passive exposure and always-on reminders in the reported Terminal-Bench and tau-bench experiments. Again, presence in storage is not presence in effective state.

The systems view is reinforced by Agent Memory: Characterization and System Implications, which profiles memory construction, retrieval, and generation separately. It highlights construction scheduling, freshness-versus-latency tradeoffs, write-path cost, and fleet-scale maintenance. Memory is not a feature switch. It is a stateful subsystem with a consistency model.

Finally, APEX-MEM combines a temporal property graph, append-only history, and retrieval-time resolution of evolving or conflicting information. Its reported benchmark results are about conversational memory, not governed enterprise actions, but its structure supports a broader rule: preserve temporal branches, then resolve at the point of use. Do not erase yesterday’s fact merely because today’s fact supersedes it.

Evolving context must resist context collapse

Agentic Context Engineering, published at ICLR 2026, treats context as an evolving playbook updated through generation, reflection, and curation. Its motivating failures are especially relevant: brevity bias drops detailed insights, while repeated rewriting causes “context collapse,” gradually eroding information.

ContextOS agrees with the adaptation target but adds a governance boundary. A model may propose a playbook update, memory item, routing rule, or prompt fragment. The Improvement Loop may evaluate it. Promotion still requires held-out evidence, release gates, versioning, and rollback. Natural execution feedback is useful input; it is not self-granted authority to modify the next run’s control state.

The deeper lesson is that a context artifact must preserve more than its final compressed text. It needs lineage and change semantics. Otherwise a beautifully curated playbook can still hide which source disappeared, which conflicting observation was removed, and whether a failed trajectory was accidentally promoted as strategy.

Trust needs a graph, not a transcript

The 2026 survey From Agent Traces to Trust defines execution provenance as a typed graph of agent execution and evidence tracing as the evidence-support projection of that graph. It connects retrieved evidence, memory, tool results, intermediate claims, actions, and final answers.

This extends a mature provenance tradition. The W3C PROV family separates entities, activities, agents, derivations, and responsibility. Agent runtimes need that discipline because a chronological transcript answers “what appeared next,” not “what derived from what,” “which principal was responsible,” or “which source justified the privileged argument.”

Security research pushes the same boundary from the other direction. Google’s CausalArmor treats indirect prompt injection as a grounding collapse at a privileged decision: untrusted content becomes more causally influential than the user’s intent. The mechanism is different from a declarative provenance graph, but the systems question is identical: which context segment actually supported the action?

The synthesis is hard to avoid. Context is not merely what the model sees. It is the governed state from which the model’s next proposal is allowed to derive.

A better formal model: context as a materialized epistemic view

Database language is useful here because it forces precision.

A materialized view is derived from underlying state. It is not the underlying state itself. It has a definition, dependencies, a refresh policy, and an invalidation problem. A CompiledContext has the same shape:

CompiledContext(t) = materialize(
  ContextPack(version),
  RunContext(t),
  policy_snapshot,
  tool_registry_snapshot,
  evidence_candidates(t),
  promoted_memory(t),
  durable_session_state(t)
)

The materialization result should contain five things:

1. Payload: the bounded blocks the model receives.
2. Eligibility: the policy, identity, integrity, freshness, and budget decisions that admitted them.
3. Dependencies: the source refs, versions, hashes, and derivations needed for replay and invalidation.
4. Negative state: omissions, rejected candidates, unresolved conflicts, and superseded branches.
5. Proof obligations: the conditions that must be true before a governed decision may commit.

This is stronger than a prompt and narrower than a world model. It does not claim that every fact in the enterprise has been reconciled. It claims that the runtime can explain whether the evidence needed for this decision is currently sufficient.

For a decision d, the commit rule becomes:

commit(d) only if every required obligation is:
  covered
  AND admitted
  AND current
  AND verified
  AND free of unresolved conflict
  AND usable under current authority and policy

That expression is conjunctive on purpose. Turning the dimensions into a single confidence score would let strength on one axis compensate for failure on another. Ten highly relevant passages do not repair a tenant-scope violation. A fresh source does not repair missing authority. Two verified sources do not repair a contradiction.

The proof is operational, not mathematical proof of truth. It demonstrates that the declared runtime obligations were satisfied under pinned inputs and rules. It remains possible for an upstream authoritative system to be wrong. What changes is that the error becomes traceable to a source and resolution policy rather than disappearing inside model behavior.

How the five planes change—and why there is no sixth plane

The five-plane model still holds. The stronger context abstraction changes the contracts between planes rather than adding an “epistemic plane.”

Memory remains in the Intelligence plane because it is reusable substrate. Session state remains a Context input because it is run-scoped material. Conflict resolution crosses Intelligence, Context, and Trust: the graph detects; the compiler carries and gates; policy or an accountable reviewer resolves.

This separation matters. If the Knowledge Graph silently picks the highest score, the conflict disappears too early. If the model picks a winner, resolution becomes stochastic and unaudited. If every disagreement requires a human, the system will not scale. The right design supports deterministic source-priority rules where the domain permits them, authoritative refresh when one exists, and human resolution only where judgment is genuinely required.

What changed in ContextOS

The change in the reference contract is intentionally small enough to be testable and large enough to close the documented gap.

EvidenceConflictMarker

Retrieval can now provide a typed marker:

{
  "conflict_id": "conflict:order:ord_881:identity",
  "evidence_refs": [
    "kg:order:ord_881#snapshot_41",
    "crm:order:ord_881#snapshot_19"
  ],
  "requirements": ["order_lookup"],
  "status": "unresolved",
  "subject": "order:ord_881",
  "predicate": "canonical_order_id",
  "values": ["ord_881", "ord_992"]
}

The marker is relation-level state. It is separate from either passage, so budget ranking cannot erase the existence of the disagreement.

A resolved marker must carry both a resolution artifact and the selected evidence:

{
  "status": "resolved",
  "resolution": {
    "resolution_ref": "review:order-resolution:441",
    "selected_evidence_refs": ["kg:order:ord_881#snapshot_41"]
  }
}

The compiler rejects malformed markers, duplicate conflict IDs, invalid selections, resolved conflicts without a resolution ref, and unresolved conflicts that pretend to carry a resolution.

Sufficiency-aware EvidenceGate

The compiler maps relevant conflicts to the active DecisionSpec.required_evidence. An unresolved marker removes the affected requirement from satisfied, adds it to unresolved, records unresolved_conflict against participating evidence, emits sufficiency: "insufficient", and keeps commit_allowed: false.

When an explicit resolution selects a branch, non-selected evidence remains visible as superseded_by_resolution. The losing fact is not deleted from history and is not permitted to satisfy the gate.

{
  "decision_key": "support.refund.execute",
  "required": ["order_lookup", "policy.eval", "identity_verified"],
  "satisfied": ["policy.eval", "identity_verified"],
  "unresolved": ["order_lookup"],
  "conflicts": [
    {
      "conflict_id": "conflict:order:ord_881:identity",
      "evidence_refs": ["kg:order:ord_881#snapshot_41", "crm:order:ord_881#snapshot_19"],
      "requirements": ["order_lookup"],
      "status": "unresolved"
    }
  ],
  "sufficiency": "insufficient",
  "commit_allowed": false
}

The new gate fields are additive in the published v1 schemas. Existing stored v1 records remain schema-valid; the current compiler emits conflict state and sufficiency on every gate. The same EvidenceGate definition flows into DecisionRecord.controls_active, so the decision receipt preserves the exact precondition that allowed or blocked commit.

Conformance, not aspiration

The change includes compiler tests for both paths:

• two current, verified sources in unresolved conflict cannot close the requirement; and
• an explicit resolution allows the selected source to close it while marking the other source superseded.

That test is the difference between a principle and a runtime contract.

Why the model is not the conflict resolver

There are cases where a model can help investigate a conflict. It can identify that two records describe different effective dates. It can retrieve a source-of-record policy. It can explain the disagreement to a reviewer. It can propose a resolution.

Those are evidence-producing actions. They are not the authority to close the conflict.

The final resolution should come from one of three places:

1. Deterministic rule: for example, a signed ledger outranks a derived CRM cache for payment state.
2. Authoritative refresh: a new read from the system of record makes the older branch inapplicable under a declared temporal rule.
3. Accountable review: a named principal selects evidence under a policy-defined decision right, producing a resolution receipt.

This keeps model capability useful without treating eloquence as source precedence. It also makes a later correction possible. If the resolution rule was wrong, the operator can find every decision derived from it and replay those runs.

What remains a candidate extension

The new contract does not solve every context problem, and pretending otherwise would create the next layer of spec drift.

Claim-level provenance graph

EvidenceConflictMarker operates at evidence-ref and requirement granularity. The provenance research points toward atomic claims connected by supports, contradicts, derived_from, used_by, and caused relations across the whole trajectory. That would allow targeted invalidation: when one claim changes, identify every compiled view, intermediate claim, tool argument, and outcome that depended on it.

This is the most important candidate extension, but it needs a stable claim identity model, privacy boundaries, storage-cost evidence, and cross-harness evaluation before becoming a core ContextOS type.

Bitemporal validity

observed_at and valid_until are useful but not a complete temporal model. Many enterprise facts need both valid time—when the fact was true in the domain—and transaction time—when the system learned or recorded it. A policy can be current in the database yet inapplicable to an event that occurred before its effective date.

Temporal memory work and APEX-MEM strengthen the case, but the reference compiler should not invent bitemporal semantics without validated domain rules. For now, source systems and Knowledge Graph snapshots own that interpretation.

Evidence independence and correlation

Two sources are not independent merely because they have different URLs. Five reports may all derive from one corrupted export. Future evidence requirements may need a source_family or derivation-aware diversity condition. The provenance graph is the right prerequisite; counting citations is not.

Learned sufficiency and active memory policies

Learned sufficiency raters and proactive memory agents can improve retrieval and intervention. They should enter ContextOS first as advisory signals and candidate generators. Deterministic gates still own minimum evidence, conflict, authority, and policy conditions. Promotion should depend on calibrated false-closure and false-abstention results for the target workflow.

Causal influence at privileged sinks

Declarative provenance records what the runtime believes supports an action. Causal attribution tests whether removing a context segment changes the model’s proposal. These are complementary. A future Tool Gateway can compare declared lineage with observed influence at high-risk sinks, but the latency, robustness, and privacy tradeoffs still need operational evidence.

The evaluation protocol

A foundational construct should come with a way to prove it wrong. A context compiler should be evaluated on decisions, not on whether its summaries look good.

The dataset needs more than ordinary questions and answers. Each case should include:

• a decision spec and required obligations;
• source snapshots with provenance;
• sufficient, insufficient, stale, untrusted, omitted, and conflicting variants;
• expected resolution policy;
• a no-conflict control;
• model and harness versions;
• tool-side effects disabled or sandboxed; and
• an outcome grader independent of the compiler being evaluated.

The most important slice is adversarially plausible conflict: two sources that are both fluent, recent, and internally consistent. Obvious nonsense only proves that the gate can reject obvious nonsense.

An incremental adoption path

Teams do not need a semantic provenance graph before they can improve their runtime.

The order matters. Starting with a universal knowledge graph project will delay the first safety improvement. Starting with model-authored conflict summaries will create an ungoverned resolution path. Typed markers plus a hard gate are a narrow, testable step.

Three objections worth taking seriously

“Frontier models will solve this themselves”

They will get better at detecting and explaining conflicts. That reduces investigation cost. It does not eliminate the need to record which source and authority justified an effect. Better reasoning changes the inside of the Decision plane; it does not dissolve the boundary between evidence and permission.

“This will make agents abstain too often”

It can, if every disagreement blocks every task. ContextOS gates only conflicts mapped to required obligations for the active decision. A conflict over preferred email tone should not block a refund unless the workflow declares it material. The correct operating target is a measured accuracy-coverage frontier, segmented by action risk—not maximum abstention.

“Resolution receipts add too much machinery”

For low-risk answers, they may. ContextOS is a governed-runtime spec, not a demand that every chatbot use enterprise ceremony. The mechanism earns its cost when an incorrect branch can move money, delete data, alter access, communicate externally, or enter durable memory. Risk should determine control depth.

The deeper conclusion

The context window is a model interface. It is not a systems architecture.

Once an agent runs for hours, retrieves mutable data, remembers prior work, delegates tasks, and causes external effects, the critical question is no longer “What tokens should we put in the prompt?” It is:

What state is this decision allowed to depend on, and what proof must the runtime carry before the effect can commit?

That question pulls together the strongest ideas in current retrieval, memory, harness, provenance, and security research without confusing them.

• Sufficient-context work says relevance is not enough.
• Temporal-conflict work says model awareness is not enforcement.
• Long-horizon memory work says state dependencies matter more than semantic similarity.
• Evolving-context work says lossy rewriting can collapse hard-won knowledge.
• Provenance work says trust requires typed derivation across the trajectory.
• Causal security work says privileged actions must remain grounded in legitimate intent and evidence.

The resulting architecture is not “more context.” It is a smaller, stronger artifact: a bounded view with provenance, conflicts, omissions, obligations, and an explicit right to abstain.

That is what CompiledContext should mean.

What to read next

• Agentic Context Engineering
• ContextOS 2026
• Context Pack contract and compiler
• Context Engineering in Production
• Agent Memory Is a Systems Workload