---
title: 'Working memory'
description: 'The bounded task state actively delivered to an agent during a run, including current goals, constraints, observations, and pending work.'
canonical_url: 'https://darkfactory.dev/glossary/working-memory'
markdown_url: 'https://darkfactory.dev/glossary/working-memory.md'
collection: glossary
date_published: '2026-08-03T00:00:00-04:00'
date_modified: '2026-08-26T00:00:00-04:00'
---

# Working memory


## Definition

Working memory is the bounded task state actively delivered to an agent during a run. It may include the current goal, standing constraints, recent observations, pending actions, unresolved failures, and pointers to authoritative artifacts. The useful unit is what the agent can act on now, not everything the session has ever recorded.

A conversation transcript is one possible input, but long transcripts mix current state with obsolete plans, repeated tool output, and abandoned attempts. Harnesses therefore select, summarize, or reconstruct a working set. Files, execution traces, task ledgers, and retrieved records can supply state even when they live outside the model's context window.

Working memory is partly a delivery property. A fact in storage does not help if the harness never places it in context when its trigger appears. Swapnanil Saha's 2026 cue-anchored working-memory study argues for deterministic, harness-side delivery and reports a small controlled coding experiment in which voluntary memory lookup was unused while injected records survived repeated compaction. The study is a single harness and workload, so its mechanism needs broader replication.

Compaction can silently change the working set. The COMPINT study by Zhiqi Wang and colleagues found that current compactors often dropped standing session constraints. Systems should test goal, constraint, provenance, and unresolved-failure retention after compaction instead of assuming a readable summary is complete.

Working state also needs authority labels. A verified deployment rule, an agent-authored hypothesis, and an untrusted retrieved passage should not enter context with the same status. Stale state must be corrected or evicted when the underlying artifact changes.

## Distinguish it from nearby terms

Working memory supports the current episode. Durable memory persists across runs. A context window is model capacity, while working memory is the selected state placed within that capacity. An execution trace records what happened but becomes working memory only when the system retrieves the relevant parts.

## Check your understanding

After compaction, an agent remembers the feature goal but forgets that one test is still failing and that deployment needs approval. Which items belonged in the reconstructed working set, and which should have come from authoritative durable records?

## Also called

short-term memory

## Related terms

- [Durable memory](https://darkfactory.dev/glossary/durable-memory)
- [Prompt compression](https://darkfactory.dev/glossary/prompt-compression)
- [Context window](https://darkfactory.dev/glossary/context-window)
- [Context engineering](https://darkfactory.dev/glossary/context-engineering)

## Related factory areas

- [Context, memory, knowledge & skills](https://darkfactory.dev/factory/context-memory-skills)
- [Orchestration, state, concurrency & recovery](https://darkfactory.dev/factory/orchestration-state)

## Evidence and further reading

- [Long-Running Agents](https://addyosmani.com/blog/long-running-agents/)
- [Shepherd: A Runtime Substrate Empowering Meta-Agents with a Formalized Execution Trace](https://arxiv.org/abs/2605.10913)
- [Delivery, Not Storage: Cue-Anchored Working Memory as a Harness Property for Coding Agents](https://arxiv.org/abs/2607.20972)
- [Lost in Compaction: Evaluating Side-Constraint Loss under Context Compaction](https://arxiv.org/abs/2608.11242)