Claude Memory: Decrypting the Effectiveness Behind Long-Running Model Capabilities

Claude Memory: Decrypting the Effectiveness Behind Long-Running Model Capabilities

Based on Lamis Mukta’s session at AI Native DevCon (June 2026). Lamis is a Member of Technical Staff at Anthropic, working on the Applied AI team, where she partners with frontier customers building production AI agents.

[embed]Lamis Mukta’s AI Native DevCon session

Introduction

Over the past year, Anthropic has released one breakthrough after another. Opus 5 pushed the boundaries of coding, Fable introduced long-running agents capable of sustained work, and Claude Tag demonstrated how agents could continuously improve developer workflows.

Most discussions around these releases focused on the models themselves. Were they reasoning better? Did they have larger context windows? How much smarter had they become?

Lamis Mukta’s session at AI Native DevCon approached the conversation from a very different angle.

Instead of asking how models became smarter, she explored how intelligent models become effective products. That’s an important distinction. Frontier models already possess remarkable reasoning capabilities, but raw intelligence alone isn’t enough to build reliable systems that operate over days, weeks or months. Every organization has its own codebase, conventions, preferences and workflows. None of those exist in the model’s pre-training. If an agent is expected to work productively inside your environment, it needs a way to acquire that knowledge, retain it and improve from experience.

Anthropic calls this discipline context engineering. Over the past year, that discipline has quietly evolved into something much larger: memory engineering.

The evolution is surprisingly simple.

CLAUDE.md  →  Memory Tool  →  Skills  →  memory/

What looks like four independent features is actually a progression of ideas. Each stage solves a limitation of the previous one, gradually transforming memory from a static configuration file into a continuously evolving knowledge system.

The final result isn’t merely persistent storage.

It’s an architecture that allows AI agents to learn from experience, collaborate through shared knowledge, and become more effective the longer they operate.

The Evolution

One of the recurring themes throughout Lamis’ talk was a principle Anthropic often follows internally:

Do the simple thing that works.

The journey of memory perfectly reflects that philosophy. Rather than designing an elaborate memory platform from day one, Anthropic kept solving the next obvious bottleneck. Every iteration preserved what worked while removing what didn’t. Looking back, the progression feels almost inevitable.

CLAUDE.md — Giving the Model a Starting Point

The story begins with **CLAUDE.md**.

On paper, the idea couldn’t have been simpler. Place a markdown file in your project containing coding conventions, architectural notes, project structure and user preferences. Every time Claude starts a session, inject that file into the beginning of its context.

There was nothing particularly sophisticated about it.

Yet, as Lamis described, it turned out to be “unreasonably effective.”

Developers suddenly had a straightforward way to teach Claude about their projects without repeatedly writing the same prompts. Instead of explaining where important modules lived, how pull requests should be structured or which testing framework the team preferred, those instructions became part of the project’s permanent context.

The simplicity was precisely its strength. Markdown is readable, editable and familiar to every developer. Both humans and AI agents could understand it without introducing new tooling or abstractions.

However, success introduced its own problem.

As projects matured, so did CLAUDE.md. Teams kept adding more instructions, more conventions and more organizational knowledge until the file itself started becoming another source of context bloat. Every session paid the cost of loading information that might not even be relevant to the current task.

The first bottleneck wasn’t intelligence.

It was context.

Memory Tool — Teaching Agents to Remember

The next evolution wasn’t about storing more information.

It was about changing who decides what should be remembered.

Rather than treating memory as a document maintained entirely by developers, Anthropic experimented with allowing the agent itself to manage memory. During an active session, the agent could decide when to read from memory, when to write new observations and when existing memories should be updated. Everything happened in-band — within the context of the current task.

This represented an important philosophical shift.

Previously, memory had been something humans curated for the model.

Now, memory became something the model actively participated in building.

Imagine an agent debugging a deployment failure. Instead of simply fixing the issue and moving on, it could record the root cause, document the successful resolution and preserve that knowledge for future executions. The next time a similar problem appeared, it wouldn’t have to rediscover the solution from scratch.

Lamis highlighted a key lesson from this phase: autonomy works. Agents were surprisingly capable of deciding what information deserved to become memory.

Yet another limitation quickly emerged.

Even though the agent could now maintain memory, it still operated within the boundaries of a single session. Memory continued to compete with the primary task for attention and context. The more an agent spent thinking about memory, the less capacity it had to solve the problem it had actually been asked to solve.

Skills — Loading Knowledge Only When It Matters

The next bottleneck wasn’t memory itself.

It was scale.

