Governed Context Architecture: Reconstruction, Provenance and Active Memory for Long-Horizon Agents

The hardship case combines recurring context failures seen in long-running workflows. Its cost, latency and control figures are illustrative.

The incident: a collections action nobody should have taken

The composite begins with a complaints team, not engineering. A customer in a loan-hardship arrangement receives a collections letter three days after the agreement is approved and logged in the case-management system. The complaints handler sees the dated agreement in the file and asks the right question: why did the collections workflow still fire?

The case has been running for a little over three months. A long-horizon agent supports intake, income review, proposal drafting, payment-plan monitoring and closure. By the time of the bad decision, its history contains roughly 3,400 turns: status checks, correspondence, internal notes, document events and periodic machine-generated summaries. These figures are deliberately large enough to expose the design problem; they are scenario assumptions, not a disclosed production count.

The decision to continue collections is not a hallucination in the usual sense. The agent does not invent the arrears flag; it reasons from a fact that was correct when recorded. The context itself is defective because nothing invalidates that fact after the hardship agreement is approved.

The later approval is also present, but a summarisation pass has reduced it to “case status updated” while preserving the older arrears flag as a standalone statement. In a history of thousands of turns, the stale statement becomes more salient than the event that superseded it.

This is the shape of the failure this article addresses. Not a reasoning failure. A context failure. The agent was asked a question it could answer perfectly well, using an input that was silently out of date, and nobody, including the agent, had any way of knowing that without going back to the ledger and the case system directly.

The postmortem finding

What the accumulated context actually contained

The reconstruction exercise assumes the exact context window was retained for audit. It contains just under 190,000 tokens, of which about 4,000 are directly relevant: current hardship status, current payment plan and current account flags. The remainder is history: intake correspondence, summaries of earlier summaries, superseded-file metadata and routine status checks. These volumes illustrate the ratio; a real postmortem should calculate it from retained traces.

The arrears flag that triggered the bad decision had entered the context at turn 340, roughly six weeks into the case. It had never been removed. It had never been marked superseded. It survived three separate summarisation passes because each pass, working from an already-compressed prior summary, treated it as an atomic fact worth preserving rather than as a claim with a validity window that had since closed. The hardship agreement, approved at turn 2,100, was present in the context too, but as one line among many in a summary of "recent case activity," competing for attention with routine notes about document uploads and an automated reminder that had fired incorrectly earlier that week.

Nothing in the architecture asked the question that actually mattered: is the arrears flag still true right now. The accumulated context could tell you what had been said about the account. It could not reliably tell you what was currently true, because nothing in the pipeline ever went back to the ledger and asked.

Three weeks is a long time in a live case

Three weeks is enough to separate a correctly applied collections treatment from an invalid one after a hardship agreement should have suppressed it. In a four-month case, that fact still looks recent. The failure was not distant-memory loss. A moderately recent fact had silently outlived its validity, and the architecture had no mechanism to notice.

The composite timing allows nine days from the letter to the complaint and six more to confirm root cause. Most of that time goes into reconstructing what the agent saw because the case history does not expose the stale fact cleanly. The assumed incident process then requires compliance review and a wider search for similar discrepancies. Fourteen additional cases need manual review. These figures illustrate why the investigation population, not only the originating event, drives remediation cost.

The economics of accumulation

Token growth over a case lifecycle

Set the regulatory consequence aside for a moment and look at the plain arithmetic, because the economics alone should have been reason enough to change the architecture. At case intake, the agent's working context was small: around 1,100 tokens covering the application, the customer's stated reason for hardship, and initial income evidence. Under an accumulation model, every subsequent turn, whether a customer message, an internal note, a document ingestion event, or a routine automated check, gets appended to that history.

By day forty, the case context had grown to roughly 64,000 tokens. By month three, it was around 140,000 tokens. By the time of the incident, early in month four, it was approaching 190,000 tokens, close enough to the practical ceiling of the model's context window that the harness was triggering automatic summarisation passes before every decision, compressing older sections to make room.

Cost tracks this growth almost linearly until summarisation passes kick in, at which point it worsens, because every decision now pays for both the summarisation call and the decision call itself. Per-decision cost at intake was a few cents; by month four it had risen to a little over two dollars, an order of magnitude increase, for a task that had not become intrinsically harder. The case had not gained complexity in proportion to its token count. It had gained history.

Latency and the signal-to-noise problem

Latency followed the same curve. A 190,000-token context takes materially longer to process than a 1,100-token one, and the summarisation passes added their own sequential latency, because the harness could not fire the decision call until compression had completed. Early in the case, decisions returned in under a second. By month four, the agent took eleven to fourteen seconds to produce a decision a human caseworker, looking only at current status, could sanity-check in under a minute.

The deeper problem is not raw cost or latency, it is signal-to-noise. As the context grows, the proportion actually relevant to the decision at hand shrinks, and the model must do implicit work every time to figure out which parts of a sprawling history still matter.

Summarisation is supposed to solve this, but summarisation performed on an already-lossy summary compounds the loss in a specific direction: it preserves facts that look decision-relevant in isolation while flattening the temporal relationship between them, such as an arrears flag predating a hardship approval that should have superseded it.

