State and Memory

An agent that works across several steps needs continuity. It must know what the task is, which actions already took effect, what remains unresolved, and which information may be useful later. Calling all of this “memory” obscures different correctness and governance requirements.

Thesis

State records what the system currently accepts as true; memory stores information that may be useful again. Retrieved memory is a candidate input, not authoritative state.

The architecture should make truth ownership, update rules, scope, validity, provenance, retention, and deletion explicit. The model may propose an update, but application code decides whether it becomes state or memory.

Separate the records

Record	Purpose	Typical example
Authoritative state	Current accepted facts needed for correct execution	Order status, approved action, active goal, remaining budget
Event record	Append-only account of material attempts and changes	Action requested, approval granted, write confirmed
Checkpoint	Resume point for a bounded run	Current phase, pending effects, state versions, limits
Derived view	Recomputable projection for a particular consumer	Dashboard status or model-ready task summary
Memory candidate	Information proposed for possible future reuse	Preference, reusable finding, prior task outcome
Artifact	A durable work product referenced by state	Report, plan, code patch, evidence bundle

One storage system may hold several of these, but their semantics should remain distinct. A conversation transcript is usually an event-like interaction record; it is not automatically the current task state. A summary is a derived view; it should not silently erase the facts from which it was produced.

Authoritative state needs an owner and schema

For each material field, define:

• which system is the source of truth;
• who or what may propose and commit changes;
• valid values and legal transitions;
• version, observation time, and freshness expectations;
• conflict and concurrency behavior;
• audit and retention requirements; and
• how a model receives a bounded projection.

Use domain identifiers and typed fields when correctness depends on exact values. Prose can explain the state but should not be the only representation of an amount, permission, recipient, test result, or committed effect.

The control loop should update state from verified action outcomes. If a write times out, record outcome_unknown and reconcile with the system of record. Do not let the model choose between “probably succeeded” and “retry” from an ambiguous text message.

Concurrency and versioning

Long-running and multi-actor tasks make stale writes likely. A human may correct a value while an agent is paused; two workers may complete against the same version; a retry may arrive after cancellation.

Common controls include:

• optimistic version checks or compare-and-set;
• idempotency keys for effect requests;
• leases for bounded ownership, with expiry and fencing where needed;
• append-only events plus deterministic projections;
• explicit merge or conflict states; and
• read-back before a consequential commit.

The correct mechanism depends on the data store and consequence. The architectural requirement is that conflict is represented and resolved by policy rather than hidden in “last writer wins” prose.

Memory is a lifecycle, not a vector database

Memory requires decisions at both write and read time:

observe information
      ↓
propose a memory candidate
      ↓
validate source, scope, consent, sensitivity, and usefulness
      ↓
store with provenance, validity, retention, and owner
      ↓
retrieve for a named future decision
      ↓
recheck permission, relevance, freshness, and conflicts
      ↓
include as attributed context or update authoritative state through its normal path

Embedding and similarity search can implement part of retrieval. They do not define what should be remembered, whether it is still true, who may see it, or how a person corrects it.

MemGPT explored a tiered memory design that moves information between limited model context and external storage (Packer et al., 2023). Generative Agents combined an observation stream with retrieval, reflection, and planning in a simulated environment (Park et al., 2023). These systems are useful research examples of external memory management. They do not establish one universal production taxonomy or correctness guarantee.

Classify memory by use, scope, and validity

Labels such as episodic, semantic, and procedural memory can help compare research, but implementation decisions need operational fields:

Dimension	Questions
Intended use	Is this for resuming a task, personalizing an interaction, reusing a finding, or improving a process?
Subject and owner	Does it concern a user, team, tenant, system, or public domain? Who controls it?
Scope	Which tasks, products, identities, and models may use it?
Source	Was it stated by a person, observed from a system, generated by a model, or inferred?
Validity	Is it a durable preference, a time-bounded fact, or an uncertain hypothesis?
Sensitivity	Does it contain personal, confidential, regulated, or security-relevant information?
Retention	When does it expire, and what legal or product rule governs deletion?
Supersession	How is a correction linked to and preferred over an older item?

A skill is maintained procedural guidance with an owner and version, not merely a memory extracted from one run. Durable domain knowledge should normally live in a governed knowledge source rather than accumulate as unreviewed agent memories.

