The Fleet — Production Agents, One Repo

The brief

One agent shipping a workflow every day is a successful pilot. Ten agents shipping ten workflows every day is a different category of problem. Each one is its own cron, its own API key, its own state directory, its own voice rules, its own failure mode. The instinct is to spin up ten parallel projects, ten parallel repos, ten parallel sets of credentials. The instinct is wrong — the operator becomes a stand-up daemon, babysitting jobs across ten dashboards, and the moment one agent breaks the rest are invisible.

The system has to invert that. One repo. One boot pattern. One memory surface. One alerting channel. One validator gate. The agents inherit; the operator audits.

What we built

A shared agent boot pattern — every agent in the fleet ships as a directory under agents/<name>/ with a CLAUDE.md boot pointer, a run.sh entry script, a prompts/ directory of versioned system prompts, a data/ directory of locked JSON contracts, and a state/ directory the agent writes back into. The boot pattern is the same shape for Pip the prediction-market agent, for Knox the cold-engagement drafter, for Rex and Riley on Reddit, for the daily essay engine, for the daily video pipeline, for the Closer agent, for the Apollo prospecting agent. New agent: copy the directory shape, edit four files, register a launchd plist.

A memory mirror system that snapshots Supabase tables, Gmail unread counts, Plausible traffic, and per-agent state into git-tracked markdown files every thirty to sixty minutes. The mirrors are what the agents read at boot — no live API calls during the run, no rate-limit collisions, no credential management inside the agent code. The mirrors live under memory/mirrors/ and any agent can grep them at startup. The same mirror commits are gated by the same Netlify ignore-script that gates the public site, so mirror churn does not eat the deploy budget.

A single validator surface under scripts/validate-* shared across every agent that produces public output. Voice unity is architectural — every agent inherits from the master voice file at runtime, no copies, no forks. A Telegram fail-alert wired into the failure path of every run.sh in the fleet, so a broken agent surfaces immediately on the operator’s phone without dashboards.

Per-agent failure isolation. One agent down does not tank the others — each has its own plist, its own state, its own log. The fleet runs the daily essay, the daily video, roughly ten Reddit posts and comments, roughly ten cold replies across X and LinkedIn, prediction-market trades on demo, Apollo cold sourcing, Upwork bid drafting, and Closer follow-ups, all on the same day, from the same repo, without contention.

The receipt

A fleet of agents running in production from one repo. The operator spends under thirty minutes a day across the entire fleet — not because the agents are simple, but because the infrastructure was designed for a fleet from the beginning. Median per-agent runtime is two minutes. Failures surface on Telegram in seconds. The mirrors are auditable in git. The validators block the bad outputs at the gate.

What this signals for a buyer: an AI-automation business is not one agent and an OpenAI key. It is a fleet, a shared backplane, a memory mirror, a validator surface, and an alerting channel — and the leverage compounds with every agent added rather than dividing across them. Running a fleet of them with one operator is the deliverable. The next one is cheaper than the last.