The signal you actually need at decision time, which is not what has been said but what is currently true, gets steadily harder to recover the longer the case runs, because the mechanism relied on to manage growing volume is optimised for compressing content, not preserving currency.

Staleness as a distinct failure mode

Why this is not hallucination

I want to be precise about this distinction because it changes what you build to fix it. Hallucination, in the sense most engineers mean it, is the model asserting something that has no basis in its input: inventing a document that does not exist, misquoting a figure, fabricating a citation. The fix for hallucination is generally some combination of better grounding, retrieval, and verification against source material.

Staleness is different. The model in the composite is grounded. It does not invent the arrears flag; the flag was a correct earlier observation. The reasoning from that flag to a collections action is sound in isolation. The failure is temporal: the input's validity window has closed, but nothing marks it as closed. A well-grounded, calibrated model can still produce a confidently wrong decision when the evidence is stale. Hallucination and staleness therefore require different controls.

Why calibration and prompting don't fix it

It is tempting to reach for a prompting fix: tell the model to be suspicious of older facts, or to weight recency more heavily. This helps at the margin but does not solve the underlying problem. The model cannot know whether a fact is old or superseded unless that information is present in context. Asking it to consider information it does not have cannot close the gap.

Better timestamping and supersession markers slow the decay. The fundamental issue remains architectural. An accumulated history records what was said, not what is true now. For any load-bearing fact, return to the system that owns current state when the decision is made.

The reconstruction pattern

Ground truth sources

Reconstruction starts by defining ground truth for the domain. In the reference design, three systems own load-bearing state: the case-management system owns status, hardship flags and workflow state; the document store owns the current authoritative document version; and the core ledger owns balance, arrears status and payment history. If one of those systems can answer a question directly, accumulated conversation history should not be treated as the authority, however recent it appears.

The test is simple: does this system get updated by a process independent of the agent, and would a caseworker asked to verify a fact go to this system rather than to their own notes. The case management system passes. The agent's own running commentary on the case does not, no matter how detailed it becomes.

The context assembly layer

The architectural change is to insert a distinct layer between the agent and its ground truth systems, whose only job is to assemble a fresh, bounded context at each significant decision point by querying those systems directly, rather than handing the agent an ever-growing transcript. This is not retrieval-augmented generation in the conventional sense of pulling passages from a static corpus. It is closer to a live query layer: at the moment a decision is required, the assembly layer asks the case system for current status, the document store for the active document set, and the ledger for current balance and payment position, building a context from those live answers and discarding everything not needed for this specific decision.

The practical effect on the collections case would have been immediate. At the moment the workflow considered issuing a collections letter, the assembly layer would have queried the case system directly, received a current hardship flag set to active, and either suppressed the action as a deterministic rule or passed that flag into the agent's reasoning as the operative fact, with no competing three-week-old arrears flag anywhere in the context. The stale fact was never a risk in a reconstructed context, because reconstruction never looks at what was true three weeks ago, only at what is true now.

What gets included and what gets left out

This is the part that takes the most judgement, and it is where certainty-gradient thinking earns its keep. Not every piece of context should be reconstructed by a deterministic query, nor should everything be handed to the model to reason over freely. Facts with a clear, current source of truth, such as account balance, hardship flag, active document set, or payment schedule, belong on the deterministic end: fetched directly, included verbatim, never paraphrased, because paraphrasing a number or status flag is where provenance quietly leaks away.

Facts that genuinely require judgement, such as whether a stated change in circumstances supports a further payment variation, belong on the reasoning end, and the model can work with a richer, more narrative context for those specific sub-decisions, so long as the load-bearing facts beneath that reasoning are still the freshly queried ones.

The general rule I apply: reconstruct anything a regulator, auditor or customer may ask you to justify with a specific number or status. Reason over what is genuinely interpretive. In the composite, the failure occurs when summarisation folds a hardship approval into a vague "case status updated" line instead of preserving it as a distinct, queryable flag.

Versioning, replay and auditability

The context ledger

Reconstruction only delivers its full value if you also version what gets assembled. Every time the assembly layer builds a context for a decision, it should write a record of exactly what it queried, from which system, at what timestamp, and what came back, before that context is handed to the agent. Call this the context ledger, distinct from the case management system's own audit log, because it does not record what happened in the case, it records what the agent believed to be true at the moment it acted.

This is the property that makes reconstruction auditable in a way accumulation is not. With accumulation, answering "what did the agent know when it made this decision" requires recreating the state of a repeatedly compressed history at a particular point in a long transcript. In the composite, that takes several days of specialist forensic work even with raw logging. With a context ledger, the decision entry names the queries and responses, so the context can be replayed directly.

Certainty-gradient placement in assembly

The context ledger also gives a natural place to record which parts of an assembled context were fetched deterministically and which were left to model reasoning, where certainty-gradient placement becomes an operational discipline rather than a principle applied once and forgotten. Each field can carry a tag: deterministic-fetch, meaning it came straight from a ground truth query with no model involvement, or reasoned, meaning the model interpreted or synthesised something from the deterministic facts.