Write policy: remember selectively

“Remember everything” creates cost, privacy exposure, contradictions, and retrieval noise. Store only when a future use is named and the benefit justifies governance.

Useful write gates ask:

• Is the information permitted and necessary to retain?
• Is the source entitled to assert it?
• Is it an observation, user statement, inference, or model-generated hypothesis?
• Could the same need be served by authoritative state or a referenced artifact?
• What scope, expiry, confidence, and correction path apply?
• Would remembering it surprise the person concerned?

Inference deserves special care. “User asked for a short answer” is an event; “user always prefers terse communication” is a generalization that may be wrong. Preserve the distinction.

Read policy: retrieval does not establish truth

At retrieval time, filter by principal, tenant, purpose, consent, sensitivity, and time before similarity. Then rank by task relevance, source authority, freshness, and confidence. Return provenance and validity metadata with the content.

When a memory conflicts with current user input or authoritative state, current authorized evidence normally wins. Some conflicts should trigger clarification instead of an automatic precedence rule. The context pipeline should identify retrieved memory as memory, not merge it invisibly into governing instructions.

Privacy and user control

Memory makes data persistent across interactions, so users and operators need meaningful control. Product & UX will own presentation, but architecture must support:

• visibility into material stored memories;
• correction, deletion, and forgetting;
• per-scope or global enablement where appropriate;
• retention and expiry enforcement;
• tenant and identity isolation;
• deletion propagation to indexes, caches, and derived views; and
• records of why a memory was used in a decision.

NIST AI 600-1 recommends documenting provenance and data flows and considering privacy risks across the GAI lifecycle (NIST, 2024). Local legal and policy requirements determine the precise controls.

Failure modes

Transcript as database

Current facts are reconstructed from a conversation containing revisions and guesses. Store authoritative state separately and project it into context.

Remember everything

Retention expands without a future purpose, increasing privacy risk and retrieval noise. Apply a write policy and default expiry.

Generated summary becomes truth

A lossy interpretation overwrites source records. Keep it as a derived view with provenance and regeneration rules.

Similarity overrides scope

A semantically close memory crosses users, tenants, purposes, or time boundaries. Filter authorization and scope before ranking.

Inference stored as fact

A model’s guess becomes a stable profile. Mark inference, confidence, source, and expiry; require confirmation when consequences warrant it.

Silent last-writer-wins

Concurrent agents or people overwrite newer state. Use versions and explicit conflict handling.

Deletion only from the primary table

Embeddings, caches, summaries, and backups continue to surface deleted content. Define deletion propagation and documented limits.

Fieldbook guidance

Create two separate contracts:

State contract
- source of truth, schema, legal transitions, versioning
- writers, validators, concurrency and reconciliation
- checkpoint and resume fields
- model-visible projection and freshness

Memory contract
- named future use, subject, owner, scope, and source
- write gate, sensitivity, consent, validity, expiry
- retrieval filters and ranking
- conflict, correction, supersession, deletion, and audit

Checklist

• Are authoritative state, event history, checkpoints, derived views, memory, and artifacts distinguished?
• Does every material state field have a source of truth and controlled update path?
• Are stale writes, retries, and concurrent actors handled through versions or explicit conflicts?
• Does memory have a named future use and a write policy?
• Are source, scope, validity, sensitivity, retention, and owner stored with memory?
• Are authorization and tenant filters applied before memory ranking?
• Is retrieved memory attributed and revalidated before use?
• Can current evidence correct or supersede old memory?
• Can people inspect, correct, and delete material memories where required?
• Do deletion and expiry reach indexes, caches, and derived views?

References and how they are used

• Packer et al., “MemGPT: Towards LLMs as Operating Systems” — research example of managing limited model context with external tiers; used to illustrate memory movement, not as a universal production architecture.
• Park et al., “Generative Agents: Interactive Simulacra of Human Behavior” — peer-reviewed research example combining stored observations, retrieval, reflection, and planning in a simulation.
• NIST AI 600-1, Generative Artificial Intelligence Profile — cross-sector risk-management profile supporting provenance, privacy, data governance, and lifecycle evaluation.
• Microsoft, “Guidelines for Human-AI Interaction” — peer-reviewed human-AI interaction paper supporting recent-interaction continuity, cautious adaptation, granular feedback, global controls, and notifying users of behavior changes.