The problem

Every mainstream AI platform — ChatGPT, Claude.ai, Cursor — gives you an isolated session. There’s no way to hand someone a link and have them join the same live conversation the way you’d share a Google Doc. That’s a real gap once you’re building anything collaborative: a support session two teammates both need eyes on, or a multi-agent team working a task together. The same gap shows up again once you add multiple AI agents instead of multiple humans: agent frameworks default to one orchestrator issuing commands and workers reporting back, which recreates the exact bottleneck flat organizations avoid — the person (or agent) with the most relevant knowledge has to wait for permission to route it, and the orchestrator becomes a single point of failure. At company scale this is the same problem as siloed team wikis and knowledge that lives in one person’s head: nobody has designed the shared, addressable memory layer that lets a team of anything — human or agent — actually work off the same live state.

The approach

I started by pulling apart ten sources — conference talks, videos, and prior article bundles — on stateful agent infrastructure (Cloudflare Durable Objects as the primitive that makes a session addressable and shareable), peer-to-peer agent orchestration versus top-down delegation, agent-to-agent skill transfer, issue trackers as agent coordination layers, and ambient multi-party AI that has to detect who’s speaking and whether it was addressed. Each source got compressed into a standalone idea note with the concrete example intact — the four-agent Pi demo diagnosing a production bug with no orchestrator, the OpenAI Symphony team using Linear as a literal state machine for parallel coding agents, the JoinIn AI demo that has to tell a question from a side conversation.

Then I used that research to actually design a system: taking Open Brain, a local memory server I built for AI tools (Postgres + pgvector, semantic search over atomic notes), and extending it into shared memory for a team of software-building agents. The design that came out of that session is concrete: four memory layers (task-scoped working memory, private long-term memory per agent, project-level memory, and global institutional memory), a read-wide/write-narrow permission model so any agent can read broadly but only write within its role, a THINK-RECALL-PLAN-ACT-REFLECT loop each agent runs per work cycle, and a promotion pipeline that scores which working-memory notes are worth keeping long-term — using citation counts, decision finality, cross-agent reuse, and human endorsement, with a confidence threshold that routes high-confidence promotions automatically and routes everything uncertain to a human reviewer instead of guessing. Conflict detection between agents runs as a cheap embedding-similarity filter first, with an LLM call only on the pairs that actually look suspicious — keeping token cost down by design rather than by accident.

What I learned

The most useful moments in this were the ones where I pushed back on my own first design and it broke. My first pass had agents’ reads restricted by role — a developer agent couldn’t see architecture decisions — and that’s simply wrong: a developer needs to read requirements and architecture, it’s writes that need to be role-constrained, not reads. Same with agent communication: my first model routed everything through shared memory, but two agents converging on a design should just talk to each other directly and write the conclusion to memory afterward — memory is the record, not the medium. And novelty detection for promoting a thought to permanent memory turned out to be the one thing I couldn’t cleanly automate — duplicate detection via embedding similarity is a good filter but a bad final judge, so that step routes to a human instead of pretending a similarity score is a decision.

Where this could go

This hasn’t shipped as a running system yet — it’s design work grounded in a real, working piece of infrastructure (Open Brain) rather than a whitepaper, which is the point: every architectural choice was tested against “how would this actually work with agents writing and reading concurrently.” The natural next step is building the four-layer memory and the promotion pipeline on top of Open Brain and running it against a real multi-agent coding task. The bigger pattern generalizes past my own setup: any organization running multiple AI agents (or humans) against a shared body of work has this same problem — where does a decision live once it’s made, who’s allowed to see it, and who decides it’s worth keeping permanently versus letting it expire with the task. That’s the same governance question as a company’s knowledge base or a team wiki, just with agents as some of the authors, and it needs the same answer: broad read access, narrow write access, and a human in the loop wherever confidence is low.