When something goes wrong, this tag tells you immediately whether the failure was a bad query against ground truth, rare, and usually a source data quality problem, or a bad piece of reasoning applied to correct facts, the more common failure and the one adversarial verification is designed to catch. Separating these two failure classes at assembly time, rather than untangling them later from a monolithic transcript, is most of what makes a long-horizon agent operationally manageable at scale.

The table below summarises how the two approaches compared across the case in this postmortem, once the numbers from the economics discussion above and the audit exercise were laid side by side.

Quarantine and provenance in reconstructed context

Reconstruction solves staleness, but it introduces its own question: what happens when a ground truth system itself receives an update from an unverified or external source, such as a customer uploading a document, a third-party data feed reporting an income change, or a note entered by a call centre agent not yet reviewed. If the assembly layer treats every write to a ground truth system as immediately authoritative, the staleness problem has simply moved sideways into a trust problem: the agent might reconstruct a context containing a fact that is fresh but wrong, rather than stale but once right.

This is where quarantined memory belongs alongside reconstruction. Content from an unverified or external source should enter a staging zone with provenance and review status, not the promoted state read by the assembler. A customer's uploaded bank statement remains quarantined until a caseworker or verification control confirms authenticity and supersession. After promotion, every fact retains a pointer to its source record. In the worked hardship path, a verified approval tag is enough for a deterministic rule to suppress the collections letter; no model judgement is required.

Where accumulation still belongs

It would be a mistake to read this as an argument against accumulation everywhere. Accumulation is fine, and often preferable, for short-horizon conversational turns where the entire interaction completes within a single session and nothing about the exchange has an external effect that needs to survive or be audited independently: a customer asking a general question about how hardship arrangements work, a caseworker asking the agent to summarise a document already in front of them, a quick clarifying exchange within a single sitting. The cost of reconstruction is not worth paying here, because there is no meaningful staleness risk across a session lasting minutes, and the audit requirement is minimal since no external action has been taken.

The dividing line in practice is whether a step has an external effect or needs to be independently auditable later. Sending a letter, initiating a collections action, approving a payment variation, closing a case: these have consequences that persist and that someone might eventually need to justify by reference to exactly what was known at the time. These are reconstruction-mandatory by default. Answering a question, drafting a first pass for human review, summarising something the caseworker can already see: these can stay on cheaper accumulation, because the cost of being wrong is low and immediately correctable.

There is a middle category: steps that are reversible and low-stakes individually but can compound over a long case, such as status checks and reminder scheduling. These may use lightweight accumulated context if the case system forces reconstruction at material transitions: approval, variation, missed payment and closure. That keeps routine cost close to the accumulation baseline while bounding the life of stale assumptions.

Worked example: a four-month hardship case

To make this concrete, walk through the same hardship case at four checkpoints and compare what an accumulated context would contain against what a reconstructed context contains at the identical moment.

At intake, in month one, the two approaches look almost identical, because there is not yet much history to diverge over. The accumulated context holds the initial application, the customer's stated reason for hardship, and the first income evidence submitted. The reconstructed context holds the same information, but pulled fresh from the case system and document store rather than carried forward as a transcript, which matters less here than it will later.

By the payment variation checkpoint in month two, the two contexts have started to pull apart. The customer has requested a schedule change, and the case has been through one round of internal review. The accumulated context now carries the original proposed schedule, the caseworker's internal notes debating it, and the final agreed variation, all present simultaneously, leaving whoever reads the context to work out which schedule actually holds. The reconstructed context simply asks the case system for the currently active schedule and receives one answer: the agreed variation, with no earlier draft cluttering the picture.

The third checkpoint matters most, inside the composite's stale-fact window in month three. The accumulated context still carries the earlier arrears flag alongside a later hardship approval, with no marker showing supersession. The reconstructed context queries the ledger and receives one current answer: hardship flag active, standard collections suppressed.

At closure in month four, the accumulated context is a sprawling transcript that has been through several summarisation passes, its provenance difficult to trace without manual archaeology. The reconstructed context at closure contains the final case state, the closure documents currently marked active, and the ledger's settlement figure as of the closure timestamp, each field carrying a direct pointer back to its source system.

The pattern across all four rows is the same: accumulation keeps everything that was ever true and asks the reader to work out what still is, while reconstruction only ever asks what is true right now and hands back exactly that, nothing more.

Failure modes in reconstruction itself

Reconstruction is not a free lunch and deserves the same scepticism applied to accumulation. The most common failure is ground truth lag: the assembly layer queries a system that has not itself been updated yet, because the update is still propagating through an upstream batch process or an eventual-consistency delay. If the ledger only refreshes arrears status overnight, a context assembled mid-afternoon can be confidently fresh and still wrong, a different failure than the original incident but with a similar shape.

The fix is to make the assembly layer aware of each source system's actual consistency guarantees, recording in the context ledger not just what it fetched but how current that source claimed to be, so a decision made against a system known to lag by hours is flagged with that specific risk rather than presented with the confidence of a real-time query.

