Sovereign Systems Specification

Open architecture specification for provenance-aware AI systems and institutional memory.

View the Project on GitHub kenwalger/sovereign-system-spec

Active Working Memory

Phase 3 - Memory

Definition

Active Working Memory is the assembled execution state that supports a single task. It sits between durable storage and the context window, gathering retrieved records, tool responses, session state, and planner output into the working set a model will reason over.

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.

Within Sovereign Systems, Active Working Memory is treated as an explicit architectural layer, not as incidental prompt construction.

Origin

The term Active Working Memory was first formalized as part of the Sovereign Systems Specification by Ken W. Alger in 2026.

Why It Matters

The context window does not begin the reasoning process. It receives the result of it.

By the time a model sees its first token, something has already decided what belongs in front of it and what does not. Documents were retrieved, tool calls completed, session state restored, and sources selected, normalized, or discarded. That assembled state is Active Working Memory, and its quality sets a ceiling on the quality of the inference that follows.

This reframes a whole class of failures. When the wrong record is retrieved, a stale version is preferred over a current one, a constraint never makes it into the prompt, or the window is flooded with loosely related prose, the model is usually blamed. These are not context-window-size problems. They are Active Working Memory problems.

Two systems can share the same model, the same window size, and the same underlying documents, and still produce very different results. The model is identical. The memory architecture is not.

Context Assembly

Context Assembly is the process that populates Active Working Memory, and it is where retrieval stops being a search problem and becomes an orchestration problem.

Search finds information. Working memory assembles it.

When information is selected for the current task, it crosses an architectural boundary. At that boundary the system makes decisions about relevance, authority, recency, format, and priority. It may compress one source, preserve another verbatim, reject a third, and annotate a fourth with provenance. Those decisions shape what the model is capable of knowing during inference, and they are the difference between useful context and expensive noise.

What Belongs in Working Memory

Working memory should hold enough to perform the current task well, and no more. It is assembled deliberately and allowed to expire when the task completes.

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.

Example

Consider an agent asked to update one section of a technical specification.

The durable store (everything retained)

- every specification section
- the full glossary and its revision history
- complete Git history
- all prior conversations
- every open and closed issue

The working set (assembled for this task only)

- the retry-policy section, current authoritative version
- 2 related Architecture Decision Records
- glossary entries for the terms in that section
- the last 3 commits touching that area
- 1 open issue referencing the policy
- tool response: current configuration values

The durable store holds everything that might matter. The working set holds only what matters now, assembled for one task and discarded when it is done.

Relationship to Context Tax

Every unnecessary document in the working set increases Context Tax. Verbose tool responses consume attention, duplicate facts compete with more important evidence, and loosely relevant material lowers signal density inside the window.

Disciplined assembly is the cheapest place to control that cost, because the context window can only reason over what Active Working Memory hands it.

Relationship to Durable Memory and Context Hydration

Durable Memory preserves what may matter later. Active Working Memory decides what matters now. Context Hydration is the mechanism that moves state from the first into the second, expanding stored, verified records into the working set on demand.

Working memory is the destination of a hydration, not a store in its own right. When the task ends, it is meant to disappear.

The Sovereign Approach

Sovereign Systems treat Active Working Memory as a first-class layer by:

The objective is not to gather everything that might be relevant. The objective is to assemble exactly what the task needs, and nothing that merely fits.

Key Principle

A useful heuristic is:

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.

References