TL;DR: The brain you built in Claude Code stops at one person because it was designed for one person. Auto memory is machine-local, session learnings die with the session, and your Obsidian vault has exactly one reader. That matters more than it used to, because 42 percent of institutional knowledge is unique to the individual and FDE teams are growing fast. Teams that moved account context into a shared, queryable memory report results like 3x rollouts per engineer at Aircall. This article maps where the personal setup breaks and what a team memory has to hold.

Forward deployed engineering is being staffed faster than it's being systematized. Monthly job listings for the role grew more than 800% between January and September 2025, and the job itself runs on context. A forward deployed engineer is an engineer who spends roughly half their time with customers understanding the problem and half building the solution for that specific customer. Both halves produce knowledge that never lands in a ticket: what the customer promised, what you decided in a session at 4pm, which integration path you ruled out and why.

The best FDEs already solved this for themselves. They pipe call transcripts through Claude Code, keep an Obsidian vault per project, and maintain migration files so a fresh session picks up where the last one ended. It works, and it works well, right up until a second person needs what's in it. A founding FDE at a vertical fintech startup put it plainly: "Shared context is still not a solved problem. It's really surprising."

He's right, and the reason is structural rather than a missing feature. Every layer of the personal stack, from Claude Code's memory model to the vault on disk, assumes a single owner. This article walks through the stack as it really gets built, the four places it breaks, and the three kinds of memory a team version has to hold. If you want the definition-first treatment of the term itself, that lives in what is shared context.

The personal brain stack, as FDEs actually build it

The setup we see over and over has three layers, assembled independently by people who never compared notes. That convergence is the strongest evidence the problem is real.

A vault, a transcript pipe, and a terminal

The base layer is a markdown vault, usually Obsidian, with a folder per account. Call transcripts flow in from a recorder, get summarized by Claude, and land as daily notes. Decisions, commitments, and gotchas accumulate as the engagement runs. This is the second brain pattern applied to client work, and solo it's genuinely good.

On top of that sits Claude Code. The vault becomes context for sessions, sessions produce solutions and decisions, and some of those flow back into notes. A head of FDEs at a workflow-automation platform described the volume honestly: "there's been several, several dozens of sessions that I've had with Claude code. And I'm just starting to realize there's no, like, centralization to those sessions."

The migration ritual

The third layer is manual glue. When a session's context window fills, the FDE writes a handover file for the next session: current state, open threads, decisions made. It's a context migration performed by hand, several times a week, and it only migrates context to yourself. Anthropic's own guidance leans the same way, recommending you clear context between tasks because the window fills fast. Sessions are designed to be discarded. The knowledge in them isn't.

Some teams are trying to formalize all this. An FDE at a vertical AI startup told us his team is building "what we call internal FD OS or FD operating system," with the goal of creating "a shared context repository" for everyone. That instinct is correct. The tools underneath fight it.

Why doesn't the brain you built in Claude Code share across the team?

The short answer: the only part of Claude Code memory that's team-shared is the part that holds coding conventions, and account context doesn't belong there.

What CLAUDE.md actually shares

Claude Code's memory hierarchy has one genuinely shared layer. The official docs list project memory as "Shared with: Team members via source control," and the best-practices guide tells you to check CLAUDE.md into git so your team can contribute. So instructions, conventions, and build commands do cross people, as long as those people work in the same repo.

That's a real mechanism, and it's the wrong shape for account state. A CLAUDE.md that says "use pnpm, prefer the v2 API" compounds in value. A CLAUDE.md that says "Meridian's cutover slipped to October 12 after Tuesday's call" is stale the moment the next call ends, and your sales team will never open the repo to read it. We take this apart file by file in Claude Code memory for teams.

What never leaves your machine

The layer that actually learns from your work is personal by design. The same docs state that "Auto memory is machine-local," and that its files "are not shared across machines or cloud environments." Everything Claude Code picks up across your sessions about an account, every debugging dead end and every customer constraint, stays on your laptop. Your teammate's Claude starts from zero on the same account.

Users have noticed

