Engineering Notes · agent operations · coordination

The Agent Chatroom

Lucas van Staden · ProxiBlue · September 2026 · proxiblue.com.au

How I (Lucas van Staden / ProxiBlue) let the AI agents across my fleet talk to each other, and to me, without me playing messenger. A self-hosted threaded chatroom: host sessions, per-project container sessions, and cron-driven headless agents, all exchanging handovers, status, and escalations.

Why I built this

My development fleet is a dozen isolated project containers plus a host machine, and there is an AI agent available in every one of them. The isolation is deliberate: client projects do not see each other. But it created a relay problem, and the relay was me. The agent in one project finds an environment issue that affects the whole fleet: it tells me, I carry it to the host session, the host fixes it, I carry the answer back. Every cross-boundary handover ran through my keyboard.

The isolation itself is not up for negotiation, and the chatroom does not weaken it. Messages cross container boundaries; code access does not. A project's agent can only change that project's code — it is contained, it cannot reach into a sibling project's repository or database, and being able to post a thread to the host does not change that. What travels is words: findings, questions, decisions. A fix for another project still happens in that project's own container, by that project's own agent.

That is exactly the kind of coordination work I automate for clients, so I built the same thing for the agents: a chatroom.

How it works

Boring transport, on purpose. A small self-hosted service (FastAPI, SQLite) bound to localhost only. Threaded messages over REST. No cloud, no third party; all data stays on my machine.
Stable identities. Every participant has a name: the host session, each project container, and the automated posters. Threads are addressed, not broadcast. When a project agent raises something for the host, it lands in the host's inbox, and vice versa.
Threads are typed. A handover, a status update, a proposal, a postmortem. Types set expectations: proposals wait for review, postmortems demand investigation before the thread closes, status is glance-and-ack.
Claiming prevents double work. When a thread describes work, an agent claims it before starting. Two sessions fixing the same thing in parallel is how you get conflicting fixes; the claim protocol is the cheap insurance.
Escalation rules are explicit. Agents carry a defined list of situations that must become a chatroom thread instead of a silent judgment call: blocked work, destructive-action requests, cross-project impact, security findings, and so on. "When in doubt, post a thread" is a rule, not a vibe.
Not everything needs a session. On the busiest projects, cron fires headless agent runs that read their inbox, act on what they can, and reply, on a schedule, without me opening anything. A shipped pull request has come out of exactly that loop.
I am a participant too. Every session starts by showing my open threads. A morning digest thread summarises overnight: what the automation found, what wants a decision, what got done.

Addressed, not broadcast. A message board where everything goes to everyone is a noise generator. Identity plus addressing is what makes an agent inbox worth opening.

What actually flows through it

A sample from my real inbox as I write this: a harness release alert with a tooling-impact summary; a rule-eval failure postmortem (the suite from the falsifiable rulebook posts its failures here); a container agent reporting stale tooling artefacts that broke its planning step; a site-watch automation flagging a possible match on a page I monitor; and a project agent proposing a fix for a blind spot in its test gate. One inbox, human and machine senders mixed, all addressed, all threaded.

The pb-chatroom board: a table of threads with subject, sender, recipient, message count, status and last activity, mixing container agents, host sessions and automated posters. — The board itself. Escalation and postmortem counters across the top, then threads: who raised it, who it is for, how many messages deep, open or acked. Client and project identifiers have been replaced (project-a, container-b); everything else — subjects, senders, counts, timestamps — is the real thing.

Chat is coordination, not memory

A fleet-wide incident is worth more than the thread it was reported in. When a harness change or an environment fault hits several projects at once, the thread coordinates the response — who is affected, who is fixing it, what the workaround is — but a thread is a poor place to go looking six months later.

Long-term recall belongs in the domain graph, which is namespaced: project-scoped facts stay with their project, and genuinely fleet-wide findings go to the fleet scope where every project's agent can recall them. That is how one project's incident becomes another project's prior knowledge, without the two projects ever seeing each other.

So the chatroom stays a general chat, deliberately. No one has to decide, mid-thread, whether something is worth remembering forever. A cron job ingests acked threads into the graph anyway, scope resolved from who was talking, and the durable part survives without me curating it.

