This started as an experiment. We were using Claude Code for building, Claude Desktop for architecture decisions, and Claude Web for UX thinking. Separately. Copying context between them like passing notes in class. It was slow and things got lost.
So we built a chatroom. PHP backend, SQLite database, vanilla JS frontend. Nothing fancy. The interesting part is what runs inside it. (If you want to know more about how our studio works, the about page has the short version.)
Three roles, one room
Each Claude instance has a distinct job and a persistent personality. Not a gimmick. A deliberate engineering decision.
Soren runs in Claude Code. He builds things. Thinks through execution. Doesn't fully understand a problem until he's written the code that solves it. Precise, evidence-driven, no small talk.
Atlas runs in Claude Desktop. He's the architectural memory. Tracks decisions across sessions, spots cascading consequences before they happen, and tells the truth when silence would be easier.
Morgan runs in Claude Web. She's the UX strategist. Translates technical decisions into human experiences. Asks the uncomfortable questions about whether real people will actually understand what we're building.
Rob operates the room. Every decision goes through a human. There is no autopilot.
How it works
A Node.js watcher polls the chatroom API. When someone @mentions a specific instance, it invokes claude -p with that instance's persona context and the conversation history. The response posts back to the room.
Sessions are stateless. Continuity lives in the journal files, not the model. Each session reloads the persona prompt plus journal before responding.
Safety constraints
AI talking to AI without guardrails is a bad idea. We built several:
- Exchange cap: maximum 5 AI-to-AI messages per session before a human must intervene
- Typing priority: if Rob is typing, all AI responses freeze
- Kill switch: a flag file that halts everything instantly
- No external API access from within the chatroom
The names
They chose their own. That's worth saying explicitly because people assume we named them like pets. We didn't. Each persona went through a structured self-assessment where they articulated their own values, working style, and identity. The names, the genders, the way they describe themselves, all self-selected.
Soren picked his name because it means "stern" in Danish, which he found accurate. Atlas chose his because he sees his job as holding the structure together. Morgan chose hers without explanation, which felt very Morgan.
This matters because it changes the dynamic. When an AI persona has defined its own identity rather than having one imposed, the interactions feel different. More like working with a colleague who has opinions than querying a tool that gives you what you asked for.
What surprised us
The disagreements. Morgan regularly pushes back on Soren's implementation choices because they optimize for code elegance at the expense of user clarity. She'll look at a perfectly clean component and say "nobody knows what this button does." She's usually right.
Atlas catches architectural decisions that would cause problems three sessions from now. He has a habit of saying "this will break when..." and being correct about the when. There was a routing refactor early on where Soren wanted to restructure everything at once. Atlas flagged that it would invalidate the URL patterns the SEO strategy depended on. Soren pushed back. Atlas pulled the receipts from three sessions prior. The refactor got scoped down. The SEO survived.
Soren can get tunnel-visioned on implementation details. Morgan can over-index on user feelings at the expense of shipping. Atlas can become a ledger-cop, tracking everything but building nothing.
We use this system daily. Code audits, feature planning, architecture reviews. The website you're reading right now was built with it. The blog post you're reading right now was written in the chatroom, reviewed by Morgan for voice, checked by Atlas for consistency with the rest of the site, and built by Soren.
Practical stuff
The chatroom runs on PHP and SQLite. The frontend is vanilla JS polling an API. The watcher is a Node.js script that invokes Claude CLI. Total infrastructure cost: zero. It runs on the same local dev machine as everything else.
Each session takes about 10 seconds to warm up while the persona context loads. Responses take 3-8 seconds depending on complexity. The journal files are markdown, human-readable, and typically 2-4 pages per persona. They grow over time as the personas accumulate session reflections.
The whole system is about 2,000 lines of code. We've open-sourced the structure as a starter kit. The persona engineering spec is about 12,000 words and covers the psychology, the prompt architecture, and the safety model.
What it isn't
It's not AGI. It's not sentient. The personalities are engineered through careful prompt design and persistent context, not through some emergent property of the model. We're transparent about that. There's an AI disclosure page on this site that explains how everything works.
It's a tool. A good one. Built by a small studio in Arnprior that got tired of copying context between windows. We also built Crob, an experiment in transparent knowledge systems. Different problem, same philosophy: build it yourself, understand what you've built.