A coding agent encountering a repository for the first time may not know its test command, team conventions, or deployment process. Even if it completes the task, a later session may repeat the same mistakes. A stronger model does not automatically acquire that organization-specific knowledge.

At AI Native DevCon 2026, Lamis Mukta of Anthropic’s Applied AI team discussed how context engineering and memory management can address this gap. This article adapts an automatic transcript of her talk and uses Anthropic’s documentation to clarify the product’s current status. The benefits she describes are observations without quantitative comparisons. Improvement here means changing external context and memory, not updating model weights.

From instruction files to searchable memory

Context engineering includes selecting, supplying, and maintaining information a model needs for a task. Mukta describes an evolution from simple Markdown instructions toward memory agents can retrieve and maintain:

1. Instruction files such as CLAUDE.md describe repository entry points, rules, or preferences. They are readable and editable, but loading an ever-growing file into every session consumes context.
2. In-session memory lets an agent read, write, or update information while working. Later tasks can use it, but maintaining it consumes resources during the current task.
3. Skills package workflows with defined steps. An agent sees a short description first and loads details when relevant, rather than carrying every workflow in every session.
4. Filesystem memory organizes Markdown files with indexes and search, so an agent can find and update information on demand. A filesystem is an interaction and organization pattern; production storage can use other underlying infrastructure.

These mechanisms can coexist. Keep a universal testing requirement in a short instruction file, put a release procedure in an on-demand skill, and store project-specific past problems in searchable memory. The goal is to make information available when needed without loading all of it every time.

What production memory requires

Readable, writable files are a starting point, not a complete shared-memory system. An incorrect change can affect other agents, while concurrent writes can overwrite one another. Mukta identifies four areas to address:

• Versions and provenance: retain change history, the author, related sessions, and supporting context so changes can be reviewed and rolled back.
• Concurrency: an agent reads a memory and its hash before preparing a change. If the version has changed at submission, it must reread and resolve the conflict. In an implementation, comparing the version and writing must be atomic to avoid a race between those operations.
• Access control: organization-wide instructions may be read-only to ordinary agents, team memory can have scoped permissions, and individual scratchpads can allow broader writes. Contain the spread of incorrect memories and malicious content as well.
• Portability: expose memory through clear interfaces so knowledge maintained by an organization is not tied to one product interface.

Mukta has observed that memory can help agents spend less time retracing their steps on similar tasks, potentially making tasks easier to complete and saving time or money. She does not provide controlled measurements, task coverage, or cost data in the talk, so those benefits need to be evaluated in each setting.

Why review memory outside a session?

In-session memory is close to the work and can capture a discovery immediately. But an agent usually sees only its own session and must also complete the user’s request. It may miss a failure repeated across many sessions or lack the resources to check whether old memories are still accurate.

Mukta calls an asynchronous, out-of-session memory review Dreaming. The process examines selected session transcripts, tool activity, and existing memory for recurring problems, missing knowledge, contradictions, or stale entries. In the workflow described in the talk, it proposes changes with evidence that a user can accept or reject.

Suppose several agents run the wrong test command in the same project. A single session may fix its immediate failure; a cross-session review can identify the pattern and recommend recording the correct command, with relevant sessions as evidence. Likewise, repeated departures from a team’s writing preference may justify a proposed update to guidance at the appropriate scope.

The two approaches complement each other, and neither guarantees a correct memory. Whether extra token costs are offset by savings on later tasks must be measured in the actual system.

Anthropic’s implementation and access boundaries

As checked on November 10, 2026, Anthropic’s Dreams documentation labels the feature a research preview and asks users to request access. Its documented job reads an existing memory store and 1 to 100 sessions, then asynchronously produces a separate output store. The input store is unchanged, allowing users to review or discard the result. This specific product behavior should be distinguished from the general design described in the talk; consult the documentation and account permissions for availability.

Selecting input sessions does not by itself solve enterprise authorization. Filter transcripts to match the user, team, and memory-store scope, and ensure the review process and its output do not expand access. The talk does not specify the implementation of permission inheritance or cross-tenant isolation.

Our OpenClaw Dreaming article covers a different background memory-consolidation mechanism. The shared name does not imply that the implementations or their operating boundaries are interchangeable.

A practical sequence

The talk suggests an incremental approach:

1. Identify rules that need repeated explanation or recurring failures. Record a concise, maintainable instruction and observe real task outcomes.
2. Move task-specific procedures into on-demand skills; make larger knowledge collections searchable.
3. Define which memories agents may update and which require human review; retain the evidence for changes.
4. As agents share memory or run over long periods, add versioning, atomic concurrency control, and access isolation.
5. If cross-session repetition remains a problem, review permission-matched transcripts asynchronously. Evaluate proposed changes, task quality, and added cost.

Agents can help decide which experiences are worth retaining. Permissions, versions, and consistency still need deterministic engineering controls.

Sources:

• Learning while you sleep: Beyond memory to dreaming (AI Native Dev, June 2026)
• Dreams (Anthropic, publication date not stated; accessed November 10, 2026)