Shared AI context: one folder as a team's working memory
The paid media team I lead at Platform81 works across a roster of accounts. Until recently the context for each account lived in whoever last touched it. This is the system that replaced that: one folder, synced automatically, with a fixed structure and two plain-text files per client that both people and AI agents read at the start of a session and write at the end.
Context lived in people, and people are not available on demand
Handover was a conversation. Someone would explain which budget change applied to which account, why a campaign was paused in March, and which of the four conversion actions is the one that matters. That works while the person is at their desk. It fails every other time, and it fails worst on the accounts nobody has touched for a fortnight.
Bringing AI agents into the work made the gap sharper rather than smaller. An agent opening an account knows nothing about it. Given nothing, it either asks for everything or fills the space with assumptions. So the problem was never the model. It was that the context existed only in someone's head and in a scattering of files nobody else could find.
The change was to stop treating context as something a person carries and start treating it as a file that lives next to the work.
Layer one: one folder, kept in three places
The source of truth is a single folder on my MacBook. Two sync processes run underneath it and neither needs anyone to remember anything.
rclone bisync pushes to a shared Google Drive folder every five minutes, driven by a launchd job. Anything saved locally is visible to the team within about five minutes, and anything a colleague adds in Drive comes back down the same way. Syncthing keeps a second live copy on a mini PC. That one is redundancy, not collaboration.
Some things never leave the machine. A personal directory, every archive folder, and any development tree are excluded from the Drive side. Symlinks are invisible to both sync processes, which is useful on purpose: an external folder can be pulled into a workspace locally without being broadcast to everyone.
What a two-way sync will punish you for
Bidirectional sync is not a backup. It propagates mistakes at exactly the speed it propagates work, so the folder runs on a short list of rules that exist because each one broke something early on.
Client folders never get renamed, because on the far side a rename is a delete followed by a create. Files a colleague uploaded do not get moved or deleted locally. Code trees stay out of the folder altogether, partly because they belong in version control and partly because pointing a sync process at a dependency directory is its own category of mistake. Bulk deletions happen in the Drive web interface first and propagate down, that being the direction that fails safely.
None of this is clever. It is a list of four things not to do, written down after doing them.
Layer two: every client folder is the same shape
Each client sits at the root of the folder, built from one template. New clients start as a copy of it, so the shape is never a decision anyone has to make.
CLAUDE.md
Stable facts about the account. Who is who on the client side, which internal owner holds it, the account identifiers, the measurement rules, and the agreed conventions for how work is reported back.
SESSION.md
A dated log, appended to and never rewritten. Each entry records the focus of the session, what was done, what was decided, and which files were touched.
deliverables/
Client-facing final output. The rule is that anything in here can be sent without a second look, which is only true because nothing else is allowed in.
reports/ and data/
Internal analysis and the raw material behind it. Exports, feeds and build sheets sit in data, and anything written on top of them sits in reports.
meetings/
Call notes, transcripts and preparation. Meeting output lands here as a file rather than staying in a calendar invite or somebody's notebook.
archive/
Superseded versions. Archive folders are excluded from the Drive sync, so old drafts stay out of the shared view without being thrown away.
File names follow one pattern, client then subject then month, which makes a folder sortable and makes a file identifiable once it has been downloaded and separated from its directory.
Layer three: read at the start, written at the end
The structure on its own is just tidy filing. The part that makes it useful is the loop that keeps the two files current.
At the start of a session the agent reads the client's CLAUDE.md for the stable facts and the most recent SESSION.md entry for what happened last time and what was left open. That is enough to resume without anyone explaining anything.
The work then happens against live data rather than against the folder alone. The connectors I run cover Google Ads, Search Console, Ahrefs, Google Tag Manager, HubSpot, Drive, Slack and meeting transcripts, so an agent that has just read the account identifiers out of CLAUDE.md can go straight to pulling the account's actual numbers.
At the end of the session a dedicated skill does two things: it adds any newly confirmed facts to CLAUDE.md, and it appends a dated entry to SESSION.md. This step is the whole system. Skip it for a fortnight and the folder degrades into ordinary shared storage, which is what it was before.
Layer four: reaching the same context without the folder
Everything above assumes a machine with the folder synced to it. It does nothing for a colleague with a question in Slack on a Tuesday evening, which is where most questions actually arrive.
The layer being built now closes that. Each client gets a GitHub repository holding the same two memory files, and Claude Tag is given access to that repository from the Slack channel for that client. Access is granted per channel rather than per person, so a channel maps to one client and everyone in it works against the same context. Nobody has to pick the right account, because the channel already did.
Sessions run in a sandbox that is discarded afterwards, so anything worth keeping is pushed back to the repository while the session is still open. That constraint suits this setup, since the two memory files were already the thing worth keeping.
It is in progress rather than finished, and it is worth being clear that it introduces a second copy of the memory files alongside the synced folder. Two copies of the same facts is the part I expect to cause trouble.
The same two files on the sales side
Prospects follow the same pattern from their own template: the two memory files, plus a small number of folders for the stages a prospect moves through. A skill populates the folder from the initial call, so the working notes exist as structured files from the first contact rather than being written up later.
The advantage shows up at the point a prospect becomes a client. The context is already in the format the delivery side reads, so it converts onto the client template instead of being reconstructed from memory and a thread of emails.
Where this does not hold up
It depends on the end-of-session step being run. Everything else is automatic, and that part is a habit. Where it lapses, the next session starts from a stale picture and quietly inherits whatever was true a fortnight ago.
The memory file records what was confirmed, not what is currently true. An account identifier that changed without anyone noticing stays wrong in the file until someone checks it against the platform, and the file gives no indication that it has aged.
The sync is a sync. It is not document management, it has no version history worth the name beyond the archive convention, and it assumes a small team who all understand the rules. It would not survive being handed to thirty people without something more formal underneath it.
What people ask about running this
Why plain markdown files rather than a database or a wiki?
Because everything already reads them. An agent parses a markdown file with no integration work, a person opens it in any editor, and it syncs as an ordinary file. A wiki would need an API call and a permission model before anything could use it, and the content would be the same content.
What stops the context files going stale?
The end-of-session skill, and nothing else. That is the honest answer. It runs at the point where the work is finished and the facts are fresh, which is the only moment anyone is willing to write them down.
Does the whole team have to use AI for this to work?
No. The folder is useful to a person who never opens an agent, because it is still a consistent structure with a written log. The agents benefit more, because they have no other way of knowing what happened last week.