A second failure mode is over-fetching, where an assembly layer built without discipline queries every available ground truth system on every decision regardless of relevance, recreating a version of the bloat problem it was meant to solve, just sourced from live queries rather than accumulated history. The discipline is to define, per decision type, exactly which ground truth fields are required, and resist fetching broadly "just in case," because every unnecessary field reintroduces noise and cost without adding auditable value.

A third is partial assembly failure: one ground truth system responds and another times out, and the agent proceeds on an incomplete context without anyone flagging that the context was incomplete. This is arguably worse than either accumulation's staleness or a clean over-fetch, because it looks like a properly reconstructed context while silently missing a field that mattered. The mitigation is straightforward but easy to skip under delivery pressure: the assembly layer must fail closed, refusing to hand a context to the agent for any reconstruction-mandatory decision unless every required ground truth query succeeded, with a clear escalation to a human rather than a best-effort context substituted silently.

A fourth, subtler failure is assembly layer drift from the ground truth schema itself: source systems change their data models over time, a status field gets renamed or a new intermediate case state gets introduced, and if the assembly layer's query logic is not kept in lockstep with those changes, it can silently stop returning a field it used to return, or return it under a name the downstream context template no longer recognises. This is a data engineering problem more than an agent architecture problem, but it sits squarely in the reconstruction pipeline's blast radius, and it needs the same change management discipline you would apply to any schema affecting a production data pipeline, including contract tests against the assembly layer's expected query outputs.

Context is a decision interface

Context is commonly described as information sent to a model. For production architecture, that definition is too weak. Context is the governed interface between enterprise reality and probabilistic reasoning. It decides which customer, case, policy, evidence, history and authority the model can see at a particular decision point. A model can reason only over that representation. If it is stale, incomplete, over-broad, unauthorized or internally contradictory, increasing model capability can make the resulting error more articulate without making it less likely.

The context service should therefore be treated like a decision-critical data product with an explicit contract, owner, lineage, service objective, test suite and change process. Its output is not a bag of retrieved chunks. It is a versioned decision snapshot assembled for a named principal, purpose and decision type.

Four classes of information should remain distinct:

Conversation history is not a fifth authoritative source. It may contain useful working material, but its statements inherit the trust of the sources behind them, not the confidence of the prose. When an agent says “the customer is in arrears,” the architecture must distinguish among a live ledger read, a customer statement, a prior agent summary and an old case note. Treating all four as text in one prompt destroys the difference most important to a regulated decision.

The context contract is evaluated before retrieval, not after generation. It names what may be fetched and why. This prevents a common pattern in which an agent retrieves broadly under a service credential, then relies on a prompt instruction not to reveal information the user should never have received. Authorization after retrieval is data-loss prevention. Authorization before retrieval is least privilege.

The decision-specific context contract

A context contract declares the information required and permitted for one decision type. It should be human-readable enough for a domain owner to review and machine-readable enough for the context service to enforce.

contract_id and version
decision_type and purpose
requesting principal and delegated subject
required authoritative fields
optional evidence classes
allowed source systems and jurisdictions
field-level authorization predicates
freshness and consistency requirements
source precedence and contradiction policy
token and latency budget
required claim-evidence coverage
failure and escalation behavior
retention and redaction rules

The distinction between required and optional fields is operationally important. If a required ledger state is unavailable, the context assembly fails closed for a consequential decision. If an optional historic note is unavailable, the snapshot can be marked partial and continue if the decision design permits it. Without this classification, teams either stop unnecessarily on every missing enrichment or proceed dangerously when a load-bearing fact is absent.

Source precedence should be explicit. A verified system-of-record field may outrank a customer statement for current account status while the customer statement remains important evidence of a dispute. An approved policy version outranks an old procedural guide. A signed document may outrank an extracted value when the extraction confidence is low. Contradictions should be preserved and surfaced, not resolved by silently taking the most recent chunk or the text with the highest vector similarity.

The contract also creates a clean place for data minimization. A credit-memo task may require facility exposure and financial statements but not unrelated retail transactions. A financial-crime investigation may require network and identity evidence inaccessible to a general servicing agent. Purpose binding means the same employee or agent principal can receive different fields for different approved tasks, with every decision recorded.

Bitemporal state: what was true and what was known

Regulated decisions often require two times. Valid time describes when a fact was true in the business world. System time describes when the institution recorded or learned it. If a customer’s address changed on Monday but the verified update arrived Thursday, a decision made Wednesday may need to be replayed using what was known Wednesday, not what the database contains today.

Every authoritative field used in a consequential context should carry:

• value;
• source system and record;
• valid-from and valid-to time where the domain supports it;
• observed or recorded time;
• verification status;
• context extraction time;
• schema and source version.

This makes later replay honest. A current-state reconstruction answers “what is true now?” A historic reconstruction answers “what did the system know at decision time?” These are different queries. Retrospectively substituting corrected data into an old decision can make a flawed decision appear reasonable or a reasonable decision appear flawed.

