Multi agent operations platform: 9 agents, one job each, and my approval on risky steps

Why nine agents and not one

One agent that does everything carries every instruction at once and holds every key at once. The agent drafting an email does not need deployment credentials; the agent parsing receipts does not need my LinkedIn drafts. Mixed instructions produce mixed behaviour, and shared access turns one mistake into a wide one.

So the work is partitioned the way a company partitions departments: mutually exclusive, collectively exhaustive. Each agent has one domain, its own workspace, its own memory, and only the tools that domain needs. A router decides who owns a request. The infrastructure agent checks hourly that nobody has drifted out of lane.

Topology

Nine agents, one owner per domain, no overlap. Alongside these agents, a typed decision model answers narrow questions for them; details on Fast decisions.

Router

The default agent receives every message from Discord or Telegram, classifies it, and hands it to the owning domain agent as a kanban card. It does small lookups itself only when routing would cost more than the task.

Domain agents

• Academics: Coursework at IIM Ranchi and IIT Madras, research reading and deadlines.
• Career prep: My own applications, resume and interview prep.
• Finance: Receipts to ledger, self hosted Firefly III.
• Infrastructure: Declared system state, services, backups, secrets. Houses the hourly drift audit engine and cleanup engine.
• Personal ops: Tasks, briefings, reminders, habits.
• Socials: LinkedIn and personal posts, drafted by the agent, published by me.
• Consulting: Commercial go to market consulting.
• Private: One agent for institute work, not described here.

Kanban hand offs

Work moves as cards: objective, context, acceptance criteria, owner. The router writes the card, the owner session writes the artifact, and a card can spawn read only children for research or critique. Cross domain jobs are separate cards linked by a parent, never one mixed artifact.

Planning at maximum effort

Some tasks need a specification before anyone writes code: multi file architecture, design direction, fact audits. Those go to a planning pass I call Fable: the strongest available model at its highest reasoning tier, asked for an executable plan. Builders then follow the plan.

Upkeep

The infrastructure agent audits configuration drift every hour and files findings rather than silently fixing them. Its janitor engine batches cleanup proposals and waits for my approval before deleting anything.

How a request moves

I dictate, check the text, then send it. What needs me lands in Google Tasks.

Input

I dictate with FreeFlow on Mac or Dictate on Android, both free and open source, read the transcript, and send it as text on Discord or Telegram. I skip the runtime's own voice plugins on purpose: I want to see what got written before an agent acts on it.

The gate

Sends, deletes and public pushes wait for my approval. Outbound email, file deletion and public git pushes stop at the gate until I have inspected the diff or the artifact. A question to me has no timeout. An unanswered card parks; it does not proceed.

Output

Important actionables that need me are synced to Google Tasks by an idempotent ledger, and a watcher logs what I complete or edit so the agents learn what I actually did.

Hours with my agents

Time I spent working with the agents on Discord, Telegram, the command line and Claude Code.

How hours are counted

Counted from the timestamps of messages I sent to my agents in Discord, Telegram, the command line and Claude Code, whether dictated or typed. Messages less than 15 minutes apart form one session, each session gets a 5 minute tail, and automated notifications are excluded.

Tokens and models

Combined daily token throughput across three paths: 9Router, a local model gateway that routes each call to a provider and falls back when one fails; direct Hermes calls to Claude; and the Claude Code CLI.

Most volume goes to a fast, cheap model for routine steps; the expensive models are reserved for planning and review.

Messages and leverage

About 5 agent replies for every message I send. That ratio is the point of the design: I write instructions, not code.

How replies are counted

Assistant messages across every agent conversation database, including scheduled jobs and subagents, counted once each after removing copies created when long conversations are compacted (same role, timestamp and opening text). Tool results and my own messages are counted separately.

Access from any device

I can run the whole platform from my phone, so work continues when my laptop is closed or not with me. Three pieces make that work.

• Private mesh: Tailscale, a WireGuard based private network, joins three devices: the server (an Azure VPS, Linux), my MacBook Pro (macOS) and my phone (Android). I reach the server over the mesh, from those three devices.
• Termius: I sometimes SSH in via Termius from my phone or laptop over Tailscale. It connects over the mesh, so I can check a service or restart one from the phone.
• Dictation: I dictate on my phone or Mac (Dictate on Android, FreeFlow on Mac), read the transcript, then send it on Discord or Telegram. The router agent picks it up from there.

Host, isolation and secrets

Every agent runs on one rented cloud server and stays inside its own workspace. The host is an Azure VPS running Ubuntu 24.04, and the runtime moved there from a MacBook Linux VM on 20 Sep 2026, so the agents run around the clock.

• systemd services: Each long running piece, such as the model gateway and the chat gateway, runs as a system service that restarts on its own after a reboot.
• Workspace isolation: Each agent has its own working directory, persistent memory, scoped tools and skills. Each domain keeps its own data in its own workspace.

Secrets and backups

Secrets live in locked down files and a credential vault that fills only at its own origin; nothing secret is ever pasted into chat. Guard scripts check the context files each agent reads. State is backed up hourly, encrypted capsules go offsite daily to GitHub Releases, the offsite copy is verified weekly, and a scripted restore to a fresh server exists.

What the review step has taught me

This page is built through the same pipeline: a planning card at maximum effort, a builder agent in the consulting profile, and a review gate before release. The review step is how stale figures on this very page were found: counts had been typed into prose and the system had moved on. The rebuild binds every number to the data file the agents maintain, so the gate now checks a script, not a memory.