What's the difference between agent memory and context?

Memory persists across sessions; context is what gets loaded into a single request. A brand-new session has no memory, but it still gets context: the prompt, files, and tool results assembled for that run. Memory is one source that context can be built from.

Do AI coding agents have persistent memory?

Increasingly, yes, but per user. Claude Code keeps memory files, and other agents have similar mechanisms. What they retain is scoped to one person's sessions; it doesn't transfer to a teammate's agent.

Why doesn't per-user agent memory work for teams?

Because each engineer's agent accumulates its own private memory, and none of it transfers. Your agent can learn a constraint on Monday and your teammate's agent can violate it on Tuesday. Coordination needs a shared record both agents read.

Agent Memory

Agent memory is what an AI agent retains across sessions, unlike context, which is loaded fresh into each request. Memory persists; context is per-run.

Agent memory is what an AI agent retains beyond a single run. It comes in layers, and the layers get confused constantly:

Session memory is what the agent holds during one run: the conversation so far, files it read, notes it wrote itself. It lives in the context window and vanishes when the session ends.
Persistent memory is what survives across sessions: memory files, learned preferences, a store the agent writes to and reads back later. Your agent remembers your codebase quirks tomorrow.
Shared team memory is what every agent on the team can read: the decisions, constraints, and conventions the team holds, not one user.

What this looks like in Claude Code

Claude Code's documentation describes two memory systems, both loaded at the start of every session:

CLAUDE.md files, which you write. A project CLAUDE.md is committed to the repo and shared with teammates through version control. Claude Code can also read an AGENTS.md in its place.
Auto memory, notes Claude writes for itself from your corrections and preferences. It is stored per repository under ~/.claude/projects/ and is machine-local: the docs state the files are not shared across machines or cloud environments.

So the shared layer is a file someone has to remember to edit, and the layer that updates itself is private to one machine. The trade-offs are compared in CLAUDE.md vs agent memory.

Memory vs context

The line people miss: memory is a place information lives; context is what actually reaches the model on a given request. An agent with perfect persistent memory still fails if the right memories aren't assembled into context for the task at hand. That assembly is context engineering.

The gap: per-user memory doesn't coordinate a team

Almost all agent memory today is scoped to one user. That's fine for preferences. It's useless for coordination: your agent learning "the events table is append-only" does nothing for the five other agents on your team. Each memory is a silo, so the team's decisions fragment across them, a direct route to decision drift.

This isn't a niche complaint. An engineering manager running two teams (fourteen engineers) filed it against Claude Code (issue #38536), calling individual-only memory "the single biggest efficiency bottleneck for teams adopting Claude Code seriously."

For how these layers work in practice for coding agents, see the AI coding agent memory guide and how to give AI coding agents your team's context.

Lockstep sits in that third layer: a shared, human-approved memory of the team's decisions, served to any MCP-speaking agent, so every session starts knowing what the team decided rather than only what one user's agent happened to learn.