A context snapshot should have its own immutable identifier and manifest listing the exact source versions and queries. The full sensitive content need not be copied permanently; references and hashes can support controlled reconstruction. For sources that may change without version history, the architecture may need a protected evidential copy or event stream. Otherwise “replay” becomes a fresh query against a different reality.

Authorization before retrieval

Enterprise search systems often retrieve first and filter later. That pattern becomes more dangerous when an agent can reformulate queries, follow links, call tools and combine weak signals into sensitive inferences. The context plane needs policy enforcement at several levels:

1. principal identity and delegated authority;
2. approved purpose and decision type;
3. source-system access;
4. row, object and customer access;
5. field and document-section access;
6. geographic and residency constraints;
7. retention and downstream-use restrictions;
8. model/provider eligibility for the data classification.

The retrieval service should receive a signed decision context, not a free-form user string alone. It derives allowable sources and filters from the contract and principal. The model may propose search terms, but it cannot widen the authorization filter. Retrieved results retain access labels so later agents, graders and logs do not accidentally receive content outside their own rights.

This pattern also constrains model providers. The context policy can route public or low-sensitivity material to one approved model class and require a different environment for confidential or regulated data. The routing decision becomes visible and testable. It is not left to application code to choose an endpoint independently.

Retrieval is a coverage problem

Top-k semantic similarity is a useful primitive but a poor definition of context quality. A decision may require evidence for several distinct claims: customer identity, income, existing exposure, policy eligibility and an exception. The five most similar chunks may all support income and leave the exception uncovered. The context assembler should plan retrieval against required claim classes and stop only when coverage, authority and freshness are adequate or the system explicitly escalates the gap.

One pattern is a claim-evidence graph. The decision contract defines required claim types. Retrieval produces candidate evidence nodes with source, time, authority and access metadata. An entailment or rule layer proposes support or contradiction edges. Coverage checks identify unsupported material claims before the model produces a final recommendation.

ADORE’s enterprise-RAG architecture is a useful recent research signal because it uses structured memory and claim-evidence planning to make evidence coverage part of execution. The enterprise extension is to bind that structure to identity, policy, time and action. Evidence is not only what makes an answer grounded; it is what makes an eventual decision contestable.

Hybrid retrieval remains valuable inside this structure. Lexical search preserves exact identifiers and policy terms. Dense retrieval captures paraphrase. Graph traversal follows known entity and relationship structure. Structured queries retrieve current state and calculations. Reranking can combine relevance with source authority, freshness, diversity and claim coverage. The retrieval score should never be interpreted as truth probability.

Active memory, not unlimited memory

Recent research suggests a shift from memory as a passive store to memory as an active control process. The question is not only what can be remembered, but when memory should intervene, which representation should be retrieved, and how the system links compressed memory back to raw evidence.

The 2026 paper Remember When It Matters models memory intervention around behavioural degradation in long-horizon tasks. Its practical implication is that continuously injecting more remembered material may be inferior to detecting when the agent is losing task state and selectively restoring the needed constraints or observations. HORMA’s “organize, then retrieve” approach uses hierarchical summaries connected to raw trajectories, emphasizing structure before search and retaining paths back to detailed experience. OCR-Memory explores a different representation: compressing long interaction history into high-density visual memory and retrieving localized content when needed. These papers are preprints and their reported gains do not establish enterprise suitability, but together they indicate that memory architecture is becoming a policy over state and representation, not simply a larger vector database.

For a bank, an active-memory controller should remain subordinate to the context contract. It may decide that a prior approved procedure, unresolved question or failed tool pattern is relevant. It cannot decide that an unauthorized customer record should enter context. It can request a memory; the authorization and provenance gates decide whether the memory is admissible.

The enterprise value is not remembering everything. It is avoiding repeated rediscovery while preventing old, weak or malicious material from becoming truth. A reviewed resolution pattern may help a later investigation. A model-generated guess that happened to precede success should not automatically become policy.

The memory write path is a high-risk tool

Teams often govern what an agent reads and leave memory writes open because writing seems passive. A memory write changes future behaviour and can propagate across sessions, users and agents. It deserves a tool contract, authority and review policy.

Every proposed memory needs:

• memory class and intended future use;
• source evidence and trace identifier;
• authoring principal;
• extraction or synthesis method;
• confidence or verification status;
• customer, domain and purpose scope;
• sensitivity and access labels;
• valid period or expiry;
• supersession relation;
• review and promotion state.

The default state should be quarantine. Deterministic observations from authoritative systems may be promoted automatically if the write preserves source and version. Model-synthesized procedures, lessons or user preferences need stronger tests because they can encode an error, a prompt injection or an accidental generalization from one case. Cross-customer or enterprise-wide memory should require explicit review and an owner.

Memory poisoning should be tested like prompt injection with persistence. A malicious document may instruct the agent to store a false procedure that appears in later unrelated sessions. The write gate should separate document content from system instructions, detect unsupported normative statements, restrict which tools or models can propose reusable memory, and run conflict checks against approved policy. Read-time defenses alone are late; the contaminated memory may already have influenced many traces.