As knowledge accumulated, developers faced the same challenge that had plagued CLAUDE.md: how do you provide rich context without overwhelming the model?

Anthropic’s answer was Skills.

Rather than loading detailed instructions upfront, Skills introduced a technique Lamis described as progressive disclosure. Each skill begins with a small piece of front matter — a concise description of what it does. The agent first scans only these summaries. If it determines that a particular skill is relevant to the task at hand, it then loads the complete document containing all the detailed instructions.

Lamis used a simple analogy that perfectly captures the idea.

Imagine standing in front of a bookshelf.

You don’t memorise every book before beginning a conversation. Instead, you glance at the titles, identify the one that seems relevant and only then open it to read the details.

Skills apply exactly the same principle to AI context.

This seemingly small design change solves a surprisingly large problem. Rich documentation no longer has to compete for valuable context window space because the agent loads it only when necessary.

At the same time, Skills remain opinionated. Humans still decide which workflows deserve to become reusable skills. That works well for structured processes, but it doesn’t fully answer a broader question:

What if agents could organize knowledge without humans deciding in advance how that knowledge should be structured?

memory/ — When Memory Becomes Infrastructure

That question led to what Anthropic now considers the state of the art.

Instead of introducing increasingly sophisticated memory APIs, they moved in the opposite direction.

Memory became… a filesystem.

Not a vector database.

Not a proprietary storage engine.

Just directories filled with markdown files.

At first glance, this almost feels underwhelming.

But the elegance lies precisely in its familiarity.

AI agents are already remarkably good at navigating filesystems. They understand directories, search naturally using tools like grep, inspect files with standard shell commands and retrieve information on demand. Rather than inventing specialized tools for memory retrieval, Anthropic simply allows agents to use the filesystem in exactly the same way developers already do.

This approach also preserves everything that made the earlier stages successful. Markdown remains human-readable. Memories can continue to grow without overwhelming the context window because agents search and load only what they need. The indexing and progressive loading concepts introduced through Skills naturally extend to the filesystem, making even large memory collections manageable.

The most significant change, however, isn’t technical.

It’s who owns the process.

Humans are no longer expected to continuously maintain every memory. Instead, agents are encouraged to autonomously create, organize and refine memories while humans remain responsible for oversight and review. In other words, the filesystem doesn’t merely store knowledge — it becomes a living workspace where both humans and AI contribute over time.

What began as a markdown file has quietly evolved into shared infrastructure for continual learning.

And that’s where the conversation becomes truly interesting.

Because once agents can remember, the next question isn’t how much they can remember.

It’s what becomes possible because they do.

The Catalyst

Every major leap in AI over the last few years has been measured in terms of model intelligence. Models became better at reasoning, writing, coding and planning. But intelligence alone doesn’t explain why some AI systems can now work productively for hours — or even days — without constantly falling back into the same mistakes.

The missing ingredient is memory.

During her talk, Lamis made an important distinction between model intelligence and context engineering. A frontier model may possess exceptional reasoning ability, but it still knows nothing about your organization. It doesn’t know your architecture, your deployment practices, your coding conventions or your team’s preferences. More importantly, it doesn’t naturally improve at those tasks simply because it completed them once before.

That’s where memory changes the equation.

Instead of treating every interaction as an isolated event, memory allows experience to accumulate. Each successful deployment can become deployment guidance. Every debugging session can become troubleshooting documentation. A mistake that once required careful investigation can be recorded so that the next agent encountering the same problem already knows the answer.

In many ways, memory turns execution into learning.

This is what separates long-running agents from traditional chat experiences. A chatbot answers a question and forgets. A long-running agent performs work, reflects on what happened, documents what it learned and carries those lessons into future executions. Every completed task becomes another opportunity to improve the system itself.

This continual learning loop is perhaps the most significant architectural shift hidden behind Anthropic’s recent releases. Whether you look at Fable, which is designed to sustain work over long periods, Opus 5, which tackles increasingly complex engineering tasks, or Claude Tag, which captures reusable development knowledge, they all point toward the same broader direction: AI systems that become more effective because they remember.

That interpretation goes beyond the specific claims made in Lamis’ talk, but it’s difficult to ignore the common thread. Throughout the session, she repeatedly emphasized that memory allows agents to “get better at the task the next time they perform it.” That’s a subtle sentence, but it fundamentally changes how we think about AI systems. Instead of optimizing only for today’s execution, we begin optimizing for every future execution as well.

Perhaps that’s why context engineering has become such an important discipline. It’s no longer just about fitting more information into a prompt. It’s about building systems that preserve knowledge long after the prompt has disappeared.

