TL;DR: Shared context is the account's memory that a whole team and its AI agents can query, and it must answer four questions with sources attached: what was promised, what was decided, what's at risk, and what's next. It is not a knowledge base, not enterprise search, and not agent memory. The problem it fixes is quantified: 42 percent of institutional knowledge is unique to the individual. The result when it works looks like Aircall's 3x rollouts per engineer (5 → 15).
"Shared context" is not our term. Practitioners named it before any vendor did. "Shared context is still not a solved problem," a founding FDE at a vertical fintech told us, surprised that in 2026 he still couldn't hand his transcripts and working notes to a teammate. An FDE at a vertical AI startup described the internal tool his team is building as "a shared context repository" for everyone. And an open feature request on the Claude Code repository asks for "a shared layer" where project memory and skills reach every surface a team works in.
When users independently name the same missing thing, it deserves a precise definition. This page gives that definition, the four questions that test it, and the categories it gets confused with.
The problem side, where personal AI setups break as a team grows, lives in the shared context problem for FDE teams. This page stays with the definition.
Shared context, defined
Shared context is the account's memory that a whole team and its AI agents can query, answering four questions with sources attached: what was promised, what was decided, what's at risk, and what's next.
Each phrase in that sentence is doing work. "The account's memory" means facts about one customer engagement, not company documentation, which changes on a different clock. "A whole team and its AI agents" means the FDE, the second engineer, the manager, and sales get the same answer, and so does a coding agent mid-session. "Query" means you ask and get an answer, rather than browse and hope. "With sources attached" means every fact points back to the call, thread, or session it came from, so a skeptical reader can verify it in seconds.
Teams use "team memory" as a synonym, and the artifact that stores it is usually called a project brain. The same 2018 research that produced the 42 percent figure found knowledge workers waste 5.3 hours every week waiting for or recreating knowledge a colleague already has. Shared context is the layer that makes that wait unnecessary.
The four questions shared context must answer
A store of information qualifies as shared context when anyone on the account, human or agent, can get a sourced answer to these four questions without asking a person.
What was promised
Commitments made to the customer: scope, dates, integration behavior, who owns which step. Promises are the facts most likely to live in exactly one head, because they're made verbally on calls and confirmed in passing. They're also the facts with the highest cost when two people give the customer two versions.
What was decided
Decisions and their reasons. Why this customer got webhooks instead of polling, why the cutover moved, why the workaround is deliberate. Increasingly these decisions happen inside AI coding sessions, and reasons matter more than outcomes here, because engineers and their coding agents need the why to avoid unbuilding it.
What's at risk
The slipped date, the assumption that stopped being true, the scope change the customer mentioned to one person. In Tandem's account brain this question has a dedicated mechanism: the risk check returns a list of risks, each with an explanation, the reason, and the sources and quotes behind it. Any action an agent proposes on a risk goes to a person for approval first.
What's next
The next steps on the account, per owner. This is the question status meetings exist to answer, and the one a shared memory answers without the meeting.
What shared context is not
Three adjacent categories get sold as answers to this problem. Each is good at a different job.
It's not a knowledge base
A knowledge base holds curated documents about your product and your process. It answers "how does our API handle retries", not "what did we promise this customer by March". Account facts change weekly, and documents written once don't.
It's not enterprise search
Enterprise search retrieves what was written, wherever it was written, ranked by relevance. That's genuinely useful, and still a different job: search can't reconcile two contradictory status updates, and it can't answer what was never written down as a document. We've made the longer argument in enterprise search is not a project brain.
It's not agent memory
Agent-memory products describe their job precisely. Mem0 is "drop-in memory infrastructure for AI agents and apps", and Supermemory is "the memory layer for AI agents". These store one agent's memory of one user, preferences and history, as developer infrastructure. That's a real need and they serve it well. It's a different axis: agent memory deepens one agent-user relationship, while shared context spans people and agents across an account. The full comparison is in agent memory vs team memory.
Here's the same distinction as a table, starting with what most teams actually run on today.
- Spreadsheets + Slack. What it holds: status cells and scattered threads. Who queries it: anyone willing to scroll. Answers "what was promised to this customer?": sometimes, freshness varies by team.
- Knowledge base. What it holds: curated docs about product and process. Who queries it: the team. Answers "what was promised to this customer?": rarely, accounts change faster than documents.
- Enterprise search. What it holds: an index of what was written. Who queries it: anyone with permissions. Answers "what was promised to this customer?": only if someone wrote it down as a document.
- Agent memory (Mem0, Zep class). What it holds: one agent's memory of one user. Who queries it: that agent, via its developer's code. Answers "what was promised to this customer?": no, it stores preferences and interaction history.
- Shared context (project brain). What it holds: source-linked account facts. Who queries it: the team and its agents. Answers "what was promised to this customer?": yes, with the source attached.
How does shared context relate to context engineering?
Context engineering is the adjacent discipline, defined by Sourcegraph as "deliberately designing what a large language model sees on every inference call". That framing is aimed at platform builders running a single pipeline. Shared context extends the same discipline to a team: deciding what every person and every agent sees when they ask about an account, not what one model sees in one pipeline.
The transport for this already exists. MCP is an open standard for connecting AI applications to external systems, described in its own docs as being "like a USB-C port for AI applications" and supported by Claude, ChatGPT, VS Code, and Cursor. The distinction worth keeping: MCP moves context, it doesn't remember anything. Something has to be the memory on the other end of the port, and that something is the shared context layer.
What shared context looks like in practice
The definition gets concrete when you watch it work. At Spendesk, Mathilde Hamy, who leads customer success and account management, describes it this way: "An engineer picks up any account and knows in five minutes what was promised and what's at risk. Nobody maintains anything." At Aircall, CPO Tom Chen compresses the whole definition into one line: "The memory belongs to the team, not the person."
You can test whether your team has shared context in an afternoon.
- Ask from outside the account. Pick a teammate who has never joined a call on the account and ask them "what did we promise?" If they can answer in five minutes without pinging anyone, you have shared context. If they ping the owner, you have a person.
- Follow one fact to its source. Take any claim in your tracker and try to reach the call or thread it came from. A fact you can't trace is a fact you can't trust in front of a customer.
- Ask from every surface. A manager should get the answer in Claude chat, an engineer in Claude Code, and the team in a Slack brief. Tandem's account brain works this way: queryable through Tandem MCP, edited through an AI chat interface, with briefs on demand or scheduled, delivered anywhere including Slack.
- Have two people write on the same day. Shared context is multiplayer by definition. Several people push to one brain, and alert recipients are configurable.
- Ask what changed this week. Memory that can't distinguish current from superseded isn't shared context yet, it's an archive.
What stays manual
The definition promises a queryable memory, not a self-running one, and the boundary matters.
Someone decides what's worth keeping. Syncing a Claude Code session into team memory is an action you trigger, and you choose what pushes. Wrong facts need a human to correct them, which the chat interface makes fast but doesn't make automatic. When a customer reverses course without telling you, no memory layer knows until a person or a connected source does.
Judgment stays with people too. Two teammates with identical context can still read a situation differently, and shared context deliberately transfers the facts, not the call. And every action a Tandem agent proposes runs through human approval before anything reaches a customer.
Start with the four questions
The definition is compact enough to use today: the account's memory, queryable by the whole team and its agents, answering what was promised, what was decided, what's at risk, and what's next, with sources. Run the four questions against your current setup and you'll know within an hour whether you have shared context or a stack of personal ones.
If the answer is a stack of personal ones, see Tandem flag the risk on one of your live implementations in a demo, with the four questions answered on your own account.
FAQs
Is shared context the same as a single source of truth?
They're related, and shared context is the stricter test. A single source of truth for implementations names where facts should live. Shared context adds what that source must answer (the four questions), demands sources on every fact, and requires that AI agents can query it, not only people.
How is shared context different from a project brain?
Shared context is the capability, a project brain is the artifact that provides it. If the brain answers the four questions with sources for everyone on the team, you have shared context. Tandem's account brain is a project brain plus risk detection, Tandem agents with human approval, and a customer workspace.
Who maintains shared context?
In a product like Tandem, sync from calls, Slack, tickets, and coding sessions does most of the carrying, and edits happen through a chat interface. Spendesk's summary was "Nobody maintains anything." In home-built setups maintenance becomes a real job: in our observation, a regular brain (Obsidian and the like) drifts somewhere between 500 and 1,000 facts.
Can I trust AI-generated account state in front of a customer?
Trust it the way you'd trust a colleague's summary: verifiable, not blind. Every answer carries its sources, so you can check the underlying quote before the call. Actions that touch customers go through human approval.
Do AI agents make shared context necessary?
They raise the price of not having it. An agent acts on whatever context it's given, so a team without a shared layer gets one well-informed agent per informed person and confidently wrong agents everywhere else. See why coding agents need the FDE's context for the engineering version of this argument.
Which tools provide shared context?
Most tools sold for it provide a neighboring capability instead, which is why the definition matters. We compared seven options honestly, including where each one is the right answer, in shared context tools for FDE and implementation teams.
Key terms
More definitions live in the customer onboarding glossary.
Shared context: The account's memory that a whole team and its AI agents can query, answering what was promised, what was decided, what's at risk, and what's next, with sources attached.
Team memory: A synonym for shared context, emphasizing that the memory belongs to the team rather than to any one member.
Project brain: The category artifact that stores shared context, a maintained, source-linked store of account facts.
Account brain: Tandem's product part, a project brain plus risk detection, Tandem agents (human-approved actions), and a 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.
Source-linked fact: A stored claim that carries a pointer to its origin (a call, thread, or session), so anyone can verify it without asking the person who recorded it.
Agent memory: Developer infrastructure that stores one AI agent's memory of one user, such as preferences and interaction history. Useful for personalization, distinct from team-level account memory.
Context engineering: The practice of deliberately designing what a language model sees on each call. Shared context applies the same discipline across a team and its agents rather than a single pipeline.