Deletion and correction matter as much as admission. If a source record is corrected, privacy rights require deletion, or an incident invalidates a procedure, the system must locate derived memory and downstream summaries. Provenance creates that reverse index. Without it, the organization can remove the original document while leaving its content embedded in summaries, vectors and experiential memory.

Evidence packing under a token budget

Context windows are finite even when they are large, and larger windows do not remove attention dilution, latency, cost or privacy exposure. The assembler should allocate a token budget by decision need rather than filling the available maximum.

A practical order is:

1. invariant instructions and action constraints;
2. identity, authority and current state;
3. decisive evidence and contradictions;
4. current plan and unresolved questions;
5. supporting background;
6. optional examples or experiential memory.

When the budget is exceeded, lower-priority material is removed or compressed first. Required claims never lose their only supporting evidence silently. Compression must retain source links, time and uncertainty. A summary without those properties is convenient prose, not evidence.

Evidence packing can be formulated as a constrained selection problem: maximize material claim coverage, authority, freshness and diversity subject to token, latency, authorization and sensitivity constraints. This framing explains why naive top-k performs poorly: it optimizes local relevance to a query, not coverage of the decision.

The model should receive a compact context manifest alongside content: snapshot ID, source IDs, policy version, time, completeness state and known gaps. If the snapshot is partial or contradictory, the agent should not infer completeness from fluent formatting.

Multi-agent context without authority creep

Multi-agent systems complicate context because agents have different roles and rights. A research agent may access broad public and internal knowledge but no customer data. A case agent may access one customer and selected tools. A verifier may see claims and evidence but not execute. An approval agent or human proxy may receive a concise decision package. Passing a shared global conversation among them collapses these boundaries.

Use context projection: each agent receives a role-specific view derived from the same snapshot and contract. Delegation creates a child context with equal or narrower authority, never broader authority inherited from the orchestrator’s service account. Returned results carry provenance and access labels so the parent cannot disclose material it was not entitled to consume.

The join is a policy point. If a child accessed data under a specialized mandate, its raw result may need redaction or aggregation before the parent sees it. “The agent already retrieved it” does not establish permission to propagate it. This is the context equivalent of preventing authority creep in tool delegation.

Evaluating the context plane

Answer quality alone cannot diagnose the context system. Evaluate it directly.

Create context-specific adversarial tests: a document with malicious instructions; an old policy with higher semantic similarity than the current one; two customers with similar names; a source update during reasoning; a revoked permission; an apparently useful memory without evidence; a deleted source with derived summaries; and a retrieval outage affecting one required claim. The expected result is often refusal or escalation, not a fluent answer.

Evaluation should also compare architecture alternatives under the same model. Test accumulation versus reconstruction, top-k versus coverage planning, unrestricted retrieval versus context contracts, and passive versus gated memory. Holding the model constant reveals whether the context plane, not a newer model, created the improvement.

Context incident response and blast-radius analysis

A context incident needs a different first response from a model-quality incident. Retraining is rarely the immediate remedy. The initial questions are: which state, source, policy or memory object was wrong; when did it become wrong; which decisions consumed it; and can the institution still identify their downstream effects?

Start by freezing mutable evidence. Preserve the context manifest, source versions, policy result, memory reads, model configuration, tool calls and effect receipts for the triggering decision. Do not rely on the conversational transcript alone. The transcript may be where the defect became visible, but the manifest identifies the data and controls actually used.

Next classify the fault. A source fault means the authoritative system itself held incorrect or late state. An assembly fault means the source was right but the context service selected, transformed or omitted it incorrectly. A policy fault means the wrong identity, purpose or field rule was applied. A memory fault means an admitted item was stale, poisoned, improperly scoped or no longer supportable. Reserve “model fault” for cases where the assembled evidence and controls were sound but the model still drew an unsupported conclusion. Each class has a different containment action and owner.

Containment should be narrow when the evidence allows it and broad when it does not. If one contract version omitted a newly introduced hardship status, disable that contract and route its decision class to manual handling. If a memory object crossed customer or jurisdiction boundaries and lineage is incomplete, disable the entire memory class until affected reads can be enumerated. Isolation by contract, source, tenant, policy and memory item therefore determines how much useful service survives an incident.

Compute blast radius from lineage rather than guessing from time. The context ledger should support queries from a defective object outward: every manifest that included the source version or memory item; every decision produced from those manifests; every approval and tool action linked to those decisions; and every observed effect. Time windows remain useful, but they are a fallback when lineage is missing. “All cases processed between Tuesday and Friday” is a crude substitute for “these 137 decisions consumed source version 42.”

For mutable sources, use bitemporal fields to distinguish two populations. The first includes decisions made while the incorrect state was considered valid. The second includes decisions made after the correction was known but before caches, indexes or summaries reflected it. That second interval explains why a source correction may not end an incident. Propagation lag is part of the control surface.

Memory requires descendant analysis. A faulty item may have been summarized, embedded, copied into a shared workspace or used to create a procedure. Deleting only the original leaves derived representations available for retrieval. The write path should retain derived-from and supersedes links. Containment can then quarantine the item, its embeddings and its descendants while preserving them under restricted access for investigation.