The Power

One of the most surprising aspects of Anthropic’s memory architecture is how ordinary it looks.

When people hear “AI memory,” they often imagine vector databases, semantic retrieval engines or highly specialized infrastructure built exclusively for large language models.

Lamis described something much simpler.

A filesystem.

Memories are markdown files.

Collections of memories are directories.

Searching those memories is no different from searching a codebase.

At first, this almost feels too simple to be powerful. Yet the more you think about it, the more elegant the design becomes. AI agents are already remarkably capable of navigating filesystems. They know how to traverse directories, inspect files, execute shell commands and search through large collections of documents using tools like grep. Rather than inventing an entirely new abstraction for memory, Anthropic simply allows agents to use the tools they already understand.

That simplicity unlocks several advantages simultaneously.

The first is progressive loading.

Earlier, Skills introduced the idea that only a lightweight description should be loaded into context initially, while detailed instructions remain on disk until the agent decides they’re relevant. The filesystem naturally extends this idea. Instead of loading thousands of memories into every session, the agent searches an index, discovers relevant files and loads only the knowledge it actually needs. Context windows stay focused while memory can continue growing indefinitely.

The second advantage is human readability.

Every memory is simply markdown. Developers can inspect it, edit it, version it with Git and review changes exactly as they would any other project artifact. There are no opaque embeddings or proprietary storage formats hiding organizational knowledge behind another abstraction layer. The same memory that teaches an agent can also be understood and improved by a human engineer.

The third advantage is shared organizational learning.

Traditional AI assistants tend to learn in isolation. Whatever one conversation discovers largely remains trapped inside that conversation. Anthropic’s filesystem approach changes this dynamic. Multiple agents can contribute to the same collection of memories, allowing discoveries made during one execution to become immediately available to future executions.

Imagine one agent identifying an edge case in a deployment pipeline. It documents the issue inside the shared memory store. Hours later, another agent working on an entirely different task encounters the same deployment pattern. Instead of rediscovering the problem, it finds the documented solution and continues working. The knowledge has moved beyond individual experience and become organizational memory.

That’s perhaps the most compelling aspect of this architecture.

It bridges development and production.

The lessons learned while building software no longer disappear once the deployment succeeds. They remain part of the system, continuously guiding every future agent that operates within the same project. Over time, the filesystem evolves into something far more valuable than documentation.

It becomes the organization’s collective memory.

The Guardrails

Autonomy, however, introduces an entirely new set of engineering challenges.

Allowing agents to write memories is easy.

Allowing hundreds of agents to safely write memories at the same time is much harder.

Throughout the talk, Lamis emphasized that the principles behind autonomous memory work beautifully in theory but quickly encounter real-world problems when deployed in production. As organizations begin running fleets of collaborating agents over long periods, memory stops being a prompt engineering problem and starts looking remarkably similar to a distributed systems problem.

Consider a few scenarios.

Two agents may attempt to update the same memory simultaneously.

A single incorrect memory could propagate across every agent in an organization.

Knowledge that was correct six months ago may quietly become obsolete.

Or, in the worst case, malicious instructions could be injected into shared memories, influencing every future execution.

Anthropic’s answer isn’t another layer of prompting.

It’s classic software engineering.

The first safeguard is versioning.

Every memory update records who made the change, which session produced it and the context that motivated the update. This provides a complete audit trail and makes rollback straightforward whenever an update proves to be incorrect. Rather than treating memory as mutable state, Anthropic treats it as an evolving history that can always be inspected and restored.

The second safeguard addresses concurrency.

Multiple agents may independently decide to improve the same memory. To prevent accidental overwrites, Anthropic employs a simple hashing strategy. Before an agent edits a memory, it records the current hash. Immediately before committing the update, it computes the hash again. If another agent modified the memory during that interval, the hashes no longer match. The write is rejected, the latest version is reloaded and the agent regenerates its update before trying again.

Developers will immediately recognize this as optimistic concurrency control — a familiar software engineering pattern adapted for autonomous agents.

Permissions form the third layer of protection.

Not every memory should be editable by every agent. Organizational principles may remain read-only. Team-specific memories may only be modified within their respective domains. Individual scratchpads, on the other hand, can remain fully writable. This balance allows agents to remain autonomous without giving them unrestricted authority over shared organizational knowledge.

Finally comes portability.

As memory accumulates over months or years, it gradually becomes one of an organization’s most valuable assets. That knowledge shouldn’t become trapped inside a single product or tied to one generation of models. Designing memory as portable filesystem artifacts with clean interfaces ensures that organizations retain ownership of their accumulated experience regardless of how their AI stack evolves.