This isn't a niche complaint. An open feature request on the Claude Code repository asks for "a shared layer where at minimum: project memory and skills are accessible across Claude Code, Cowork, and Claude.ai Projects," and notes that memory files, MCP connections, and context don't transfer between surfaces today. The demand is registered. The product's memory model remains personal, which is reasonable for a coding tool and a real gap for a team running customer accounts through it.

Where does a personal brain break? The four break points

A solo FDE with a tight vault feels no pain. The pain arrives on a schedule, at four predictable moments. If you're planning how your FDE team is structured, these four are worth designing for before they happen.

Break point 1: the second FDE joins the account

The first hire against your account is where the wall appears. The founding FDE quoted above was blunt about it: "the number one thing is I cannot share the Obsidian brain with other people." Obsidian's sync collaboration exists, but the official limits are stark for team use: "Fine-grained permissions are not supported yet. All collaborators receive the same permissions as the vault owner," no real-time editing, and conflicts merged at sync time. Two writers in one vault is a merge problem, not a memory.

So the second FDE ramps the old way, by interrupting the first. Research on onboarding puts new-hire ramp at up to six months, much of it spent hunting for knowledge a colleague already has. We wrote a separate playbook for onboarding a second FDE onto a live account, and the whole thing depends on context the new person can query without asking.

Break point 2: the engineer (and their coding agent) needs the customer's context

Product engineers building against your account need to know what was promised and what was decided, and increasingly their coding agents need it too. Google's 2025 DORA report found 90% of respondents now use AI at work, while 30% report little or no trust in AI-generated code. Context quality is the lever, because as the same report puts it, AI "amplifies what's already there." An agent fed stale or missing account context amplifies exactly that.

Today the FDE bridges this gap in person. An FDE at an insurance-claims platform described the result: "Sales is saying something different. Marketing is saying something different. I'm implementing something... it's like kind of playing broken telephone with outdated documentation." Every relay through a human also costs the human. Interruption research puts the price of each context switch at 23 minutes and 15 seconds to get back to the original task.

Break point 3: the manager and the sales team ask a status question

The third break point is the reader who will never open a vault or a terminal. Your manager preparing a QBR, the account executive walking into a renewal call, the support lead triaging an escalation. As the fintech FDE noted, "the salespeople don't use the Claude code." Their questions are simple, and answering them is expensive: 72% of project professionals spend half a day or more every month collating reports. That half day is mostly the FDE re-narrating what their own notes already know, to people who can't read the notes.

Break point 4: the handoff

Leave, rotation, promotion, an acquisition that adds accounts. Eventually the person who holds the context stops being available, and this is where the personal brain fails hardest. Panopto's 2018 research found that 42 percent of institutional knowledge is unique to the individual, and estimated the cost of inefficient knowledge sharing at $47 million a year for a large enterprise. A handoff document written the week before departure is a snapshot. It can't answer follow-up questions, and nobody can verify it against sources once the author is gone.

What does a team memory need to hold?

Naming the break points is the easy half. The harder question is what a shared memory must actually contain to survive them. Watching FDE teams that made the move, the answer is three streams, each with sources attached. This is the shape of a project brain, the category artifact these teams converge on.

Account events: what was promised and what changed

The first stream is the customer-facing record. Commitments made on calls, dates that moved, scope that changed, risks that surfaced. This is the material currently trapped in transcripts and daily notes, and it's what the second FDE and the account executive both need. The test is whether a fact carries its source: a claim like "cutover moved to October 12" should link to the call where it moved.

Product decisions: what was decided and why

The second stream is decisions, especially the ones made mid-build. Which API path you chose, what you ruled out, what constraint forced it. These are the facts engineers rediscover the hard way when they're missing, and rediscovery is expensive. Knowledge workers already lose 5.3 hours every week waiting for or recreating knowledge a colleague has, and a decision rediscovered wrong is worse than one rediscovered slowly.

Sessions: what happened in the terminal

The third stream is the newest and the leakiest. Real delivery decisions now happen inside Claude Code sessions, and when the session ends they're gone. The dozens-of-sessions problem the head of FDEs described above is a decision log that was never written anywhere. Getting selected session outcomes into team memory, deliberately and with your approval on what syncs, is its own workflow. We cover it in product decisions made in Claude Code sessions.