Remediation follows effect, not merely bad context. A flawed snapshot that produced no action may require evidence correction and control improvement. The same flaw used to send a letter, change a limit, close a case or expose restricted data requires customer, operational, compliance or privacy assessment. Effect receipts make this distinction available without manually replaying every trace.

Recovery is a new release, not an informal return to service. Correct the source, adapter, policy or memory rule; reproduce the triggering case; run the relevant temporal and adversarial scenarios; compare the rebuilt manifest with the expected one; and re-enter through shadow or bounded canary mode. The release record should state the incident population, correction, tests, remaining uncertainty and owner accepting residual risk.

Measure incident readiness before an incident occurs. Choose a synthetic source version and ask the platform team to enumerate every context manifest and downstream action that consumed it. Choose a synthetic memory item and trace its descendants. Choose a policy version and identify every decision authorized by it. If these questions require an ad hoc search across unrelated platforms, the context architecture is observable but not yet controllable.

The exercise should produce four timed measures: detection to containment, containment to affected-population estimate, estimate to effect review, and correction to controlled recovery. It should also identify the manual joins still required between the context ledger, case system and action platform. Those joins are where investigation delays and undercounted populations usually arise.

Do not optimize only the first measure. Rapidly disabling a service is useful, but a team that cannot identify affected decisions still faces a prolonged remediation. The target state is both fast containment and precise reconstruction. That combination depends less on a sophisticated model than on disciplined identifiers, immutable manifests and effect lineage built before release.

Cloud-neutral deployment mapping

The logical architecture can be implemented on any major cloud without surrendering portability at the control level.

The strategic design decision is where portability matters. Model invocation and embeddings are replaceable when hidden behind a gateway and stable evidence contracts. Identity semantics, policy, source lineage, context manifests and memory governance are institutional assets and should not be encoded solely in one model provider’s conversation object. Cloud-native services can implement them while the contracts remain explicit.

A ninety-day context-backbone programme

Days 1–30: map decisions and sources

Choose one material journey. Inventory decision types, authoritative fields, evidence classes, current retrieval, memory writes, permissions and audit gaps. Define context contracts for the two or three decisions that create the most risk or review effort. Establish snapshot and source identifiers across the path.

Days 31–60: build reconstruction and evidence

Implement authorization before retrieval, current-state assembly, claim-evidence coverage, context ledger and fail-closed behavior for missing required fields. Add a bounded working-memory service. Keep experiential memory read-only or quarantined until write governance exists. Compare against the current accumulated-context baseline.

Days 61–90: add active memory and production assurance

Introduce selective memory intervention for reviewed procedures or unresolved task state. Add promotion, expiry, supersession and deletion lineage. Run adversarial, temporal and failure tests. Shadow live decisions, measure completeness, latency, review effort and error. Release only the decision classes whose context evidence meets the agreed threshold.

The reusable product is a context backbone, not one RAG application: identity-bound contracts, source adapters, evidence graph, snapshot ledger, memory policy, evaluation harness and operating ownership. Each new agent defines a context contract rather than rebuilding retrieval and permissions from the beginning.

Business and consulting implications

The context backbone is where several enterprise-AI value arguments meet. It reduces repeated integration work, constrains data exposure, improves answer and decision quality, shortens investigation, supports model substitution and makes reuse credible. More importantly, it changes what higher-value agentic use cases can be approved. An institution will not responsibly grant more action rights to an agent whose knowledge state cannot be reconstructed.

This is consistent with current market evidence. Google Cloud’s 2026 infrastructure research reports that production autonomy is exposing infrastructure, governance and MLOps gaps. AWS’s enterprise guidance emphasizes agent identity, registries, access controls and audit as maturity increases. Microsoft’s maturity guidance treats governed data, managed identity, approved connectors, lifecycle and observability as prerequisites for scale. The BIS’s 2026 analysis of AI data in financial services emphasizes quality, privacy, security, third-party concentration and lifecycle governance. These sources differ in audience, but all point away from the idea that the next step is merely a larger model connected to more documents.

For consulting firms, the opportunity is not another generic RAG accelerator. It is a governed context transformation combining data architecture, identity, knowledge engineering, model risk, process design and delivery. The engagement begins with decisions and source authority, not vector-store selection. Its measure of reuse is how many journeys adopt the contracts, evidence and controls, not how many demonstrations share a chat interface.

Sources and limits

The architecture draws on delivery work and current research. The incidents combine recurring failure patterns, and the figures require institution-specific validation. This is a design to test, not a claim of a new empirically proven algorithm.

The active-memory discussion draws on recent preprints: Remember When It Matters, HORMA, OCR-Memory, and ADORE. Their findings motivate design hypotheses but should not be generalized beyond their evaluated settings without replication. Regulatory and industry implications draw on official sources including the BIS data-governance paper, the Bank of England’s work on AI in the financial system, and current hyperscaler production guidance.

The architectural proposition is testable. For long-horizon, consequential work, reconstruct authorized current state; retrieve against required evidence coverage; preserve temporal provenance; admit memory through a governed write path; and evaluate the context plane independently of the model. Context is not whatever happens to fit in the window. It is what the institution is prepared to stand behind at the decision point.

