Tommy: a six-agent fleet that runs my day

Tommy is not a chatbot. It is a fleet.

Six specialised agents share a memory layer and a skills library, orchestrated by a router that sends each job to the cheapest model that can actually do it. Sixteen scheduled jobs run whether I am awake or not: a morning intelligence briefing, a content pipeline that drafts and queues, notification sweeps at midday and evening, nightly backups.

What it is made of

Nineteen skills give the agents real capability: web search, email, calendar, file operations, publishing. The whole thing survives reboots as a background service, and every configuration change is versioned.

The routing layer is the part most people skip. A formatting job and a strategy job do not deserve the same model. Tommy classifies the job first, then picks the model, so the expensive tier only gets called when the work justifies it.

What broke

I built and debugged all of it without writing code by hand, and the failures are the useful part:

• Gateway crashes that turned out to be a corrupted config file, rewritten by a process that should not have had write access.
• A misconfigured API wire format on one model provider that cascaded through every agent using it. One wrong field, six broken agents.
• A sandbox that silently switched itself off after a container error, leaving every agent running with more access than intended for days before I noticed.

Each one is documented in the Build Log, with the root cause and the fix.

What I would do differently

Start with the security posture, not the capability. I built outward from “what can it do” and had to retrofit “what should it be allowed to do”. The roadmap below is that retrofit.