Orchestrating a fleet of agents: the fanout that runs them

Patient work, woven in public.

This is Thread 15 of Loomwork. New here? Thread 01 explains why this newsletter exists — 2 minutes. Threads 09 and 11 introduced Galaxy as a single agent orbiting your stack. This one is about what happens when it isn't one agent any more.

I've built a registry of 48 specialist agents — roughly one per tool a stack might contain — plus a master chief-of-staff that reads everything they find and writes one morning brief. Six run on a schedule against my own stack today, and the chief-of-staff also answers on demand; the rest activate the moment a credential is connected. A scheduler wakes every hour and runs each user's fleet once, at their local hour.

The agents turned out to be the easy part. The scheduler is the product.

The problem, stated as engineering rather than as a feature.

A specialist that reads your GitHub and flags a stale PR is a weekend project. The system around it is not. Every user connects a different subset of forty-eight tools. Each subset has to run on a schedule that respects that user's timezone rather than one global 9 AM. Every run spends real money that has to be capped before the call, not reconciled after it. Some agents read other agents' output and cannot run until those have finished. And at the end, one model has to read everything and produce a brief that doesn't read like forty-eight bullet points stapled together. None of that is "can an agent call an API." All of it is orchestration.

Three shapes I weighed, and the two I rejected.

A cron per tool. The obvious instinct: GitHub gets a scheduled job, Vercel gets one, and so on. It doesn't compose. Forty-eight schedules multiplied by however many users converges nowhere, and it leaves no natural place for synthesis — every tool would know how to check itself, and nothing would know how to add it up.

A persistent worker per agent. The architecturally orthodox answer at scale: long-running processes, event-driven, queued. Deferred deliberately. The deploy target is serverless, and workers don't fit it without infrastructure that buys me nothing at today's volume. It solves a scale problem I don't have at the cost of the two I do: cost discipline and execution order.

What I built: one hourly cron that fans out per user, per tier. A single job wakes every hour and asks each user one question — is it your scheduled hour, in your timezone? The tick is hourly; each user is briefed once a day, guarded by a 23-hour cutoff so a retry can never double-charge anyone.

Order is a correctness property, not a performance one.

For whoever is due, three tiers run in a strict sequence. Monitoring specialists first — the read-only tool-watchers. Then role agents, which read those findings as context: a Tech Lead reviewing your open PRs is far more useful once it knows what the monitors just saw. Then desk agents that synthesize per team. Only then the master chief-of-staff, which reads every finding from every tier and writes the one brief.

Inside a tier, everything runs in parallel and failures are isolated — a broken Sentry connection must never cost you your GitHub findings. Across tiers, execution is strictly sequential, because tier three literally consumes tier two's output. That ordering isn't a tuning decision I could relax for speed; violate it and the later agents reason from data that doesn't exist yet.

Spend is a ceiling in code, not a chart in a dashboard.

Before any tier runs, two gates are checked. A per-user monthly ceiling of $64 — deliberately 80% of the $80 platform cap — so a single runaway account can never drain the budget for everyone else. And the global platform ceiling behind it. At roughly 1.3 cents per briefing cycle, that covers on the order of two hundred daily-active users.

The important word is before. These are pre-flight checks that refuse to start, not alerts that tell you what you already spent. A budget you observe is a report; a budget that can decline the call is a control. They're evaluated once at the top of a cycle, which is the right granularity for work measured in cents — per-call accounting is the trigger to add when a single cycle can cost real money.

The model is chosen per job, not per vendor.

Not every agent gets the same model, and many get none at all. Deploy-failure detectors like Render, Railway and Fly.io derive the answer straight from the API response — "did the deploy fail" is a boolean, and paying a language model to read a boolean is waste. Most per-tool summarizers run on Haiku, which is more than enough to turn an API response into a sentence a human wants. Exactly three jobs run on Sonnet: the Tech Lead's PR review, the master's synthesis, and the interactive chief-of-staff — judgment and synthesis, where better reasoning changes the answer rather than just the prose.

Each specialist declares the model it needs, next to the work it does. Model choice is a property of the job, and the job is the thing that knows what it costs.

The brief is built before the model is asked.

This is the piece I'd defend hardest. The master doesn't hand a pile of findings to a model and hope for a briefing. It first ranks every finding by severity and recency and assembles a valid, structured brief deterministically — in code, with no model involved. Only then is the model asked to rewrite the prose on top of that fixed structure. Its output is schema-validated, and if the call fails or returns something malformed, the deterministic brief is what ships.

The result is that a language model failure degrades the writing, not the product. Findings that don't make the cut are summarized as a counted tail rather than silently dropped, and everything the agents ingest is wrapped as untrusted before it reaches the model, so text from a stranger's PR is treated as data to be read rather than instructions to be followed.

An LLM should be the best part of your system. It should never be the load-bearing one.

The failure mode of a scheduled system is silence.

Early on, this scheduler shipped in a state where every real trigger was rejected — the endpoint accepted one kind of request and the platform's cron sent another. Nothing crashed. No alarm fired. A missing morning brief just reads as a quiet morning.

That's the failure mode worth designing against, and it generalises: anything that runs on a schedule fails quietly, because the absence of output looks identical to the absence of news. It's precisely why the fleet-health surface from Thread 14 exists — a system that runs without being watched is a system that has already stopped, and you just don't know it yet.

What I'm deliberately not doing yet.

Users are processed sequentially inside a five-minute serverless window. That's correct at today's volume and it is the first thing I'll chunk when it isn't — I know the exact line. A tier-one failure flags and lets the run continue rather than retrying with backoff, because a partial brief beats no brief; real retry semantics are reliability work with their own chapter. And the tiered fanout is proven end to end, but not under forty-eight-way parallel load, so I'm treating per-user concurrency limits as an open question until real usage tells me the answer rather than guessing at it now.

The pattern underneath all of it: the interesting problems in a multi-agent system aren't in the prompt. They're in the scheduler, the ceiling, the ordering, and the one voice at the end.

— Vamshi

Loomwork is by Vamshi Krishna Veggalam. Building Foundry at mindloomhq.com, with the full archive at loomwork.dev. Find me on LinkedIn.