How to share context between your team's AI agents
The practical options are pasting context by hand, committing it to a git repo, putting it behind an MCP server, or syncing a shared folder to every machine. Pasting doesn't survive the session, a repo only reaches people who use git, and an MCP server means one more service to run. A synced folder is the only one where the files stay local, so every agent reads them without an integration.
Every team that adopts AI agents hits the same wall about a month in. One person's agent knows the pricing rationale, another's knows the migration plan, and neither knows what the other knows. The context exists — it's just trapped in whoever's session produced it.
Why does context stay stuck in one person's session?
Because agent memory defaults to being local and private. Claude Code reads CLAUDE.md from the working directory. Cursor reads its rules file. Codex reads AGENTS.md. Each one is a file on one laptop, and nothing moves it anywhere.
That's a reasonable default — your notes are yours — but it means the useful byproduct of every session (the summary, the decision, the research) lands in a directory nobody else can see. The knowledge was created. It just wasn't shared.
What are the actual options?
Paste it. Copy the relevant context into the next session. It works, it costs nothing, and it survives exactly as long as the conversation does. Fine for one person on one project; unworkable the moment two people need the same thing.
Commit it to a repo. Put the markdown in git next to the code, and every engineer's agent has it. This is the right answer when the context is about the code. It stops working when the people who own the context — sales, support, the founder — don't use git. A workflow that requires a pull request excludes most of the company from the knowledge base.
Put it behind an MCP server. Give the agent a tool that queries a shared store. This is genuinely the right shape when the data lives somewhere an agent can't read directly: a database, a CRM, a ticket tracker. For markdown files it's a lot of machinery — a service to run, auth to configure, a round trip on every read, and nothing works offline.
Sync a folder. Keep the context as files in one folder, and keep that folder identical on every teammate's machine. Every agent already reads files from disk, so nothing needs an integration: the agent doesn't know or care that the folder is shared.
What does a shared folder actually buy you?
The agent-facing part is that reads are free. No tool call, no network hop, no permissions dance — the files are simply there, the way CLAUDE.md is there. An agent that can read a folder can also write to it, so the summary your agent produced at 2pm is on your colleague's disk before their next session starts.
The human-facing part matters just as much. Non-engineers can open the folder in Finder, drop in a PDF, and edit a document, and the same content reaches every agent on the team. That's the difference between a knowledge base the whole company maintains and one three engineers maintain.
The part people underestimate: versioning. Shared context rots. Six months in, the question is never "what does this document say" but "is this still true, and who changed it." Per-file history and attribution turn a stale wiki into something you can audit.
What's the catch?
Sync is a real distributed-systems problem, and anyone who tells you otherwise hasn't run it in production. Two people edit the same file offline; both come back online. You want to know exactly what your tool does there — keep both versions, or silently pick one. Ask before you adopt.
The second catch is scope. A folder that syncs everything eventually syncs something that shouldn't leave a laptop. Whatever you use should let you sync part of a folder, not just all of it.
BearDrive is our answer to this: mount a folder, and it stays in sync across every device and teammate, with per-file history and public share links when you want them. It's open source, and it's what the rest of this blog is mostly about.
Questions
- Can two AI agents share the same memory?
- Yes, if the memory is files rather than a vendor's internal store. Every major coding agent reads plain files from the working directory, so a folder that syncs to each machine gives Claude Code, Codex, and Cursor the same context with no integration between them.
- Do I need an MCP server to give an agent shared context?
- No. MCP is the right answer when the data lives in a system the agent can't reach — a database, a ticket tracker, an API. For markdown and documents, files on disk are simpler, work offline, and need no server running.
- Where should a team's agent memory live?
- In one folder per project that every teammate has locally, versioned so you can see who changed what. Keep it out of the code repo if non-engineers need to write to it, since a git workflow excludes most of a company.