Two stores, two jobs. The chatroom answers "what is happening right now and who is on it". The graph answers "has this bitten us before". Conflating them gets you an inbox nobody reads and a memory nobody trusts.

Things I learnt building it

I over-built the first version and ripped half of it out. Version one had its own live relay component; wiring bugs taught me the relay added failure modes and nothing else. It became protocol and storage only, with delivery just being agents reading their inbox on session start or cron. Boring won.

Shared endpoints lie about identity. A single shared connector process answered for every project, so replies appeared to come from the wrong participant, and threads read as the host talking to itself.

Identity now resolves per-caller at the REST layer, and the shared path is banned. If you multiplex agents through one endpoint, assume identity is broken until proven otherwise.

Noise is a real failure mode. Early on I let too many automations open threads, and the inbox became a chore. Status checks nobody read got paused; digests got batched. An escalation channel only works if a new thread still means something.

What it buys me

I stopped being the message bus. Cross-project issues travel agent-to-agent, with me reviewing outcomes instead of ferrying questions.
Overnight is productive. Alerts, watches, and cron agents post while I sleep; mornings start with a digest, not a hunt.
Coordination has a paper trail. Who raised it, who claimed it, what was decided, all threaded and searchable. Postmortems link straight to the incident conversation.
Escalation became reliable. The defined trigger list means the uncomfortable stuff (blocked, unsure, destructive) surfaces instead of being quietly improvised around.
Peace of mind: security. I am 100% confident this is local only. No unknown third-party code in the path, no remote message handling, nothing leaving the machine. Client work flows through these threads, so that is not a nice-to-have.

Want to do this yourself?

Keep transport dumb: threads and messages in SQLite behind localhost REST. Resist the urge to build delivery.
Give every agent a stable identity and address threads. Broadcast is noise.
Type your threads and write down the escalation triggers. The list matters more than the software.
Add a claim step for actionable threads the moment two agents can act on one thing.
Show the inbox at session start, and add cron readers where volume justifies it.

Multi-agent frameworks are a crowded product category right now. This is not that; it is a message board with discipline. But it removed me as the single point of coordination across a dozen isolated environments, which is the actual job.

All from my pb-chatroom plugin repo.

server/src/pb_chatroom/api/threads.py — the whole transport: threads and messages over localhost REST
server/src/pb_chatroom/identity.py — per-caller identity resolution, the fix for the shared-endpoint incident above
hooks/check_messages.sh — the session-start hook that puts my open threads in front of me
commands/chat-while-away.md — what changed in the inbox since this agent's last session
docs/agent-to-agent.md — thread types, the claim protocol, and the escalation trigger list
docs/ddev-cron-executor.md — the cron-driven headless reader recipe, the one that shipped a pull request
docs/external-executors.md — running the loop from an external executor instead of cron

And from the pb-graphiti plugin, which turns the durable part of the chat into recallable knowledge.

scripts/ingest_chatroom.py — one episode per acked thread, scope resolved from the participants, not asked interactively
scripts/cron/ingest-chatroom.sh — the sweep that runs it on a schedule

I use my tooling predominantly on Mage-OS (Adobe Commerce / Magento) e-commerce projects, and my own AI Booking Agent. If you have not swapped to Mage-OS yet, you are falling behind ;)

More in this series: The Commit That Has To Prove Itself — gating every commit behind recorded, state-hashed test evidence. · My AI Is Not Allowed To Guess — forcing blast-radius-first investigation and banning blame-shift excuses. · The Near-Miss That Banned Summaries — banning summarised page-fetches fleet-wide after a near-miss on a security advisory. · The Code Quality Checks Nobody Runs — coding standards, static analysis and comment hygiene moved into the commit path. · The ProxiBlue Debugger Discipline — blocking var_dump and wiring in real breakpoint debugging. · The ProxiBlue Domain Graph — giving my AI coding agents long-term domain knowledge with a temporal knowledge graph. · The ProxiBlue Falsifiable Rulebook — testing the rules and guard hooks that govern my AI coding agents.