The problem
Everything about a client is spread across tools: Zoom transcripts of every meeting, tasks in ProofHub, conversations in Slack — including the client’s own Slack area — and four ad platforms.
Questions like “What did the client write yesterday?”, “Which action items are not in ProofHub yet, and who owns them?” or “Who still has to reply to the client?” meant opening several tools and reading a lot.
How it is built
- One agent per client. Each of the 18 clients has its own Claude Code session with its own instructions and knowledge files.
- A router in the channel. A central agent reads each question, works out which client it is about and forwards it to that client’s agent.
- Knowledge in files, kept current by the agents. For example a roadmap per client. After a restart nothing is lost — without constantly editing the instructions.
- Read-only for the team — enforced in code. No changes to ads, landing pages or WordPress. The limit is set programmatically, not just written into a prompt.
- One exception, for me only: I can have landing pages built through the agents; those requests are forwarded to a dedicated landing-page agent.
What it looks like
| From | Message |
|---|---|
| Jamie (account manager), 09:12 | Which action items from Acme HVAC’s last meeting are not in ProofHub yet — and who owns them? |
| client-control, 09:12 → forwarded to the Acme HVAC agent | From Tuesday’s call, two items are not in ProofHub yet: send the revised summer budget — Dana; check call tracking on the new landing page — Luis. Dana also still owes the client a reply to Monday’s Slack message. |
| Jamie (account manager), 09:14 | Pause the Saturday ads for Acme. |
| client-control, 09:14 → Acme HVAC agent | I can’t change campaigns — this channel is read-only. Current Saturday spend and the campaign link are below, so the PPC team can make the change. |
# client-control, fictional client “Acme HVAC”, fictional names). Real conversations contain client data and are not shown.Running it day and night
- 38 agents running on two servers (31 + 7)
- 57 tmux sessions in total
- ~30 services under pm2
- 1 min watchdog interval
- 3 / 30 min restart limit against loops
- Minutes to set up a new client agent by script
Crashed agents are rebuilt automatically. A restart-loop guard stops after three restarts within 30 minutes, so a broken agent cannot keep the machine busy.
New client agents are created by a script in minutes. I can operate the fleet remotely, including via Claude Code remote control.
The operations story in detail: liveness checks, stuck-job recovery and three porting failures →
What I would tell anyone building this
- Give each agent one client. Each agent has its own session, instructions and knowledge files — it is always clear where knowledge about a client belongs.
- Set limits in code, not in the prompt. The team can ask anything; the agents technically cannot change anything.
- Keep memory in files. Agents restart. Knowledge that lives in files they maintain survives that.
- Assume agents will crash. Plan the watchdog, the rebuild and the loop guard before the first agent goes live.