The Agent Trio: How I Run Three AI Agents on One Shared Memory
Three agent planes, one shared memory, zero self-modification: the shape that keeps a multi-agent system debuggable as it grows.
Run three specialised agent planes, build (Claude Code), schedule and delivery (Hermes), execution and reach (OpenClaw), over one shared typed memory, and let nothing modify itself without human sign-off. The split keeps failures debuggable: where a job breaks tells you which plane to inspect.
The Agent Trio: Three Agents, One Memory
Most people who “run AI agents” run one mega-agent that schedules, executes, reaches the network, remembers, and notifies, and then can’t tell you why it broke. Or they run several agents that each keep their own context, so nothing one learns is available to the others.
I run three agent planes. They share one memory, and none of them can change itself without my sign-off. That shape, specialise the planes, share the memory, gate the changes, is the whole design. Here’s why each part earns its place.
The shape, in one line each
- Claude Code, the build / config plane. Where I design, code, configure, and decide, with a human in the loop.
- Hermes, the delivery / schedule plane. It owns the clock (cron) and the phone channel (Telegram). It’s how the system reaches me.
- OpenClaw, the execution / reach plane. Privileged shell, browser, secrets, and the network paths the others can’t take. It’s how the system reaches the world.
Underneath all three: one shared memory, a single store every plane reads and writes. Not three siloed contexts. One.
Claude Code = BUILD / CONFIG , design, code, approve (you in the loop)
Hermes = DELIVERY / SCHEDULE, cron + Telegram out
OpenClaw = EXECUTION / REACH , privileged exec, browser, secrets, network
└────────── one shared memory spans all three ──────────┘[YOUR TAKE] The origin: why three planes instead of one mega-agent? What was the specific mess (a tangle you couldn’t debug, an agent that forgot everything between runs) that pushed you to split them? Two or three sentences of the real story here, that’s what makes this yours.
Decision 1: one memory, three readers
The planes are specialised, but they are not strangers. Every one of them reads and writes the same store (memory_search over a shared database). A decision made while building in Claude Code is visible to Hermes when it schedules, and to OpenClaw when it executes.
This is the part most multi-agent setups get wrong. They give each agent its own memory, and then spend all their time passing context between agents by hand. Shared memory means the context is the substrate, no hand-off, no drift, no “which agent knew what.”
The cost: you have to be disciplined about what goes in. One shared memory with junk in it poisons all three planes at once. So the store is typed, segments, summaries, decisions, not a dumping ground.
Decision 2: nothing modifies itself
The second rule is stricter than it sounds: automation may propose changes, but it never applies them.
A daily job can analyse my sessions and say “here’s a new skill you should add” or “this agent definition has a gap.” It writes that as a proposal. It does not touch a single agent or skill definition. Nothing changes until I read the proposal and say yes, at which point Claude Code (the build plane) makes the actual change and commits it.
[YOUR TAKE] Why you hold this line so hard. A self-improving system that can rewrite its own agents sounds powerful, state plainly why you refuse to let it. (Auditability? A near-miss? The principle that a system you can’t predict is a system you can’t trust?) This is a strong, contrarian opinion, own it.
The boundary that makes it debuggable
The real payoff of the split shows up the moment something breaks. Take a daily digest job:
OpenClaw → reaches the source, fetches + reads the data (EXECUTION / REACH)
↓ hands the finished payload to
Hermes → fires on schedule, delivers to Telegram (DELIVERY / SCHEDULE)If the digest is late, it’s a Hermes problem, schedule or delivery. If the digest is empty, it’s an OpenClaw problem, fetch or reach. If the digest is wrong, it’s a build problem, I fix the logic in Claude Code. The boundary tells you where to look before you’ve opened a single log.
That is the entire argument for specialising the planes: separation of concerns you can debug six months later.
[YOUR TAKE] A real war story. The RSS digest that silently failed for days when one plane tried to do another’s job, what happened, what you saw (or didn’t), and how the boundary would have caught it faster. Concrete beats abstract; give the reader the actual failure.
When to reach for which
| You need to… | Plane |
|---|---|
| Design, code, configure, or decide | Claude Code |
| Run something on a schedule | Hermes |
| Send anything to my phone | Hermes (only) |
| Run a privileged command, browser task, or read a secret | OpenClaw |
| Reach a source behind a network the scheduler can’t | OpenClaw |
| Recall anything any plane has seen | shared memory (any plane) |
Building or deciding → Claude Code. Scheduling or announcing → Hermes. Doing or reaching → OpenClaw. Remembering → all three, one store.
The takeaway
The lesson isn’t “use these three tools.” It’s the shape:
- Specialise the planes so each does one job and a failure tells you where to look.
- Share one memory so context is the substrate, not a hand-off.
- Gate every change so nothing rewrites itself behind your back.
A mega-agent gives you power and no legibility. Isolated agents give you legibility and no shared context. Three specialised planes on one gated memory give you both, and that’s the only reason the system still makes sense to me months after I built it.
[YOUR TAKE] What you’d do differently, honestly. One or two things the design gets wrong or that you’d rebuild. This section earns more trust than the wins, don’t skip it.
Part of how I run a personal multi-agent system. The two execution planes get their own deep-dive in Hermes vs OpenClaw; the shared-memory layer in a separate post.