The Fleet Forgets When the Engineer Leaves

Your most productive engineer just gave notice. You know the drill: transfer the tickets, document the deploy process, hand off the on-call rotation, schedule the brain-dump sessions. The offboarding checklist has been refined over decades, and it covers everything the company thinks it owns.

Here's what the checklist misses in 2026: that engineer's home directory contains a personal CLAUDE.md tuned over eighteen months, a dozen custom skills that encode exactly how to navigate your gnarliest subsystem, memory files where their agent accumulated hard-won facts about your codebase, and harness settings calibrated through hundreds of sessions of trial and error. None of it lives in the repo. None of it transfers with the account.

On their last day, IT deactivates the laptop, and months of compounded agent configuration — the difference between their agent shipping features unattended and everyone else's agent flailing — evaporates without anyone noticing it existed.

This is a new species of an old problem. We used to worry about the bus factor for code knowledge: the senior engineer who was the only person who understood the billing system. But code knowledge at least leaves fingerprints — commits, PR reviews, design docs, Slack threads. Agent configuration is worse. It's tacit knowledge that got written down, which sounds like progress, except it got written down in the one place your organization never looks: dotfiles.

Where the Shadow Config Lives

To understand what walks out the door, you have to understand the split between personal and shared agent configuration — a split that every major coding-agent harness bakes into its design.

Take Claude Code as the representative example, since its layout has become the de facto pattern. Project-level configuration lives in the repo: a root CLAUDE.md, skills and subagents under .claude/ — all of it committed to git, all of it shared. But there's a parallel universe under ~/.claude/: a global CLAUDE.md that loads in every session, personal skills in ~/.claude/skills/, personal subagents in ~/.claude/agents/, persistent memory directories scoped per project, and settings.json with permission rules and hooks. The same duality exists in Cursor, Codex CLI, and every serious harness: repo config for the team, home-directory config for the individual.

The design is sensible. Personal preferences shouldn't pollute team config. But look at what actually accumulates in the personal layer of a heavy user after a year:

• Workflow skills: "how to run the flaky integration suite and interpret its three failure modes," "how to safely regenerate the GraphQL schema without breaking the mobile client."
• Codebase memory: agent-written notes like "the orders service retries are configured in the deploy repo, not the service repo — always check there first."
• Permission and hook tuning: which commands are pre-approved, which linters run automatically after edits, which directories are off-limits — a codified risk model of the codebase.
• Prompting idioms: the personal CLAUDE.md paragraphs that stop the agent from making that one recurring mistake in your legacy module.

Every item on that list is institutional knowledge about your systems. It reads like the onboarding doc you never wrote. And it lives in a directory that your backup policy probably ignores and your offboarding checklist definitely does.

Why This Knowledge Is More Perishable Than Code Knowledge

There's a tempting counterargument: engineers have always had personal tooling — vimrc files, shell aliases, custom scripts — and we never treated those as company assets. Why is agent config different?

Three reasons, and they compound.

The leverage is categorically higher. A departing engineer's shell aliases saved them keystrokes. Their agent config saved them decisions. A tuned harness setup is the difference between delegating a full refactor to an agent overnight and babysitting it through every file. With 84% of developers now using or planning to use AI tools and half of professionals using them daily, per the most recent Stack Overflow survey, the productivity delta between a tuned and untuned setup is now a meaningful fraction of an engineer's total output. When they leave, the team doesn't just lose their output — it loses the multiplier they built.

The knowledge is invisible to the team while it's being created. Code knowledge leaks into shared spaces continuously: reviews, standups, docs. Agent config accrues silently. Nobody sees a colleague add a memory file entry or refine a skill. There's no PR, no notification, no artifact in any shared system. The first time the team learns the config existed is when they wonder why a certain class of task got slower after the departure — if they ever connect those dots at all.

It's already written down, which removes the usual forcing function. Classic knowledge-transfer rituals exist because tacit knowledge dies unless someone extracts it in exit interviews and shadowing sessions. Agent config is perversely worse off: it has been extracted, painstakingly, into precise machine-readable instructions — so the departing engineer doesn't feel the knowledge is at risk, and no one schedules the transfer session. The document exists. It's just in a grave.