One observation stood out to me while listening to this section.

As AI systems become increasingly autonomous, the engineering challenges begin to look less like artificial intelligence and more like software infrastructure. Version control, concurrency management, permissions and portability have existed in distributed computing for decades. Anthropic isn’t reinventing those ideas; it’s adapting proven engineering principles to a world where autonomous agents become active participants in the system.

The Benefits

The production metrics Anthropic shared — 97% fewer first-pass errors and 30% faster execution — are impressive, but they’re really symptoms of a deeper transformation rather than the story itself.

The reduction in errors doesn’t happen because the model suddenly becomes smarter overnight.

It happens because yesterday’s experience becomes today’s starting point.

Without memory, an agent encounters a deployment issue, solves it and eventually forgets the solution. The next time the same issue appears, it repeats much of the same investigation. With memory, that investigation is already documented. The successful fix becomes part of the project’s knowledge base, allowing future executions to begin where previous ones ended instead of starting from scratch.

This creates a compounding effect.

The first execution is an investment.

Every subsequent execution benefits from that investment.

Speed improves for exactly the same reason.

When an agent already understands your project’s architecture, preferred workflows and historical lessons, it spends less time exploring blind alleys. Fewer reasoning steps are required. Token consumption decreases because less trial-and-error is needed. Tasks that previously required multiple iterations become increasingly achievable in a single pass. Anthropic observed roughly a 30% improvement in execution speed, but the more interesting story is why that improvement occurs. Agents become faster because they spend more time applying knowledge than searching for it.

The final benefit is perhaps the most meaningful, even though it doesn’t fit neatly into a benchmark chart.

It changes the relationship between developers and AI.

Today, engineers spend an astonishing amount of effort repeating themselves. They explain coding conventions, deployment practices, documentation standards and organizational preferences over and over again. They correct the same mistakes across multiple sessions and gradually become the memory system that their AI assistants lack.

Anthropic’s approach shifts that responsibility.

The agents document what they learn.

The organization accumulates knowledge automatically.

Developers can redirect their attention toward designing products instead of continuously tutoring their AI systems.

That’s a subtle but profound change.

For years, we’ve expected humans to train AI through repeated interaction.

Memory begins to reverse that relationship.

Instead of requiring constant supervision, agents gradually become capable of supervising their own learning, allowing developers to focus on solving new problems rather than revisiting old ones.

Dreaming

Even with autonomous memory, Lamis argued that there is still a fundamental limitation.

Memory updates happen in-band — while an agent is actively trying to complete a task. That creates a conflict. Every token the agent spends deciding whether something deserves to become memory is a token it isn’t spending on solving the user’s problem. At the same time, the agent only sees its own session. It has no visibility into the hundreds or thousands of other sessions happening across the organization.

Those two limitations become increasingly important as organizations begin operating fleets of agents.

An individual agent might notice that a deployment failed because of a missing configuration file. What it cannot know is whether that same mistake has occurred fifty times this week across other projects. Likewise, it cannot identify that a particular tool call keeps failing in different teams, or that an organizational coding convention is causing confusion across multiple repositories. From the perspective of a single session, those patterns simply don’t exist.

This led Anthropic to introduce what Lamis called Dreaming.

Unlike memory, Dreaming doesn’t run during the task. It runs afterwards.

Instead of asking the working agent to simultaneously solve today’s problem and improve tomorrow’s performance, Anthropic separates those responsibilities. Agents remain focused on completing their work, while a completely different process is responsible for learning from that work.

Lamis used a wonderful analogy to explain the idea.

Imagine a school.

Students complete assignments every day. Teachers grade those assignments. But there is also a head teacher who reviews results across the entire school. Unlike an individual teacher, the head teacher can recognize patterns that nobody else sees. Perhaps every geography student misunderstood the same concept. Perhaps an entire class keeps making the same mathematical mistake. Those recurring failures suggest a problem with the curriculum rather than the students themselves.

The head teacher doesn’t simply correct individual papers.

They improve the curriculum so tomorrow’s students perform better.

Dreaming plays exactly the same role for AI agents.

Rather than reviewing a single interaction, Dreaming examines collections of transcripts gathered over time. It looks not only at the conversations between users and agents, but also at tool invocations, execution metadata, failures, retries and the memories that already exist. Its goal isn’t to judge one particular session. Its goal is to identify recurring patterns that should change the shared memory itself.

