What Happens to Agent Memory When an Engineer Leaves

A senior engineer spends six months correcting their coding agent. Do not reach for that shared fixture in tests, the migration has to run before this suite, we pulled that cache out last spring for a reason. The agent learns. Then they leave, IT wipes the laptop over the weekend, and on Monday their replacement's agent proposes the fixture again.

Nothing in the repository changed. CLAUDE.md is where it was, AGENTS.md is where it was, and git log shows no deletion, because git never tracked the part that disappeared. Agent memory is not one thing. Some of it is committed and survives any departure. Some of it lives in a home directory on a machine that no longer exists, and the difference is a storage path you can check today.

Which layers travel with the repository and which do not

The useful question is not what your agent knows. It is where each piece of that knowledge is written down, and whether a fresh clone on someone else's machine picks it up. Five common locations are below, and they fall into three groups rather than two. Memory-enabled custom subagents keep their own directories outside all five, which the audit further down covers.

Project instructions are the row version control carries. Claude Code's memory documentation describes them as shared with your team through source control, and recommends keeping them to project-level standards for that reason. Claude Code v2.1.277 and later can also read AGENTS.md, but by default only when no CLAUDE.md, .claude/CLAUDE.md, or CLAUDE.local.md exists at or above the working directory. To load both formats, use an @AGENTS.md import or the claude-md-and-agents-md Project instructions setting. Confirm loading with /context after the handoff, because a local override left in place can stop the AGENTS.md you just promoted to from loading at all.

The managed policy row survives a departure too, by a different route. It is deployed to every machine in the organization by IT through MDM, Group Policy, or similar, so it is nobody's personal file and nothing a departing engineer hands over. If your organization uses it, leave it out of the offboarding audit below. It is already somebody else's job, and it holds company-wide standards rather than the project reasoning this article is about.

The last three rows are the personal ones. User instructions sit in the engineer's home directory and apply to every project they touch, which is the wrong scope for a team rule and the right scope for their own shell shortcuts. Local overrides are documented with the instruction to add them to .gitignore, so they are deliberately outside the repository even though the file sits next to project files.

Auto memory deserves a second look because Claude writes it from corrections and preferences, including project decisions it cannot derive from the code or git history. The first 200 lines or 25KB of MEMORY.md, whichever comes first, load at startup. Separate topic files are read on demand, so the startup budget is not the size of what is stored. The default directory is ~/.claude/projects/<project>/memory/, and autoMemoryDirectory can relocate it. Inspect the configured directory and its topic files during the audit, not just the startup index. The path is derived from the git repository, so the notes are scoped to your project, and they are still stored under one person's home directory. Scoped to the repository and stored on a laptop are different properties, and only the second one decides what survives Monday.

If your team runs an agent other than Claude Code, the specific paths will differ. The check does not. Find where it keeps instructions and where it keeps anything it wrote itself, then ask of each location whether a teammate's fresh clone receives it.

The corrections are the part you cannot reconstruct

A wipe takes the home directory and the gitignored files. That much is obvious once the layers are laid out. What makes it expensive is which knowledge tends to live there.

Claude Code's documentation suggests adding an instruction when the agent repeats a mistake, when review catches something it should have known, or when a new teammate would need the same context. Those moments happen in the middle of work. An engineer notices the agent reaching for the wrong pattern, says why in chat, and keeps going. The explanation was never a documentation task, so it never entered a documentation workflow.

That is the gap. A committed CLAUDE.md holds what somebody decided was worth writing up and merging. The corrections hold why a plausible change is wrong here, which is the expensive knowledge precisely because it is not inferable from the code in front of you. An agent reading the repository can see that the cache was removed. It cannot see the incident that removed it.

So "we should write better docs" is a real answer to a different problem. Documentation is authored deliberately and in arrears. Local memory accumulates as a byproduct of working, continuously, without anyone deciding to. Asking every engineer to promote every correction by hand, at the end of a task, under a deadline, is a workflow people skip. Two losses come out of this and they need different fixes: knowledge nobody recorded anywhere, and knowledge recorded only in a layer that does not survive.

An audit to run before the laptop goes dark

Start a few weeks before a known departure, while the engineer can still say why a given line exists. Work the files rather than asking them to recall six months of corrections.