Researchers studying institutional knowledge in agentic development have started calling skills and agent instructions a "knowledge primitive" — the atomic unit through which organizational context reaches both AI agents and new hires. That framing is right, and it has a sharp corollary: a knowledge primitive stored in a home directory is a single point of failure with a scheduled demolition date.

The Audit: What to Do Before the Exit Interview

If someone influential in your team's agent adoption resigns tomorrow, here's the triage. It takes an afternoon, and it should happen in the first week of the notice period, not the last.

Inventory the personal layer. Sit down with the departing engineer and list what exists: global instruction files, personal skills and subagents, memory directories, settings and hooks, and any custom slash commands. You're not confiscating anything — most of it will be genuinely personal preference. You're sorting it into three buckets: personal taste (leave it), company-specific knowledge (migrate it), and credentials or sensitive data (revoke it — more on that below).

Migrate by promotion, not by copying. The wrong move is tarring up ~/.claude/ and dropping it in a shared drive, where it becomes an unmaintained snapshot nobody trusts. The right move is promoting each company-relevant item into the repo where it belongs: the memory note about the orders service becomes a line in that service's CLAUDE.md or AGENTS.md; the flaky-test skill becomes a committed project skill; the permission rules that encode "never touch the payments directory without review" become team-level settings. Committed config gets reviewed, versioned, and maintained. Copied config rots.

Sweep for secrets while you're in there. Personal agent config is also a shadow-AI surface: MCP server credentials, API tokens embedded in settings, hooks that call internal endpoints. Auditors have been warning about ungoverned AI tooling for two years — IBM's breach-cost research found that incidents involving unsanctioned AI tooling added over half a million dollars to average breach costs. The offboarding sweep is your chance to find tokens that no secrets manager knows about.

The Real Fix Is a Graduation Ritual, Not a Departure Ritual

The audit above is damage control. If you're doing knowledge transfer during a notice period, you've already lost most of the value — the engineer is checked out, the timeline is compressed, and you'll capture the artifacts but not the judgment behind them.

The durable fix is to make promotion from personal to shared config a routine part of engineering work, the same way we made testing and code review routine. Call it a graduation ritual: personal config is the nursery where conventions are born, and graduation to the repo is how they become team property.

Concretely, that looks like a few habits:

• A standing question in retros and reviews: "Is any of this in your personal config? Should it be in the repo?" When someone's agent handles a task noticeably better than everyone else's, that's not a curiosity — it's an unmerged branch of team knowledge.
• A low-friction path to promote. Adopting the AGENTS.md convention — now supported natively by more than two dozen tools and present in tens of thousands of open-source repos — means promoted knowledge is portable across whichever harnesses your team runs, instead of being locked to one vendor's format. A personal skill graduating to .claude/skills/ or its tool-agnostic equivalent should be a five-minute PR.
• Treat personal config as a staging area with a TTL. The heuristic: if a note about the company's systems has lived in your home directory for a month and still proves useful, it's not a personal preference — it's undocumented team knowledge, and it's overdue for a PR.
• Watch the asymmetry metric. If one engineer's agent sessions consistently succeed at tasks where teammates' sessions fail, the gap is usually config, not talent. That gap is measurable if you look at session outcomes, and closing it is cheap.

There's a cultural component too. Engineers hoard personal config for the same reason they hoard any private tooling: promotion means review, review means friction, and there's a whiff of ego in "my setup is my edge." Teams that get this right make promotion feel like status — shipping a skill the whole team uses is a visible contribution, the 2026 equivalent of writing the wiki page everyone bookmarks.

Productivity That Survives the Account

The uncomfortable summary: as more engineering output routes through agents, an increasing share of what makes your team good lives in configuration rather than in heads or in code. Configuration is the most portable form of knowledge we've ever had — it's plain text, it's diffable, it's reviewable. Whether it compounds for the team or dies with an account deactivation is purely a question of where it sits.

So run the thought experiment now, not during someone's notice period: for each engineer on your team, if their laptop were wiped tonight, what fraction of their agent-assisted productivity would survive in the repo? If the honest answer is "most of it," your team is building a durable asset. If it's "almost none," you don't have a team capability — you have a collection of personal ones, temporarily co-located.

The fleet only remembers what you commit.