For example, Dreaming might discover that deployment failures consistently stem from an undocumented environment variable. Instead of fixing one deployment, it proposes a new memory explaining the required configuration.

It may discover that agents repeatedly misuse a particular API because the available documentation is ambiguous. Rather than correcting every individual execution, it updates the shared memory so future agents approach the API correctly from the beginning.

It might even identify organizational preferences that emerge over time. Perhaps every team gradually starts using a particular architectural pattern, or repeatedly rejects another. Those trends can become institutional knowledge instead of remaining scattered across hundreds of individual sessions.

This is where Dreaming moves beyond memory.

Memory captures experience.

Dreaming curates experience.

Lamis also described an implementation that reflects this philosophy. A collection of transcripts is distributed across multiple analysing agents. Each agent independently searches for recurring problems, opportunities for improvement and outdated memories. An orchestrator then reviews those findings, determines whether a pattern is significant enough to justify updating the memory store and presents the proposed changes — along with supporting transcripts and statistics — for human review. The final decision still belongs to the developer, ensuring that memory evolves with oversight rather than blind automation.

What I particularly liked about this design is that it separates execution from reflection.

Humans rarely become experts while performing a task. We improve afterwards, when we reflect on what happened, identify recurring mistakes and adjust our approach for next time.

Anthropic is applying the same principle to AI systems.

Instead of expecting every agent to become wiser while it is working, they dedicate a separate process entirely to learning.

That’s a subtle architectural decision.

But it may prove to be one of the most important.

The Takeaways

Lamis’ talk wasn’t simply about introducing another Anthropic feature. It was about describing a different way of thinking about AI systems. Several ideas stood out to me.

Context engineering compounds model intelligence

As frontier models become increasingly capable, competitive advantage shifts toward the context surrounding them. The newest model still doesn’t understand your organization’s architecture, conventions or workflows. Investing in context engineering — and increasingly, memory engineering — continues to pay dividends even as models improve.

Simple abstractions often win

The progression from CLAUDE.md to memory/ wasn't driven by increasingly sophisticated infrastructure. It was driven by simple developer-friendly abstractions that proved surprisingly effective. Markdown, directories and filesystem search turned out to solve many of the problems people expected would require specialized AI databases.

Autonomy matters more than persistence

Persistent storage alone isn’t enough.

The real breakthrough comes from allowing agents to decide what deserves to become memory, when it should be updated and how that knowledge evolves over time. Memory becomes a living system rather than a static archive.

Memory systems are software infrastructure

As soon as autonomous agents begin collaborating, familiar engineering challenges return. Version control, concurrency management, permissions, auditing and portability aren’t optional features — they’re the foundation that allows autonomous memory to scale safely in production.

Learning deserves its own architecture

Perhaps the most forward-looking idea from the session was Dreaming. Learning shouldn’t compete with execution. Reflection deserves dedicated resources, broader visibility and its own lifecycle. Separating execution from reflection may ultimately become as important for AI systems as separating training from inference.

Conclusion

Over the past two years, the AI industry has largely measured progress through model intelligence. Every new release has been evaluated by how much smarter the model became, how many benchmarks it surpassed or how much larger its context window grew.

Lamis Mukta’s talk suggests that the next phase of progress may be measured differently.

The question is no longer just “How intelligent is the model?”

It’s becoming “How effectively can the system learn?”

Anthropic’s evolution from **CLAUDE.md to Memory Tool, Skills and finally a filesystem-backed `memory/`** architecture isn't merely a sequence of product features. It's the emergence of an operating system for long-running AI agents—one that allows knowledge to accumulate instead of disappearing at the end of every conversation.

Memory changes the role of an AI agent.

Instead of repeatedly solving the same problems, it begins building on previous solutions.

Instead of treating every execution as independent, it turns execution into experience.

And instead of requiring humans to continually reteach the same lessons, it allows those lessons to become part of the system itself.

Dreaming extends that idea even further. It recognizes that learning isn’t something that happens accidentally while work is being done. Learning is valuable enough to deserve its own process — one that periodically reviews the past, refines organizational knowledge and prepares the next generation of executions to perform better than the last.

That may ultimately be the most important takeaway from the session.

For years, we’ve been building models that could reason.

Anthropic is now showing what it looks like to build systems that can remember, reflect and continuously improve.

Perhaps that’s the real secret behind long-running AI capabilities. It isn’t simply more intelligence.

It’s memory that survives the conversation, learning that survives the task, and knowledge that survives the model itself.

Anthropic #Claude #AIAgents #ContextEngineering #MemoryEngineering #LLM #AgenticAI #AIEngineering #AIDev #AINative