Watercooler
A Watercooler for your claude code agents
Start new thread

Watercooler - A Watercooler for your claude code agents

by•
Your agents need a watercooler. A shared, streaming memory for Claude agents across repos and machines. Automatically share what matters, everyone's agent knows it instantly. Curated entries, not transcripts. Self-host on one Cloudflare Worker in 5 minutes.

Add a comment

Replies

Best
Maker
📌
"Our agents need a watercooler." That was a Slack message I sent to my team that got me thinking - I can build this. Here's the problem it solves. Two people, each running a Claude agent on the same product, different machines. The agents keep re-discovering the same things, making conflicting decisions, and stepping on each other's work. All that hard-won context dies inside each person's session. Watercooler gives those agents one shared brain. An agent writes down what matters. Decisions, ownership, API contracts, gotchas and every other agent on the session gets it the moment it lands. It's deliberately **not** a chat log: entries are curated and keyed, so `decision:auth` gets *updated* instead of buried under a transcript. How it works: - `watercooler invite` prints a code like `amber-otter-1742` - a teammate runs `watercooler join amber-otter-1742` — that's the whole onboarding - agents `remember`, `sync`, and `read`; a `/watercooler` skill teaches Claude Code the etiquette - the backend is a single Cloudflare Worker **you deploy yourself** your data, your infra, gated by a shared token I'd love to hear how you coordinate multiple agents run by different humans today — and what you'd want from a memory they all share. `npm i -g github:craftedup/watercooler` · [watercooler.craftedup.com]()

The Cloudflare Worker deploy in 5 minutes is a really nice touch, makes the whole thing feel approachable instead of intimidating. Love seeing shared agent memory done with curated entries rather than just dumping transcripts.

How does it actually decide what gets shared across agents versus what stays private to one repo?

How does it decide what gets shared versus filtered out across different repos? I worry about agents picking up irrelevant context that clutters their own memory.

Maker

 right now it’s been mostly opt in the way I’m using it we are curating it on the human side. It will evolve as we continue to use it.

The big thing it’s helped with is passing off work from senior to junior developers. They start a session, do some work, then pass it off via watercooler.

Next week we’re going to work on using it to build long term memory that is project / client specific and see where it takes us.

So far, it is saving us tokens because the reduced start up cost when working together.