Where does the team memory need to be reachable?

Content is half the spec. The other half is reach, because each break point involves a reader in a different tool, and a memory only counts as shared if people can use it where they already work.

For engineers and their agents, that's the terminal. Tandem's account brain is reachable through Tandem MCP from Claude, Claude Code, or ChatGPT, and at Aircall, "Engineers query rollout context (commitments, porting dates, integration decisions) through Claude via MCP." Paul Yi, a senior software engineer there, described what that feels like in practice: "I ask 'what's blocking the cutover' in Claude and get the actual answer, with sources. Same question, same answer, whoever asks. We tried to build that. It didn't hold."

For managers and sales, it's Claude chat, where they can ask the same brain the same questions without touching a terminal. For everyone else it's Slack, where a brief arrives on demand or on schedule. Several people push to one brain, alert recipients are configurable, and the brain itself is edited through an AI chat interface rather than by gardening markdown files. A Salesforce connector covers the CRM side. When the brain runs a risk check, it returns a list of risks, each with an explanation, the reason, and the sources and quotes behind it, so a human can verify before anything goes in front of a customer.

Personal brain vs team memory: what actually changes

Most teams don't jump from a vault to a product. The realistic comparison includes what they're actually using today, starting with the default nobody chose on purpose.

  • Spreadsheets + Slack. Who can read it: Everyone, in theory. Who keeps it current: Nobody in particular, updates lag. Handoff survival: Poor, threads scatter and trackers go stale. Agent access: None.
  • Obsidian vault + Claude Code. Who can read it: The owner. Who keeps it current: The owner. Handoff survival: Poor, 42% of knowledge stays with the individual. Agent access: Owner's sessions only.
  • CLAUDE.md in git. Who can read it: The repo's engineers. Who keeps it current: Whoever commits. Handoff survival: Partial, conventions survive, account state was never in it. Agent access: Yes, but conventions only.
  • Home-built context store. Who can read it: Configurable. Who keeps it current: An engineer, part-time. Handoff survival: Varies by team, drift is the risk. Agent access: If you build it.
  • Project brain (e.g. Tandem). Who can read it: Whole team, from Claude Code, Claude chat, or Slack. Who keeps it current: Synced from calls, sessions, and connectors, humans approve. Handoff survival: Designed for it. Agent access: Via Tandem MCP.

Two honest notes on that table. The home-built row can absolutely work, and it keeps you in full control, but our observation across teams is that a regular brain (Obsidian and the like) drifts somewhere between 500 and 1,000 facts, once reconciling it stops being anyone's job. And the build-vs-buy call deserves more than a table cell, so we've laid out the real patterns and costs in build vs buy a shared context layer. MIT's 2025 research adds a base rate worth knowing before you commit an engineer to it: purchased specialized tools succeeded around 67% of the time versus roughly a third for internal builds, in a field where 95% of enterprise AI pilots showed no measurable P&L impact, largely because generic tools don't learn the team's workflows.

Moving without a migration project

Teams that made the switch didn't stop working to do it. The pattern looks like this:

  • Pick one live account, not your archive. Migrating years of vault history is the task that kills the project. Start the memory at today.
  • Connect the event sources first. Calls and the CRM give the brain its account-event stream before anyone changes a habit.
  • Keep your personal stack, add the sync. Your vault and your sessions stay. What changes is that chosen outcomes get pushed to the shared brain, and you decide what's worth pushing.
  • Give the readers their doors. Engineers get Tandem MCP in Claude Code, the manager gets Claude chat, the account team gets the Slack brief.
  • Let the first handoff or ramp be the test. The measure of a team memory is whether the next person needs the last person, ideally before that becomes urgent. Spendesk's head of customer success and account management, Mathilde Hamy, describes the passing grade: "An engineer picks up any account and knows in five minutes what was promised and what's at risk. Nobody maintains anything."

What stays manual

A shared memory removes the courier work, not the judgment. Being specific about the line matters more than the pitch.

