Open architecture specification for provenance-aware AI systems and institutional memory.
Active Working Memory is the assembled execution state that supports a single task. It sits between durable state and the model’s context window, gathering hydrated records, current instructions, tool responses, session state, planner output, unresolved questions, and the provenance and qualification needed to interpret them.
If the context window is the CPU cache of an AI system and durable storage is its filesystem, Active Working Memory is the RAM: temporary, task-scoped, and assembled deliberately rather than persisted as long-term state.
Within Sovereign Systems, Active Working Memory is treated as an explicit architectural layer, not as incidental prompt construction.
The governing principle is:
What belongs in working memory is determined by whether it contributes to the task, not by whether it fits.
The term Active Working Memory was first formalized as part of the Sovereign Systems Specification by Ken W. Alger in 2026.
The context window does not begin the reasoning process. It receives the result of earlier architectural decisions.
By the time a model sees its first token, the surrounding system has already determined which sources were discovered, which records were eligible to participate, which evidence was preserved, which tool calls completed, which state was restored, which contradictions remained unresolved, and which material was excluded.
The resulting task-scoped state is Active Working Memory.
Its quality sets a ceiling on the quality of the inference that follows.
Two systems can share the same model, the same context-window size, and the same underlying Durable Memory while producing very different results. The model is identical. The working state presented to it is not.
This reframes a broad class of failures.
When a superseded record enters current context, a governing constraint is omitted, contradictory evidence is flattened into one answer, provenance disappears during summarization, or the window is flooded with loosely related prose, the model is often blamed for the result.
Those are frequently memory-architecture failures that occurred before inference began.
flowchart LR
D["Durable Memory"] --> H["Context Hydration"]
T["Tool Results"] --> A["Active Working Memory"]
S["Session State"] --> A
P["Planner / Runtime State"] --> A
I["Current Instructions"] --> A
H --> A
A --> C["Model Context Window"]
C --> M["Inference"]
classDef capture fill:#378ADD,stroke:#378ADD,color:#FFFFFF
classDef governance fill:#1D9E75,stroke:#1D9E75,color:#FFFFFF
classDef memory fill:#BA7517,stroke:#BA7517,color:#FFFFFF
classDef boundary fill:#6B7280,stroke:#6B7280,color:#FFFFFF
classDef failure fill:#C0392B,stroke:#C0392B,color:#FFFFFF
class T,S,P,I capture
class D,A memory
class H governance
class C,M boundary
Active Working Memory is not another persistence layer.
It is a bounded, ephemeral representation of what the current execution needs.
Its contents may originate from persistent systems, but the assembled working set exists for the task.
When the task ends, the working set may disappear.
That does not mean every event surrounding the task disappears. Consequential decisions, tool activity, or outcomes may independently produce durable evidence in the Reasoning Ledger, Forensic Receipts, or application state.
The distinction is architectural:
Durable Memory
persists across tasks
Active Working Memory
exists for this task
Context Window
is the model-visible representation used during inference
Working memory may be larger or richer than the exact prompt sent to a model. It can include structured state that an orchestrator uses to decide what should enter the next inference call.
Context Assembly is the process that constructs Active Working Memory from task-relevant inputs.
Context Hydration governs the read-side transition by which durable state is discovered, evaluated, resolved, and reconstructed for present use. Context Assembly combines the result of that process with ephemeral task state such as tool responses, instructions, planner state, and current interaction state.
This distinction matters.
Context Assembly should not casually manufacture authority because a retrieved record ranked highly.
Authority, provenance, lifecycle state, and eligibility should already have been evaluated to the extent required by the task and governing policy.
Assembly then decides how eligible and appropriately qualified information should be represented in the working set.
flowchart LR
Q["Task Intent"] --> H["Context Hydration"]
D["Durable Memory"] --> H
H --> A["Context Assembly"]
T["Tool Results"] --> A
S["Session State"] --> A
P["Planner State"] --> A
I["Instructions / Constraints"] --> A
A --> W["Active Working Memory"]
classDef capture fill:#378ADD,stroke:#378ADD,color:#FFFFFF
classDef governance fill:#1D9E75,stroke:#1D9E75,color:#FFFFFF
classDef memory fill:#BA7517,stroke:#BA7517,color:#FFFFFF
classDef boundary fill:#6B7280,stroke:#6B7280,color:#FFFFFF
classDef failure fill:#C0392B,stroke:#C0392B,color:#FFFFFF
class Q,T,S,P,I capture
class D,W memory
class H governance
class A boundary
Search finds candidates.
Hydration determines what durable state is eligible and useful to return.
Context Assembly builds the task state.
Active Working Memory is the result.
Working memory should hold enough to perform the current task well, and no more.
A task-appropriate working set may include:
What belongs there is not decided by whether something fits.
It is decided by whether it contributes to the task and whether the system is entitled to use it in the way the task requires.
Active Working Memory does not need to contain only resolved facts.
A system that requires every working-memory element to collapse into a single asserted truth before inference can erase exactly the uncertainty the model needs to reason correctly.
Working memory may legitimately contain:
deployment_region:
status: disputed
claims:
- value: "us-west-2"
source: "inventory-service"
- value: "us-east-1"
source: "runtime-observation"
It may also contain:
authority_resolution:
status: undetermined
reason: "governing source unavailable"
or:
source_state:
status: unverifiable
historical_value: "approval-required"
These are not malformed working states.
They are faithful representations of what the system can currently establish.
Working memory should preserve uncertainty when certainty has not been earned.
Provenance that mattered during adjudication may still matter during inference.
Suppose hydration produces two statements:
Production policy v7 requires the automated risk gate.
Historical policy v6 required human approval.
If the context window receives only:
Human approval is required.
The automated risk gate is required.
the system has destroyed the distinction that made the information usable.
Active Working Memory should therefore preserve consequential qualification alongside the evidence it qualifies.
That may include:
Not every token of provenance must be sent verbatim to the model.
The requirement is that compression or transformation must not erase semantics necessary for correct reasoning.
flowchart LR
E["Evidence"] --> W["Active Working Memory"]
P["Provenance"] --> W
L["Lifecycle State"] --> W
A["Authority Qualification"] --> W
U["Uncertainty / Contradiction"] --> W
W --> C["Model-Visible Context"]
classDef capture fill:#378ADD,stroke:#378ADD,color:#FFFFFF
classDef governance fill:#1D9E75,stroke:#1D9E75,color:#FFFFFF
classDef memory fill:#BA7517,stroke:#BA7517,color:#FFFFFF
classDef boundary fill:#6B7280,stroke:#6B7280,color:#FFFFFF
classDef failure fill:#C0392B,stroke:#C0392B,color:#FFFFFF
class E capture
class P,A governance
class L,W memory
class U,C boundary
Provenance normally describes the ancestry and evidence surrounding information.
Active Working Memory introduces an additional question:
Why is this information in the working set?
For consequential tasks, the system may need to preserve enough context provenance to answer questions such as:
Context provenance does not require logging every ranking score or every discarded chunk.
It means that consequential context-selection decisions remain observable enough to investigate later.
This is especially important because the model can reason only over the context it receives.
What the model did not receive can matter as much as what it did.
Consider an agent asked to update one section of a technical specification.
- every specification section
- the full glossary and its revision history
- complete Git history
- all prior conversations retained under policy
- every open and closed issue
- current and historical Architecture Decision Records
- retry-policy section v4
state: current
authority: specification
- retry-policy section v3
state: superseded
historical relevance: high
- ADR-0017
state: current
relationship: governs retry behavior
- ADR-0009
state: superseded
- glossary definitions referenced by v4
- open issue #241
status: unresolved
claim: v4 may conflict with current runtime behavior
TASK
Update the retry-policy section without changing its governing semantics.
CURRENT GOVERNING STATE
- retry-policy v4
- ADR-0017
- current glossary definitions
OPEN CONTRADICTION
- issue #241 reports that deployed runtime behavior may differ from v4
- runtime state has not yet been independently verified
HISTORICAL CONTEXT
- v3 and ADR-0009 are superseded and should not govern the edit
CURRENT TOOL STATE
- repository branch: docs/retry-policy
- working tree: clean
The working set does not contain everything that was retrieved.
It contains what the task needs, with enough qualification to prevent historical or unresolved information from silently masquerading as current governing state.
Every unnecessary artifact in the working set increases Context Tax.
Verbose tool responses consume attention.
Duplicate facts compete with more important evidence.
Historical state can distract from current state when its role is not explicit.
Large provenance payloads can consume tokens without improving the decision.
Disciplined assembly is therefore a compression problem as well as a governance problem.
The objective is not maximum context.
It is maximum useful signal under a bounded reasoning budget.
flowchart LR
C["Candidate Context"] --> S["Sieve / Assembly"]
S --> H["High-Signal Context"]
S --> X["Excluded / Deferred"]
H --> W["Active Working Memory"]
classDef capture fill:#378ADD,stroke:#378ADD,color:#FFFFFF
classDef governance fill:#1D9E75,stroke:#1D9E75,color:#FFFFFF
classDef memory fill:#BA7517,stroke:#BA7517,color:#FFFFFF
classDef boundary fill:#6B7280,stroke:#6B7280,color:#FFFFFF
classDef failure fill:#C0392B,stroke:#C0392B,color:#FFFFFF
class C,H capture
class S governance
class X boundary
class W memory
The cheapest context is context the task never needed.
Durable Memory preserves governed long-term state.
Context Hydration determines which durable state is eligible and useful to return for the present task.
Active Working Memory is the task-scoped state that results after hydrated durable state is combined with ephemeral execution state.
Durable Memory
↓
Context Hydration
↓
Context Assembly
↓
Active Working Memory
↓
Model-Visible Context
Durable Memory may preserve current, historical, superseded, corrected, disputed, stale, invalidated, or unverifiable state.
Hydration determines how that state may participate now.
Active Working Memory preserves the resulting task-relevant distinctions long enough for the current execution to use them.
Working memory is therefore the destination of hydration, not a durable store in its own right.
The Reasoning Ledger preserves observable evidence surrounding consequential decisions and system activity.
Active Working Memory is ephemeral.
The ledger is historical.
A consequential ledger event may record evidence about the working state used for a decision without attempting to preserve every token of the prompt or any private model chain-of-thought.
Depending on policy and consequence, it may preserve:
Working memory supports the decision. The ledger preserves evidence about the decision.
A Forensic Receipt may bind defined evidence to a consequential context artifact, tool event, or resulting action.
A receipt can provide integrity evidence for a representation of working state.
It does not prove that:
Those claims require broader provenance, governance, and audit semantics.
Context Hydration is a governed transition.
Active Working Memory is a state.
This distinction prevents the two concepts from collapsing into one another.
Hydration asks:
What durable state should return, and with what qualification?
Active Working Memory asks:
What does this task currently have available to reason and act with?
Hydration can fail, defer, qualify, or return undetermined.
Those results may themselves become part of Active Working Memory when they matter to the task.
Active Working Memory and the context window are not necessarily identical.
An orchestrator may maintain working state in structured memory while exposing only selected portions to a model during each inference call.
For example:
Active Working Memory
├── task plan
├── current constraints
├── hydrated evidence
├── tool state
├── unresolved questions
└── execution metadata
↓
Model-visible projection
├── current step
├── relevant evidence
├── necessary constraints
└── required uncertainty
This allows a system to preserve task state without repeatedly injecting every detail into every model call.
The context window is therefore one consumer or projection of Active Working Memory.
It is not the architectural definition of working memory itself.
In classical operating systems, thrashing occurs when a system spends more time swapping pages between RAM and virtual memory than executing useful process cycles.
In agentic architectures, Agentic Thrashing occurs when the system repeatedly loads, evicts, rehydrates, or reconciles working state without making useful progress.
This can happen when:
flowchart LR
R["Retrieve"] --> W["Working Memory"]
W --> C["Conflict / Noise"]
C --> R
C --> T["Thrashing"]
A["Adjudication / Eviction"] --> W
A --> P["Forward Progress"]
classDef capture fill:#378ADD,stroke:#378ADD,color:#FFFFFF
classDef governance fill:#1D9E75,stroke:#1D9E75,color:#FFFFFF
classDef memory fill:#BA7517,stroke:#BA7517,color:#FFFFFF
classDef boundary fill:#6B7280,stroke:#6B7280,color:#FFFFFF
classDef failure fill:#C0392B,stroke:#C0392B,color:#FFFFFF
class R capture
class W memory
class C boundary
class T failure
class A governance
class P memory
Active Working Memory reduces agentic thrashing by making context sieving, lifecycle qualification, working-set eviction, unresolved-state preservation, and task-state management explicit orchestration responsibilities.
The goal is not to eliminate contradiction.
Some contradictions are real.
The goal is to prevent the system from repeatedly rediscovering or accidentally manufacturing contradictions because its working state is poorly governed.
Active Working Memory is intentionally temporary.
Information should leave the working set when:
Eviction from Active Working Memory is not deletion from Durable Memory.
Likewise, a durable correction or supersession does not automatically rewrite an already-running task’s working state unless the architecture rehydrates or updates that state.
Long-running tasks therefore need explicit policies for:
A working set assembled correctly at T1 can become stale at T2.
Sovereign Systems treat Active Working Memory as a first-class execution layer by:
undetermined state to remain explicitThe objective is not to gather everything that might be relevant.
The objective is to assemble the smallest task state that preserves the evidence, constraints, uncertainty, and governing semantics required to reason correctly.
A useful heuristic remains:
What belongs in working memory is determined by whether it contributes to the task, not by whether it fits.
A computer does not load its entire storage device into memory to open a text editor.
An agentic system should not hydrate its entire knowledge store into a prompt for the same reason.
Capacity is not relevance.
And relevance, by itself, is not authority.