1. See what loads. Have them run /context in each active project and note the files listed under Memory files. Check each worktree separately for a CLAUDE.local.md, since a gitignored file exists only in the worktree where it was created.
2. Read the local layers together. Open ~/.claude/CLAUDE.md, every CLAUDE.local.md, and the configured auto memory directory. If they use memory-enabled custom subagents, also inspect ~/.claude/agent-memory/ and each worktree's .claude/agent-memory-local/. Project-scoped subagent memory lives in .claude/agent-memory/, so verify that it is committed before assuming a clone preserves it. For each item, ask what prompted it and whether a teammate would need it. Keep personal shortcuts, credentials, and private test data out of shared files.
3. Look for contradictions. On v2.1.283 and later, /doctor prompt-audit checks instruction files for outdated or conflicting content and returns a report with proposed edits. Nothing changes until you ask for the edits to be applied, so treat the report as a reviewer's list rather than a fix.
4. Give each keeper a destination. Durable agent instructions belong in a committed CLAUDE.md or AGENTS.md. Longer rationale belongs wherever your team keeps decision history, with a pointer from the instruction file when the agent needs to find it.
5. Land it as a reviewed change. The output is a merged pull request against the instruction files, reviewed by someone who can check a proposed rule against the code. A handoff meeting leaves the agent's instructions exactly as they were.

Make it continuous, because most departures are not scheduled

An audit helps when you know someone is leaving. Laptops also fail, people go on leave, and plenty of departures give you no runway at all. The durable version of this is a habit rather than an event.

The trigger is repetition. When an agent needs the same correction twice, that is the signal the rule belongs somewhere a teammate's clone will pick it up, and the next pull request is a reasonable place to ask. Someone still has to check the proposed rule against the code before it lands, because a wrong instruction in a committed file is worse than no instruction. Every agent on the team now reads it with confidence.

This is the gap Dosu is built to close. Dosu reads connected Sources, which are GitHub and live web access, plus Slack and Notion on the Teams plan, and turns that activity into Documents in a Library. Monitors watch a Source for changes worth documenting. When a pull request is opened or marked ready for review, a Monitor compares the change against published Documents and flags the ones that have fallen out of date with a targeted edit. That edit goes to Review, where a person accepts, edits, or declines it unless you turn on auto-accept. Coding agents then read that knowledge over the Dosu MCP Server, which works with Claude Code, Cursor, VS Code Copilot, and other MCP-compatible clients.

Capture that runs off pull requests, issues, and team chat produces a record that outlives any individual's machine, because it was never on that machine to begin with. Dosu does not read a departing engineer's auto memory, and nothing described here will. What continuous capture changes is how much of the team's reasoning was sitting in those local layers in the first place.

FAQ

Does wiping a laptop delete agent memory?

It deletes everything under the engineer's home directory and any gitignored files in their worktrees, which covers user instructions, local overrides, main-session auto memory, and the user and local scopes of any subagent memory. Committed project instructions come back with any clone, as does project-scoped subagent memory once it has been committed. Whether a local copy survives depends entirely on whether your organization backed up or synced those paths, so confirm that rather than assuming it.

Can auto memory or CLAUDE.local.md be recovered after the fact?

Only from a backup, a synced copy, or an export made before the wipe. The repository cannot restore a file it never tracked. This is worth checking before the machine is reclaimed rather than after.

Should we just commit the local files?

Read them first, then move only what applies to everyone into a shared CLAUDE.md or AGENTS.md as a reviewed change. Local layers collect personal preferences and sometimes sandbox credentials or private test data, none of which belongs in a repository.

How is this different from ordinary offboarding?

Revoking access stops a departing engineer from reaching company systems. Memory review is the opposite problem, because something on their machine is worth keeping and disabling an account does not copy it anywhere. The two run on the same schedule and need separate checklists.

For an audit trail, how does auto memory compare to a committed file?

A committed instruction file has review history, so you can see what changed, when, and who approved it. Auto memory has none of that, and you can only read it while you still have access to the machine it sits on. Neither one tells you whether an agent followed an instruction in a given session.

Find out what is only on one laptop

Pick the engineer on your team with the longest tenure and have them run /context in your main repository, then open their auto memory directory and, if they run memory-enabled subagents, ~/.claude/agent-memory/. Anything in there that a teammate would need, and that is not in a committed file, is currently one laptop away from gone. That list is usually short and more specific than you expect, which makes it a good first pull request.

Then close the other half. Connect a repository to Dosu and see what the next merged pull request proposes for your Documents, so the reasoning your team works out keeps landing somewhere a new hire's agent can read.