Shared AI context: one folder as a team's working memory
The paid media team I lead works across a roster of accounts. Until recently, each account's context lived in whoever last touched it. The replacement: one synced folder with a fixed structure and two plain-text files per client, read by people and AI agents at the start of a session and written at the end.
Context lived in people, and people are not available on demand
Handover was a conversation: which budget change applied to which account, why a campaign was paused in March, which of the four conversion actions matters. It works while the person is at their desk and fails every other time, worst on accounts untouched for a fortnight.
AI agents made the gap sharper. An agent opening an account knows nothing. Given nothing, it asks for everything or fills the space with assumptions. The problem was never the model. The context lived in someone's head and in files nobody else could find.
The change: stop treating context as something a person carries; make it 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; 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 reaches the team within about five minutes; anything added in Drive comes back down the same way. Syncthing keeps a second live copy on a mini PC as 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, usefully: an external folder can be pulled into a workspace 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.
- Client folders never get renamed. 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 altogether. They belong in version control, and 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, the direction that fails safely.
None of this is clever. It is 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, so the shape is never a decision.
CLAUDE.md
Stable facts about the account: who is who on the client side, the internal owner, the account identifiers, the measurement rules, and how work is reported back.
SESSION.md
A dated log, appended to and never rewritten. Each entry records the session's focus, what was done, what was decided, and which files were touched.
deliverables/
Client-facing final output. 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 its raw material. Exports, feeds and build sheets sit in data; anything written on top of them sits in reports.
meetings/
Call notes, transcripts and preparation. Meeting output lands here as a file rather than a calendar invite or somebody's notebook.
archive/
Superseded versions. Excluded from the Drive sync, so old drafts stay out of the shared view without being thrown away.
File names follow one pattern: client, subject, month. A folder sorts cleanly and a file stays identifiable once separated from its directory.
Layer three: read at the start, written at the end
The structure on its own is just tidy filing. What 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 latest SESSION.md entry for what happened last time and what was left open. Enough to resume without anyone explaining anything.
The work then happens against live data, not 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 read the account identifiers can go straight to the live numbers.
At the end a dedicated skill adds any newly confirmed facts to CLAUDE.md and 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. It does nothing for a colleague asking in Slack on a Tuesday evening, where most questions arrive.
The layer being built now closes that. Each client gets a GitHub repository holding the same two memory files, and Claude Tag gets access to it from the client's Slack channel.
Access is granted per channel, not per person. A channel maps to one client, so everyone in it works against the same context and nobody picks the account; the channel already did.
Sessions run in a sandbox discarded afterwards, so anything worth keeping is pushed back to the repository during the session. That suits this setup: the two memory files were already the thing worth keeping.
It is in progress, not finished, and it introduces a second copy of the memory files alongside the synced folder. Two copies of the same facts is where I expect trouble.
The same two files on the sales side
Prospects follow the same pattern from their own template: the two memory files, plus a few folders for the stages a prospect moves through. A skill populates the folder from the initial call; the working notes exist as structured files from first contact instead of being written up later.
The advantage shows when 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; that part is a habit. Where it lapses, the next session inherits whatever was true a fortnight ago.
The memory file records what was confirmed, not what is currently true. An account identifier that changed unnoticed stays wrong until someone checks it against the platform, and the file gives no sign it has aged.
The sync is a sync, not document management. It has no version history worth the name beyond the archive convention, and it assumes a small team who understand the rules. It would not survive thirty people without something more formal underneath.
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 markdown with no integration work, a person opens it in any editor, and it syncs as an ordinary file. A wiki would need an API and a permission model before anything could use it, for the same content.
What stops the context files going stale?
The end-of-session skill, and nothing else. It runs when 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: a consistent structure with a written log. The agents benefit more, because they have no other way of knowing what happened last week.