A service objective for decision-ready context

Platform teams need an operational definition of “context ready.” Availability alone is insufficient: the service can return a fast response that is incomplete, stale or unauthorized. Define a decision-readiness objective per contract.

A snapshot is ready only when every required field is present or explicitly marked unavailable; every material evidence class meets its coverage threshold; source and valid-time metadata are intact; authorization succeeded for the requesting principal and purpose; contradictions are surfaced; the state version remains current; and the manifest has been durably written. Latency is measured only among snapshots meeting those conditions. A fast invalid snapshot is a control failure, not a latency success.

Report readiness rate, refusal rate, gap reason, reconstruction latency, snapshot age, source failure and replay success by decision type. Do not average a low-risk knowledge search with a consequential case decision. The contract with the strongest freshness and completeness need will naturally cost more; that is visible architecture economics rather than unexplained platform overhead.

The objective also creates honest degraded modes. An internal assistant may continue without optional background and display the gap. A consequential action may pause when a required ledger source is unavailable. A safety action may use a narrowly defined emergency context contract. These modes are designed and tested in advance rather than invented by the model during an outage.

Ownership should be equally explicit. Data owners certify source meaning and timeliness; the context-platform owner certifies assembly, authorization and replay; domain owners certify decision requirements; risk functions challenge coverage and failure assumptions; operations owns recovery. Without this division, every context defect is assigned vaguely to “the AI,” and no team can correct the actual contract, source or control that failed. Decision-ready context is a shared enterprise product with named accountabilities, not middleware that disappears between the data platform and the agent team.

Questions at the context design review

A context design review should begin with the decision, not the retrieval product. Which facts must be true before this decision can be made? Who owns each fact? Which source is authoritative for its present value, and which source preserves its historical value? What freshness limit applies? What happens when the value is absent, contradictory or unavailable? If those answers are not explicit, adding another index or a larger context window cannot make the decision ready.

The review should then follow authority end to end. Which human and workload principals are acting, for what purpose, and under whose delegation? Is authorization enforced before candidate documents, rows or fields are retrieved? Can a child agent observe information that the parent or final recipient is not permitted to receive? Does the evidence manifest preserve redaction and purpose constraints when context is summarized, cached or passed between agents? A secure source attached to an insecure context assembly path is not a secure system.

Memory requires its own challenge. Which class is being written: working state, episodic event, semantic claim, procedure or profile? What evidence supports it? Who can approve promotion? When does it expire or become superseded? How is a correction propagated to summaries and derived memories? A useful answer generated once is not automatically safe future context. The write path needs more scrutiny than the read path because one weak inference can otherwise become a durable premise for many later decisions.

The final questions concern operation. Can the team reproduce the exact context for a past decision? Can it detect a source update that occurs mid-trajectory? Are incomplete snapshots refused or visibly degraded? Do service objectives measure readiness, not merely response time? Can operations stop assembly, quarantine a source and identify affected decisions without assistance from the original developers? When these questions have evidence-backed answers, context has become an enterprise control plane rather than an accidental prompt payload.

Notes for practitioners

Start by inventorying, explicitly and in writing, which systems qualify as ground truth for which classes of fact, and resist letting the agent's own case notes or memory store quietly become one of them, no matter how convenient. If a caseworker would go to a specific system to verify a fact, that system is your ground truth for that fact.

Draw the accumulation-versus-reconstruction line by external effect and audit requirement, not by convenience or existing code structure. Any decision resulting in a letter, an action against an account, or a status change a regulator might later ask about should be reconstruction-mandatory, regardless of how expensive that feels the first time you build it.

Build the context ledger before an incident. In the composite postmortem, the largest investigation cost is reconstructing what the agent knew from a transcript never designed to answer that question. A ledger recording what was queried, from where and when turns a multi-day forensic exercise into a direct lookup.

Tag every field in an assembled context as deterministic-fetch or reasoned at the point of assembly, and keep that tag through to logging. This single piece of metadata does more to speed up root cause analysis than almost anything else in the architecture, because it immediately tells you whether a bad decision came from bad data or bad reasoning over good data.

Set explicit reconstruction checkpoints at material state transitions rather than reconstructing on every single turn, which is unnecessary for routine activity and adds cost without adding safety. Let the case management system's own recognised state transitions (approval, variation, missed payment, closure) define those checkpoints, so the boundary is owned by the domain model rather than by an arbitrary engineering convention that will drift over time.

Quarantine anything entering a ground truth system from an unverified or external source before it is promoted to a state the assembly layer can read, and make the promotion step an explicit, logged action with its own provenance trail, not an implicit side effect of the write itself.

Finally, reconstruction is more expensive per call in the narrow sense: more queries, more round trips and more source-system integration. Compare architectures across the full case lifecycle, including incident, complaint, remediation and forensic costs. Under the composite assumptions, reconstruction becomes cheaper once the case ages because context remains bounded while accumulated history continues to grow. That is a scenario result, not a universal cost claim; the break-even point must be calculated from local volumes, model prices, source latency and incident exposure.