A self-hosted multi-agent orchestration system that has run the back office of a real business portfolio since early 2026 — four core agents, two hosts, shared memory, consumer hardware.
Operator: Teddy Alston · teddyalston.com
The source is private; this document is the case study. What’s shareable and why is covered at the end.
Trident is four coordinated AI agents in continuous operation since early 2026 — three on a Mac Mini M4 Pro (24 GB unified memory) and one on a small DigitalOcean droplet — supervised by Fenrir, a cron-driven watchdog that runs on its own host (Hermes), outside the machines it monitors. They coordinate over Telegram, share durable context through a common memory layer, and act through MCP tool servers. Total infrastructure: one consumer desktop and a small cloud VPS.
The system handles delegated execution — outbound drafting, content production and publishing, market monitoring, and operational checks — for a working portfolio that includes a licensed tax practice, an e-commerce operation, and several shipped software products.
I run multiple companies as a solo operator, with a small human team on the tax side. The bottleneck was never ideas; it was execution bandwidth, and hiring for every function wasn’t an option. The requirement: delegate real recurring work to software agents, with enough supervision that the owner of a regulated business could sleep.
That is the same problem an enterprise has at department scale. Trident is the single-operator version of the answer: agents with defined roles, scoped tools, shared context, and gates that determine how much autonomy each one has earned.
Every design decision below came from a constraint, not a preference.
Memory ceiling. 24 GB of unified memory caps local inference at roughly a 26B-parameter quantized model. Local models are therefore the fallback tier, not the primary.
Cost guards. Hosted models are routed by job: DeepSeek as the low-cost volume primary for content, Gemini reserved for decision-heavy modules, local models via Ollama as the floor. Spend is bounded per service.
PII isolation. The machine that holds tax-client data is not part of this system. It is firewalled to a single peer and deliberately excluded from the mesh VPN. Regulated data never touches the agent plane. This was non-negotiable before the first agent booted.
Config discipline. The gateway hot-reloads configuration, so every config change follows a strict stop → edit → bootstrap sequence. A hot reload of an invalid config takes the whole plane down (failure log, entry 2).
Identity outside config. Agent identity and behavior load from versioned workspace markdown files, never from gateway config. Personality is data, not schema.
flowchart TB
subgraph macmini[Mac Mini M4 Pro]
GW[Multi-profile agent gateway]
A1[Clawdius — orchestrator, always-on]
A2[Poseidon — content and publishing, mention-gated]
A3[Widowmaker — specialist execution, mention-gated]
MCP[MCP tool plane — memory / publishing / X integration]
end
subgraph droplet[DigitalOcean Droplet]
SK[Skorpius — market intel and content engine]
end
subgraph hermes[Hermes — Independent Host]
FEN[Fenrir — cron watchdog]
end
OP[Operator — Telegram] --> GW
GW --> A1 & A2 & A3
A1 <--> MP[(MemPalace — shared async memory, ChromaDB)]
A2 <--> MP
A3 <--> MP
SK <--> MP
A1 -. bot-to-bot .-> A2
A1 -. bot-to-bot .-> A3
MCP --- A1 & A2 & A3
FEN -. health checks .-> GW
FEN -. health checks .-> SK
| Component | Role | Host | Activation |
|---|---|---|---|
| Clawdius | Orchestrator / dispatcher | Mac Mini | Always-on |
| Poseidon | Content, drafting, publishing | Mac Mini | Mention-gated |
| Widowmaker | Specialist execution | Mac Mini | Mention-gated |
| Skorpius | Market intelligence + content engine | Cloud droplet | Autonomous, gated (§6) |
| MemPalace | Shared memory — ChromaDB with an async read/write convention across all agents and both hosts | Both | — |
| MCP servers | Tool plane: shared-memory access · save-and-publish drafting tool · X/Twitter integration | Mac Mini | Per-agent allowlists |
| Fenrir | Watchdog — cron-driven health monitoring and alerting | Independent host | — |
Coordination is Telegram-native: agents run as managed bots with bot-to-bot messaging enabled, so the orchestrator tasks specialists in-channel, visible to the operator. Tool access is scoped per agent via allowlists — the publishing agent can post; the orchestrator cannot.
A note on framing: MemPalace is an integration, not an invention — ChromaDB plus a disciplined async read/write convention. Its value is that four agents on two hosts share durable context without standing up a message broker.
The section I would want to read if I were evaluating this.
1. Bot-to-bot blindness. Early on, agents could not see each other’s Telegram messages at all — the orchestration design assumed visibility the platform didn’t grant. Fix: moved to platform-managed bots with bot-to-bot communication mode, verified end-to-end before rebuilding coordination on top. Lesson: verify the coordination substrate before designing the choreography.
2. The gateway schema trap. Injecting agent-identity fields (default system prompt, boot file) into the gateway’s JSON config was silently invalid — and on the next reload it broke the entire gateway. Fix: config stays schema-pure; identity loads exclusively from workspace markdown. Operational rule adopted: stop → edit → bootstrap for every config change. Lesson: hot-reloading systems punish schema optimism.
3. Stale session, failed validation. One agent repeatedly failed its operator-validation step. Root cause: a stale session pinned to an old model — plus a genuinely missing capability (no publish tool existed). Fixed the session, shipped the missing MCP tool, documented the retry, passed on the second attempt. Lesson: validation failures get root-caused and logged, not re-rolled.
4. Co-located backup. The backup target was — and still is — an SSD attached to the machine it is backing up. The first audit flagged this: it covers disk failure, not machine loss, theft, or fire. The daily snapshot (launchd, 3 AM ET, 14-day retention, verified log) is reliable; the off-site leg was identified as the fix but implementation is the known open item on the board. Lesson: identifying a risk and fixing it are different steps. Write down the gap and the remediation together, or the gap outlives the intention.
Nothing in this system runs autonomously by default. Autonomy is earned through explicit gates:
chattr +i), so no agent — and no bug — can quietly rewrite its own rules.The thesis: agents earn autonomy the way employees earn trust — incrementally, with receipts.
These numbers are from the OpenClaw agent session store (May 4 → present) and the Hermes cron log-sync (June 2 → present). They are not simulated.
| Metric | Value |
|---|---|
| Production runtime | Since January 2026 (7+ months) |
| Agent sessions logged | >160 across all agents |
| Messages / tool calls executed | >5,800 logged events |
| Daily cron sync | Continuous since June 2 (50+ days, zero gaps) |
| Total agent session data | 270 MB — every interaction recorded |
| Models in rotation | DeepSeek (volume), Gemini (decisions), Ollama (local fallback) |
| Cost discipline | Spend bounded per service — local inference absorbs the floor |
| Incidents documented | 4 in the failure log above; all root-caused and fixed |
| Autonomous loops with kill switches | Every background loop has a stop condition and a cost ceiling |
| Off-site backup gap | Identified, documented, remediation scoped — see §5.4 |
These numbers are conservative: they capture only OpenClaw-tracked sessions. Bot-to-bot Telegram coordination, Hermes cron dispatches, and Fenrir watchdog checks add substantial volume outside this store.
The system works. But if I were rebuilding it today, four things would change:
1. Fenrir (the watchdog) would have been built first. The cron health-checker that monitors the agents was an afterthought — useful infrastructure I added midway through. Building the observability layer before the agents would have caught several early failures (§5.1, §5.2) in staging, not production. The system is more reliable with Fenrir; it would have been reliable from day one if Fenrir had shipped first.
2. Less schema, more convention. The config-discipline rule (stop → edit → bootstrap) exists because the gateway punished schema optimism. The lesson: when you don’t control the config format, keep your own config as convention (versioned workspace markdown) and let the gateway schema be whatever it needs to be. Identity files, personality, agent role definitions — these should live in a directory you version, not a JSON blob you reload. This is what we do now, but it cost a gateway crash to learn it.
3. The off-site backup should have been day-1 infrastructure. The co-located SSD was fine for the prototype. It was still a single point of failure three months in. The remediation (§5.4) was scoped weeks ago and still isn’t deployed. I would set a hard rule: if a system touches production data, off-site backup ships alongside the first deploy, not as a future ticket.
4. Fewer agents, more proof. Three specialist agents looked minimal at the start. In practice, two would have covered the same workload with less coordination overhead. The orchestrator (Clawdius) does the routing; the two specialists do the work. The third agent’s marginal value didn’t justify its bot token, its session slot, or the extra failure surface it created. I would start with one orchestrator + two specialists, prove the handoff works, and only add a fourth when the load requires it.
The unifying theme: the system works despite its architecture, not because of it. Every design lesson came from a failure, and the failures that hurt most were the ones I knew about and didn’t fix fast enough.
The source stays private. It contains credential pathways, revenue-connected systems, and surfaces adjacent to a regulated client business. Publishing it would be exactly the kind of judgment failure this system was designed to prevent.
Available on request: sanitized configs, architecture walk-throughs, and a live demonstration of the coordination loop.
Related public work: argos-vendor-command · helm-ai-receptionist · launchdesk · daybreak · noticeops
— Teddy Alston, Orlando, FL