Somewhere in a long agentic session, an agent has to decide where a piece of work goes. Before it can, it needs four answers: what can I use? Is it working now? Is this job allowed to use it? What happens if the worker gets stuck? Most setups leave those answers in prose, if they exist at all.
I built rough answers to all four over the summer. By the time I finished, the toolchain had shipped native ones.
The implementations changed; the questions did not. That makes this a strange moment to write. The ground is moving faster than my feet. At the start of the summer, several of these problems were obscure enough that I hand-built answers. By late autumn we may have forgotten they were problems because the harnesses will handle them. I still think it is worth seeing what sits underneath. You may never write a connection pool, but knowing what one does helps when it leaks; agent tooling will leak too.
When a fleet is worth it
For a single bounded task, one agent in a good loop is usually right because the coordination overhead buys you nothing.
The case for a fleet starts with work that can run in parallel, contexts that would pollute each other, or a build-and-review split where one agent judges another's output. Separate windows keep each job focused. That is a correctness measure before it is a speed one.
The first practical limit is your own attention. 's agent view puts background sessions on one screen so you can "step in only when one needs you", while ten in parallel consume roughly ten times the subscription quota . Quota is the second constraint, and the reason spending has to be checked before a job starts. Attention still sets the fleet's ceiling well below what the hardware could run.
What a serious version of this looks like is not what I built. Mine ran on a laptop with standing in for isolation, and the surface was a I could read from a phone. An organisation doing it properly has two halves to get right. I underestimated the second.
The first half is the spine: how work is admitted, authorised, dispatched and accounted for. Policy sits ahead of dispatch. A gateway holds routing and spend limits. Each worker runs in a real with short-lived credentials the agent never holds. Evidence is written whether or not anyone is watching. Above it sits a control plane where operators can see the board, prioritise the queue and answer questions an agent cannot settle.
The spine. Note the dotted line: an agent that is stuck has to be able to reach a human, and that path needs to exist by design rather than as a log line nobody reads. Author's illustration.
The second half is what a worker can reach once it is running, and this is where my experiment was poorest. My got a brief and a directory. That is nothing like the access a human on the same task would have.
On an unfamiliar ticket, you read the internal docs, look at how another team solved something similar, inspect what the data actually contains and use tools that require trusted credentials. You ask a colleague who has seen the problem before. An agent given none of that is closer to a contractor locked in a room with a printout than to a junior engineer.
What a worker can reach, and the broker that decides. Not every project needs every lane, but a factory running many projects needs all of them available and separately grantable. Author's illustration.
Five lanes in that second diagram, and none existed in my version.
Managed tool access. Agents need internal tools and external ones, and is how that is arriving. What makes it managed is that the grant is per job rather than ambient: this worker, on this task, may reach these three servers, and every call is recorded. Most setups instead hand every agent the whole toolbelt and hope the brief holds.
The . This is separate from the tools above. MCP is what the agent can do; an API is a contract between the software it is building and everything else the company runs. Those integration points have to be discoverable. such as provide a registry where teams declare services and with the owner and contract attached . It suits agents because it is structured and queryable: an agent can ask what exists instead of being told. Without it, you get the week-one mistake of hand-writing a client for a system that already publishes one.
Knowledge stores. The company's documentation, architecture decisions, runbooks and post-mortems. A human doing the work would read them. An agent that cannot is guessing at conventions it could have looked up.
The data platform. Read-scoped and governed, but present. Much real engineering work starts with "what does this data actually look like?" An agent reasoning from a schema rather than the data reaches confidently wrong conclusions.
Memory that outlives the session. A worker that finishes and forgets means the fleet relearns the same thing every morning. Shared memory, scoped per project and selectively across projects, turns a set of contractors into something with institutional knowledge. It also creates a hazard: a wrong conclusion written into shared memory is inherited downstream.
Not every project needs every lane. The point of a broker is that access is granted rather than assumed. A factory working across many projects must be able to offer all five because its agents need the information its humans would have needed.
What I built, and what I did not
Those diagrams show the target state as I understand it. They do not show my experiment.
I built the model gateway and the spending rules in front of it, a back-channel for a blocked worker, and an evidence trail. That is it. I had no control plane beyond a dashboard rendered from log files, no container isolation, no managed tool grants, no catalog, no knowledge stores, no data platform and no memory that survived the session. My workers could not talk to each other. Access was not brokered because there was nothing to broker.
That gap is one of the experiment's results. I set out to learn whether cheap capacity could carry real work and found that it can. I also learned that the distance between a functioning experiment and a lies mostly in the parts I did not have to build. Answering the four questions made the fleet function. It did not make it something I would run a company on.
This is not a build list. Companies with real budgets are constructing these systems, and few readers will assemble one by hand. Understanding the shape lets you judge what they offer.
The four answers below are where I have evidence. The factory above is where I think this goes.
The answers cannot live in the instructions
The factory tour was long, so here are the four questions again: what can I use? Is it working now? Is this job allowed to use it? What happens when the worker gets stuck?
Keep one ordinary job in view: review a code change and report whether it is safe to merge. Before the can hand off even that small job, it needs all four answers.
The tempting fix is to write those answers into the project instructions: list the models, mark the cheap ones, protect the expensive subscription.
That fails twice. The list is wrong within a week as providers add models, retire names and reset plans. It is wrong silently, so the first warning is a failed job. Procedural memory also decays. I watched an orchestrator forget which files belonged in a worker's sandbox with the rule written in three places.
The useful distinction is between a fact an agent remembers and one it queries. Each answer needs one clear source that the orchestrator can ask before dispatch.
Four questions between an agent and the capacity it spends. Only the fourth points back the other way. Author's illustration.
What can I use?
For the review job, the first answer is a live list of the models available across your providers, with enough detail to choose between them: what they can do, how much context they can hold and what they cost. The orchestrator asks for the list when it needs it instead of keeping a copy that goes stale without warning.
The catalogue should stay narrow. It is not a , proxy or credential store. It can also name useful defaults such as the best coding model, the best-value model and the best free one, so every tool does not rebuild the same ranking.
My Model Discovery Feed does that. Omnigent now pulls choices from live provider catalogues and installed command-line tools rather than names baked into a release . A gateway can populate a client's picker from its own endpoint when discovery is enabled . The tools differ. The question does not. A hand-maintained model list is wrong by Thursday.
Is it working now?
This is the question people skip, which is why setups that look correct fail in the middle of real work.
The catalogue may name a suitable reviewer, but it cannot say whether that model will answer now. Selection alone gives you plausible entries that fail on first contact, after the brief and context have already been assembled.
Before a model enters the pool, something has to call it and check that it answers. A failing model comes out; a recovered one goes back in. If the provider has published a quota reset time, the system should wait for it instead of spending calls to discover that nothing has changed.
One writer per file
Your rules about which models you want are yours, and the tool never edits them. The health record belongs to the tool that measured it. The record of what failed in live traffic belongs to whatever saw the traffic. Three files, three owners, no overlap.
That ownership rule stops a scheduled run overwriting a manual decision and keeps a live failure from disappearing during regeneration. One more guard matters: refuse to write an implausible result. A bad download should never empty a working configuration.
My version is the LiteLLM Model Config Maintainer, which reads the feed, applies my rules, checks that each candidate actually answers, and only then writes.
shows the fuller version. It separates cheap liveness and readiness probes from /health, which makes real model calls and can cache them from a background loop . Health-driven routing removes a failing deployment before a user request lands, applies different thresholds to different error types, and restores the deployment after cooldown . Without that distinction, one timeout can evict a healthy model. That is superstition, not a health check.
Is this job allowed to use it?
A model can be suitable and healthy yet still be off-limits for this review. "Allowed" hides two questions, and confusing them cost me the capacity I most needed.
The first is may this job spend real money at all. Free, flat-rate and metered capacity are different permissions. A job can usually use the first two but should need explicit permission for the third.
The second is whose account does it come out of. Several flat-rate subscriptions all pass the first test, but each has its own limit. Two seats with the same vendor are separate pools. A fleet that cannot tell them apart drains whichever it reaches first, which in my case was the one I could least afford to lose.
The check happens before launch. If no permitted capacity remains, stopping is correct. The refusal should say what ran out, what was ruled out and when the soonest account refills, because waiting is often cheaper than paying.
The cost of getting this wrong is easy to measure. One trivial test job of mine, dispatched to directly-billed capacity because nothing stopped it, cost nearly three dollars.
My Claude Lane Orchestrator checks whether a job may use metered capacity and which accounts it may draw from. LiteLLM has cost-based routing, provider budgets, and spend tracking per key and team with scheduled hard-cap resets . The product can enforce the rule, but you still have to decide it.
What happens when the worker gets stuck?
The first three questions point outward, from the agent toward the capacity it spends. The fourth points back.
Once the review starts, dispatching to a headless agent is usually a one-way trip. If the brief omits which library the project chose or whether an interface may change, the worker guesses or gives up. One missing sentence can cost the whole job twice.
A back-channel lets the worker ask and wait. Each question names its job. The orchestrator claims a question before answering so two sessions do not research it at once, and the claim expires if the holder dies. Declining with a reason is a complete outcome, which keeps the channel from becoming an interruption queue. A worker cannot resolve its own question, and the turn cannot end while one waits. The failure worth preventing is silence: a worker blocks, nobody reads the question, and everything looks fine until the result comes back wrong.
This had the largest measured effect of any change I made. Two stalled units went from nothing to nearly complete after one answer; blind re-dispatch had produced nothing across two waves.
My version is the Agent Orchestrator Messagebox. Code's cross-session messaging now provides the native form. A message from another session cannot count as consent, answer a permission , change configuration or run a command embedded in its text . A worker can ask for help, but it cannot smuggle authority through the reply.
This creates a star: every worker talks to the orchestrator, never sideways. That is easy to audit and also a bottleneck. Peer communication and shared memory may improve the topology, but they need their own rules for ownership, consent and correction. I did not test them, so I will leave them outside the four.
Make the checks unavoidable
Rules can live in prose, a skill or a command. Prose is cheapest and decays fastest. A skill brings the right judgment with the tool, but it is still prose. A command holds because the tool decides. My launcher resolves the model, checks the account and refuses before dispatch; the orchestrator cannot forget a check that is part of the operation itself.
Hooks remove the choice to call the command. One refused dispatches that would not be recorded; another blocked the session from ending with stale evidence or an unanswered worker question. A bootstrap script refreshed capacity and open work at the start of every session because the prose version had already failed.
State needs the same discipline. My rules, the measured health record and the build log each had one writer. The config maintainer refused an implausible result so a bad download could not empty a working file. After a repair script destroyed a decoder, the sandbox builder stopped deleting old attempts and moved them aside instead.
Executable gates still need suspicion. One decoder passed because its output parsed, even though the files contained almost nothing. A gate measures only the property you wrote down. The job is to put spending permission, state ownership and evidence behind mechanisms that fail loudly, then make the model's forgetfulness irrelevant.
Now the orchestrator can choose
With the four answers in place, routing becomes something the orchestrator can ask for. A job declares its purpose: planning, implementation, review or bulk mechanical work. The dispatcher finds what exists and what answers, checks whether the job may use it, walks a failover list, and refuses work whose input exceeds every permitted window.
The orchestrator never needs an opinion about whose weights are behind "a reviewer". Cost, quality and speed are preferences the dispatcher enforces. Which model suits which work is a separate argument.
Every job owes you evidence
The four questions get a job started. Evidence is what the job owes you when it finishes: an inspectable change, an acceptance command run against it, and a record of model, cost, attempts and verification.
Without that, a fleet that works and a fleet that is merely busy look alike. My dashboard showed every gate green on a build whose output was visibly wrong. Judge the dispatch, not its report.
The tools change faster than the questions
In June, each answer was a script of mine; by August, the same jobs lived in settings elsewhere: live catalogues, health-driven routing, provider budgets, per-key spend tracking and cross-session messaging.
Five weeks was enough to date my tools, and by late autumn some examples here may be stale. A listed model will still need proof that it answers, two seats with one vendor will remain separate pools, and a blocked worker will still need a way back.
Three decisions remain yours: the spending rules, the role definitions and the audit record. Only you know which account must stay alive, what "a reviewer" means on this project, and what evidence you will accept when someone asks whether the fleet worked.
Final thought
A fact an agent must act on should be something it queries, never something it remembers.
Before an Agent Fleet Can Work · August 2026 · A companion to the summer's field report, covering the machinery the narrative left out. Measurements from the author's own build record; product capabilities cited to vendor documentation as of the accessed dates.
References11
- 1LiteLLM, "Router: Load Balancing" (routing strategies including cost-based routing against the model cost map, usage-based routing, latency-based and least-busy routing, cooldowns, retries and fallbacks). docs.litellm.ai ↗ Accessed 2026-08-09
- 2LiteLLM, "Health Checks" (`/health` issuing real model requests, `background_health_checks` with `health_check_interval`, and the lightweight `/health/liveliness` and `/health/readiness` probes). docs.litellm.ai ↗ Accessed 2026-08-09
- 3LiteLLM, "Health Check Driven Routing" (background probe loop, failing deployments removed from the pool before a request lands, `allowed_fails_policy` per error type, temporary cooldown with automatic recovery). docs.litellm.ai ↗ Accessed 2026-08-09
- 4LiteLLM, "Spend Tracking" and "Budgets, Rate Limits" (spend per key, user, team and organisation; hard budgets with daily and monthly resets). docs.litellm.ai ↗ · docs.litellm.ai ↗ Accessed 2026-08-09
- 5LiteLLM, "Provider Budget Routing" (per-provider spend limits used as a routing constraint). docs.litellm.ai ↗ Accessed 2026-08-09
- 6Anthropic, Claude Code documentation, "Model configuration" (gateway model discovery populating the model picker from the gateway's own model endpoint). code.claude.com ↗ Accessed 2026-08-09
- 7Anthropic, Claude Code documentation, "Agent view" (one screen for background sessions; "step in only when one needs you"; background sessions consume subscription usage the same as interactive ones, so ten in parallel use quota roughly ten times as fast). code.claude.com ↗ Accessed 2026-08-09
- 8Anthropic, Claude Code documentation, "Message your other Claude Code sessions" (cross-session messaging, inbound controls, and the limits on what an incoming message may do). code.claude.com ↗ Accessed 2026-08-09
- 9Omnigent, GitHub release notes for v0.8.0 (live model discovery: model choices taken from the active provider catalog and installed CLIs instead of release-baked names). github.com ↗ Accessed 2026-08-09
- 10Databricks, "Introducing Omnigent: a meta-harness to combine, control and share your agents", June 13, 2026. databricks.com ↗
- 11Backstage, "Software Catalog" (open framework for internal developer portals; APIs are first-class catalog entities alongside components and resources, with ownership and dependency relationships, and the catalog backend exposes a JSON REST API). backstage.io ↗ Accessed 2026-08-09