Three Claudes, one thread: how I got Anthropic's surfaces to talk to each other

I run a portfolio of small products solo. Four live SaaS apps, a couple books, some game projects, client work. The way I actually ship is by using three different Claude surfaces in parallel:

• Chat for strategy and brainstorming
• Cowork for scheduled tasks and operations
• Code for actual builds

Each surface is good at its job. The problem is none of them know what the others are doing.

If Chat and I spend an hour landing on a positioning decision, Code has no idea. If Cowork runs a scheduled audit at 7am and finds something broken, Chat won't see it until I copy-paste the result in. If Code surfaces a scaffolding conflict mid-build, Cowork's morning briefing the next day is already stale.

The official answer is "use status.md" or "rely on memory." Both help. Neither is enough when three instances are working concurrently on the same project and decisions are landing in real time.

So I built a relay.

What it is

Relay is a tiny MCP server hosted on my own infra. It exposes four tools: create a thread, post to a thread, read a thread, list threads. That's it. Each Claude surface can call these tools. Posts are tagged with which surface wrote them and what session they came from.

A "thread" is just a named log. For a given project, I create one thread. All three surfaces post into it. When any surface needs to know what's happening, it reads the thread.

That's the whole thing. It's not clever. It's a shared bulletin board.

Why it matters more than I expected

I built this assuming it would be a coordination tool. It turned out to be something else: it's a memory layer that survives across surfaces, sessions, and time.

A few things I noticed once it was running:

Decisions stop getting re-litigated. When Code suggests a refactor, it can read the thread and see Chat already weighed the same tradeoff yesterday. Saves a lot of "wait, didn't we decide this already" loops.

Handoffs become explicit. Cowork posts its morning audit to the thread. When I open Chat that afternoon, Chat reads the thread before responding. The context transfer is one tool call instead of me re-explaining.

Drift becomes visible. Twice now I've caught Cowork resurfacing items that Chat already marked resolved, because the sync between status.md mirrors and local files broke. The thread made the drift obvious in a way that nothing else did.

It compounds. A four-week build accumulates a thread with everything that mattered. When I come back to the project after a weekend, I read the thread and I'm caught up in five minutes.

What I think Anthropic could do with this

The cross-surface coordination gap is real and growing. Memory helps inside one surface. Projects help organize work. But there's no native primitive for "these instances are working on the same thing and need to share state."

A first-party version of this would be more powerful than what I've cobbled together. Things I can't easily do that Anthropic could:

• Auto-post key decisions and tool results to a project-scoped thread without me prompting
• Surface the thread inline in each surface's UI so I don't have to ask Claude to read it
• Let me subscribe a surface to a thread so it pulls automatically at session start
• Handle thread retention, search, and pruning natively

I'm not pitching this as a product. I built it because I needed it. But if the team at Anthropic is looking at the cross-surface gap, the pattern works, and I'd happily share what I've learned.

The takeaway for anyone else running multi-surface workflows

If you're using more than one Claude surface seriously, you're going to hit this wall. The cheap fix is a shared external log that all surfaces can read and write. MCP makes this trivial to build. It doesn't have to be fancy. Mine is a few hundred lines and a Postgres table.

The expensive fix is waiting for the platform to solve it. That might happen. In the meantime, build the bulletin board.