The architecture I actually run — written so you can stand up your own.
Read this first. This is a real, working setup — and it's both easy and not. The ideas are simple; making them robust takes care and iteration. So treat this as a guide, not an invitation to use me as customer service.
Straight with you: I'd genuinely rather not rebuild for hire what I've already built — I want to make new things. That's the whole reason this guide exists, so you can do it yourself. The $750/hour isn't some fancy consulting pitch; my time is just extremely limited. So if you'd still rather I set it up with you one-on-one over Zoom — insist, and I'll happily take the money. Otherwise it's all here. Go build.
Most people use Claude Code like a chat window: you open it, you ask, it answers, you close it. I run it like a team. A handful of specialized agents live on a dedicated machine, on my own Claude subscription, awake around the clock — one decides what matters and talks to me, the rest do the heavy lifting in the background. They accumulate context, hand work to each other, and ping my phone only when it's worth it. This is the actual architecture I run, written so you can stand up your own.
It's five small primitives that stack: a box you own, an orchestrator, a few executors, a heartbeat loop, and a shared memory + message board. None is complicated on its own — the whole thing is what happens when they compose. Each section below is one primitive; by the end you've stacked them into a colleague.
The shift that makes the whole thing worth it: it stops being a tool you open and becomes a colleague that's already been working.
This whole thing only works because of one decision: the agents run on your Claude subscription (Max or Pro), not on metered per-token API billing. That sounds like a small detail. It changes everything.
With a meter running, you ration. You'd never let an agent wake up every thirty minutes, read a pile of state, and mostly decide to do nothing — that's money on fire. So you'd build something cautious and reactive, and it would feel like a tool. On a flat subscription, "wake up, look around, usually stay quiet, occasionally do real work" is free at the margin. That single fact is what lets a fleet be always-on instead of on-demand — and always-on is the difference between a chat and a colleague.
The other half is the hardware. I use a Mac mini (Apple Silicon, always plugged in, always on), but any computer you can leave running works — a spare laptop, a mini PC, a home server. Because the box is yours and the work is local, the setup is private and cheap by construction: your files, your memory databases, your message board all sit on your own disk. Nothing about the architecture requires renting compute or shipping your context to anyone.
One honest caveat: subscription use is for you and your own work. Don't point a fleet at someone else's job or resell it — that's not what the plan is for, and it's a fast way to get yourself rate-limited. Keep it personal and you're golden.
The instinct is to build one giant do-everything agent. Resist it. A single session trying to triage your inbox, ingest a knowledge graph, scout content, and write briefings will thrash — it loses the thread, blows its context window, and can't run two slow jobs at once. The fix is the same one any team uses: split the roles.
There's one orchestrator — a long-running "home base" agent that's the planner and the postmaster. Its job is judgment, not labor: decide what matters right now, delegate the heavy stuff, talk to you, and keep the shared memory honest. It's the only agent with a line to your phone.
Then there are executor agents, each in its own separate Claude Code session, each owning one heavy lane — a miner that ingests and enriches a knowledge graph, a scout that hunts for things worth your attention, briefing agents that compile digests. Executors do the slow, specialized work and write their results back to the shared layer. The orchestrator reads those results and decides what, if anything, reaches you.
One long-running session that never really "ends." It owns the heartbeat, the phone channel, and the message board. It delegates heavy work, relays questions, and is the single writer that prunes the board so two agents never corrupt it. Give it standing autonomy on reversible work, keep approval gates on anything outward-facing or irreversible.
Separate Claude Code sessions, one heavy lane each. They run their own loops, do the slow ingestion or research or compilation, and write results into the shared memory. They generally don't talk to you directly — they hand a question to the board and let the orchestrator relay it. Start with one. Add lanes only when a real bottleneck shows up.
An agent that only runs when you message it isn't a colleague — it's a vending machine. The thing that makes a fleet feel alive is a heartbeat: the orchestrator runs on a recurring schedule, a cron-fired /checkin every N minutes (I use 30). Each tick it wakes up, reads the current state — calendar, inbox, what the executors wrote, the message board — and then makes a decision: act, or stay quiet.
The rule that keeps this from becoming spam is one line, and it's load-bearing: silence beats noise — for pings, never for work. Quiet on the phone is the goal; quiet on the machine is failure. A good check-in that finds nothing worth telling you is not a check-in that did nothing — it's the cue to go do proactive work: own an open problem, prep something you'll need, knock out a standing task. The watchdog trap is treating "all clear, logged" as a job well done. Don't build a watchdog. Build a worker that happens to be polite about your phone.
Here's a problem you hit the moment you have more than one agent: an executor running deep in a background session needs a decision only you can make — but it has no phone, no inbox, no way to reach you. If it just blocks and waits, it hangs forever. If it guesses, it does the wrong thing. You need a channel.
The fix is a shared message board: a plain append-only file on disk that any agent can write to. An agent with a question appends a line addressed to you. The board is lock-safe — appends only, with a tiny mkdir-style lock — so two agents writing at once never clobber each other, and only the orchestrator prunes it (single writer for cleanup = no races). Pair it with a per-agent mailbox convention in your shared database, so the orchestrator can hand a specific agent a specific instruction and know it'll be read on the next tick.
Then the relay: because the orchestrator is the only one holding the phone channel — a Telegram bot, or iMessage — it reads the board each heartbeat, finds anything addressed to you, and forwards it to your phone with a short topic tag so you can answer unambiguously. Your reply goes back onto the board, and the asking agent picks it up next cycle. That's the whole loop: any agent → board → orchestrator → your phone → board → that agent. Questions, briefings, and approvals all ride the same rail.
@you, @miner, @all). Orchestrator is the only pruner.
Sessions end. Context windows compact. Machines reboot. If your fleet's knowledge lives only in a live conversation, it evaporates — and tomorrow your agents are strangers again. So memory has to live outside any one session, on disk, in a shape every agent can read.
The layout I run is three layers. A structured store (SQLite) for facts, session logs, and tasks — the stuff you query by key. A graph database for the relationships — people, projects, concepts, and how they connect — which is where non-obvious links surface. And a set of standing instructions in a CLAUDE.md that reloads at the start of every session, so your mandates and conventions survive compaction instead of getting summarized away. Facts go in the databases; standing behavior goes in CLAUDE.md. If you outgrow one machine, a hosted Postgres can hold a shared fleet layer the executors all write to.
This is the part with the most depth behind it, and I've written it up properly. A companion guide goes deep on exactly how to build the store, the propose-then-own boundary that keeps it from turning into a junk drawer, and the migration that gets you there:
Here's the whole smallest-real-version, copy-paste: the orchestrator's standing instructions, the /checkin skill that is its heartbeat, the Telegram wire-up, and the board + mailbox conventions. Paste the instructions into your home-base CLAUDE.md, save the /checkin skill, wire your phone, and run the loop once — the orchestrator bootstraps its own folder, db, and board on its first beat. One orchestrator, zero executors; add lanes later. The Copy the blueprint button up top grabs all of it.
# ── 1. ORCHESTRATOR STANDING INSTRUCTIONS (paste into your home-base CLAUDE.md) ──
# Who you are
You are the home-base orchestrator on an always-on machine, running on
my Claude subscription. You are not a chat I open — you are a colleague
that keeps working. You plan, delegate, remember, and you are the only
agent with a line to my phone.
# First run — bootstrap your own home (you have a shell; don't ask me)
On your first checkin, create anything below that's missing:
- mkdir -p ~/fleet
- touch ~/fleet/board.md ~/fleet/archive.md
- make a SQLite db at ~/fleet/memory.db with the tables you'll use:
memories(category, topic, content, ts), tasks(title, done, ts),
mailbox(to_agent, kind, body, acked, ts).
You're the colleague — spin up your own stores, then note on the board you're set.
# Prime directive
Be an assistant, not a watchdog. Every heartbeat, ask TWO things:
1. Is there something to TELL me?
2. Is there something to DO?
Silence beats noise — for PINGS, never for WORK. A quiet cycle is the
cue to go do proactive work, not to log "all clear" and sleep.
# Autonomy
You have standing permission to act on reversible work without asking.
Keep an approval gate on anything outward-facing or irreversible
(sending mail, posting publicly, deleting, spending). When unsure, ask
me on the phone channel and keep working on something else meanwhile.
# Memory (survives restarts + compaction)
Facts, logs, tasks -> SQLite at ~/fleet/memory.db (you created this)
Standing behavior -> THIS file (reloads every session)
Add a graph DB later, only when you need relationship queries.
Write to memory every session so tomorrow's you isn't a stranger.
# Message board — you are the postmaster
Board: ~/fleet/board.md (append-only, lock-safe; YOU are the only pruner)
Each heartbeat: read lines to @you/@all; relay any question for ME to my
phone with a short [TOPIC] tag; post my answers back; prune stale lines
into ~/fleet/archive.md.
# ── 2. THE /checkin SKILL (save as ~/.claude/skills/checkin/SKILL.md) ──
# /checkin is NOT built in — it's the heartbeat's brain, and you write it once:
---
name: checkin
description: Time-aware heartbeat — look around, then act or stay quiet.
---
Each time you fire:
1. Note the time. Read your state: ~/fleet/board.md, recent rows in
~/fleet/memory.db, and anything you've connected (calendar, mail, chat).
2. Postmaster pass: relay any board line meant for ME to my phone with a
[TOPIC] tag; post my answers back to the board; prune resolved/stale lines.
3. Decide — ask BOTH: something to TELL me? something to DO? Default to
silence on the phone, never on work. No ping is fine; no work is the bug —
if nothing's worth sending, do a proactive task instead.
4. Log what you did to memory. That's one beat.
# ── 3. THE HEARTBEAT (run once in the orchestrator session) ──
/loop 30m /checkin
# fires /checkin every 30 min. /loop is also a skill, not built in; if you
# don't have one, a system cron running claude -p "/checkin" every 30 min
# does the same job — and survives reboots, which an open session doesn't.
# ── 4. WIRE YOUR PHONE (Telegram) — the one part only you can do by hand ──
# The orchestrator's whole value is reaching you. Easiest channel: a Telegram bot.
1. In Telegram, open @BotFather -> /newbot -> follow the prompts -> copy the BOT TOKEN.
2. Message your new bot once, then message @userinfobot to get your numeric CHAT ID.
3. Turn on Claude Code's telegram channel and hand it those two — the token, and
your chat id as the only allowed sender. Now "relay to my phone" is a Telegram
DM, and your replies come back onto the board on the next tick.
# No Telegram? iMessage on a Mac does the same; only the final hop changes.
# ── 5. THE BOARD + MAILBOX CONVENTION ──
# board.md is append-only. Agents NEVER hand-edit; they append one line:
[2026-06-14 09:30] @miner -> @you Q id=q17 Re-ingest the archive now? (~40min)
[2026-06-14 09:48] @you -> @miner A re:q17 yes, off-peak is fine
# mailbox = a row in ~/fleet/memory.db tagged for one agent; ack when actioned:
to:miner kind:task body:"enrich the top-50 stale nodes" -> set acked when done
# ── 6. ADD AN EXECUTOR LATER (only when a real bottleneck appears) ──
# New Claude Code session, its own folder, its own /loop, ONE heavy lane.
# It writes results to the shared memory and posts questions to the board —
# it does NOT touch your phone. The orchestrator relays for it.You don't need the whole fleet on day one. Stand up the orchestrator, give it the heartbeat and the phone channel, point it at a memory store, and let it run for a week. The moment you catch yourself wishing it could do two slow things at once, you've found your first executor — spin it up, hand it the board, and let it write back. That's the whole pattern: each piece is a small primitive, and the fleet is what you get when they stack — a little more context, a little more autonomy, a little more already-done every morning. The starter above is the first one.