You still decide what syncs from a session. Nothing moves from your terminal to team memory unless you choose it, and auto-resync at every checkpoint is a request we haven't shipped. Agents draft and flag, but risks come back with reasons and sources precisely so a human can approve or reject before anything reaches a customer. The relationship itself doesn't transfer either. A new FDE can read every commitment in five minutes and still need weeks to earn the trust behind them, which is why our ramp playbook treats context transfer and judgment transfer as different problems. And the first hard conversation on an account is yours, whatever the brain knows.

The outcome, in business terms

The break points compound quietly, which is why teams tolerate them for so long. The return from fixing them shows up in three places, in this order: hires you don't make, engagements that move faster, and admin hours that disappear.

The hires-avoided case is the biggest. Qonto's onboarding org runs about 90 specialists. Tandem's automated coordination and day-three delay detection let the team absorb 34% more volume and avoid roughly 23 hires. At €80K to €100K fully loaded per specialist, that is €1.8M to €2.3M in avoided payroll against a Tandem cost of about €0.85M a year, a 2 to 2.7x return in year one. The full model is in the Qonto story.

Speed is the second return. Aircall cut time from contract to cutover 30% and now runs 3x rollouts per engineer (5 → 15). Their CPO Tom Chen named the mechanism: "We're seeing engineers confidently run rollouts they've never been on a call for. The memory belongs to the team, not the person." That last sentence is the whole thesis of this article in nine words.

If you run an FDE or implementation team, the question isn't whether your people have brains. They do, good ones, and each brain currently has one reader. See how Tandem works for FDE teams, or better, see Tandem flag the risks on one of your live implementations in a demo.

FAQs

Can't I just check CLAUDE.md into git and call it shared context?

You should check it in, and it solves a different problem. Project CLAUDE.md shares coding conventions with people in the same repo, which the docs recommend. Account state (commitments, dates, decisions, risks) changes daily, needs sources, and needs readers who will never clone the repo. See Claude Code memory for teams for the full breakdown.

Do I have to abandon my Obsidian vault and Claude Code setup?

No, and you shouldn't. The personal stack is where the context gets created, and it stays your working environment. What changes is that chosen outcomes sync to a shared brain other people and agents can query, instead of stopping at your laptop.

Can I trust AI-generated account state in front of a customer?

Trust the sources, not the summary. Tandem's risk check returns each risk with an explanation, the reason, and the source quotes behind it, so you verify the claim before you repeat it. Aircall's engineers describe getting "the actual answer, with sources," and the same answer regardless of who asks.

What if my FDE team is just me right now?

Then your personal setup is probably fine today, and the break points are on your calendar anyway. The second hire, the first engineer who needs your context, and the first handoff all arrive faster than teams expect, given hiring in the role grew over 800% in nine months. Starting the shared memory early is cheaper than reconstructing it later.

Is a team memory the same thing as a knowledge base or enterprise search?

No. A knowledge base holds curated documents, and search retrieves what was written, whenever it was written. A team memory holds current, source-linked account state: what was promised, decided, and at risk, as of now. The project brain for FDEs piece draws the line in detail.

Key terms

Shared context: the account knowledge a whole team and its AI agents can query, rather than knowledge held by one person. The term comes from practitioners, and it names the problem this article covers.

Team memory: a synonym for shared context, emphasizing persistence. Memory that survives the departure, promotion, or vacation of any single member.

Project brain: the category artifact, a maintained, source-linked record of an engagement's state that people and agents query instead of asking whoever knows.

Account brain: the part of Tandem, the AI workspace for implementation and deployment teams, that holds shared account context, runs risk detection with sources, and feeds Tandem agents and the customer workspace.

Forward deployed engineer (FDE): a forward deployed engineer is an engineer who spends roughly half their time with customers understanding the problem and half building the solution for that specific customer.

CLAUDE.md: Claude Code's project memory file. Shared with teammates through source control, and intended for conventions and instructions rather than account state.

Auto memory: Claude Code's machine-local memory that accumulates learnings across your sessions. It is not shared across machines, people, or cloud environments.

Tandem MCP: Tandem's MCP server, which makes the account brain queryable from Claude, Claude Code, or ChatGPT, for humans and coding agents alike.

---