For two years I have run infrastructure quality work that would normally staff a small team. Not by working more hours — by treating agents as operators I supervise, each bounded by a contract, each writing back what it did. The leverage is real, but it is not "the AI does my job." It is a specific system design, and the design is the interesting part.
The naive version of "one engineer plus agents" is a chat window and a lot of copy-paste. That does not scale past about an hour, because the context evaporates, the agent re-derives the same facts, and you become the integration layer between every step. You are the bottleneck and the memory. That is not leverage; that is a faster way to get tired.
The version that scales treats each agent as a worker with three things pinned down before it ever runs:
- A contract — what it is allowed to touch, and what it must never
do. In my system this lives in an
AGENTS.mdnext to each resource. - A memory — the authoritative facts it reads first and writes back last, so the next session inherits the work.
- A verification — the observable signal that says the work landed, so "done" is not the agent's opinion.
When those three exist, I stop being the integration layer. The agents integrate through the filesystem and git. I supervise the edges: I read journals, I approve risky steps, I tune the contracts when reality disagrees with them.
The fleet is not one giant agent. It is nine narrow ones, each with a
single job, defined under agents/:
| Agent | Job |
|---|---|
| Triage | Pre-fetch evidence, classify a failure |
| Incident | Drive an incident from signal to root cause |
| SRE | Operate live infrastructure within guardrails |
| Infrastructure | Provision and reconverge resources |
| Upgrade | Move a resource between known-good states |
| Verification | Declare intent, check it observably |
| Observability | Turn raw signals into a decision |
| Knowledge | Search prior incidents and internal docs |
| QA | Author and run tests, specify intent |
Narrow agents are easier to reason about, easier to constrain, and far easier to debug. When something goes wrong I know which contract failed. A single do-everything agent gives you one enormous blast radius and no seam to inspect.
The supervisor — me — does not micromanage. I set the work, the agents run, and I review the diffs and journals. The unit of review is the same unit a human teammate would hand me: a small, reversible change plus evidence it worked.
Every agent in the fleet runs the same loop. It is the single most important design decision in the whole system, and it is boring on purpose:
read-first
→ check feasibility against recorded capacity
→ act minimally and reversibly
→ verify with an observable signal
→ write back inventory + journal
→ commit
Read-first means the agent never acts on assumptions. It loads the
resource's INVENTORY.yaml — capacity, services, ports, mounts — before
it proposes anything. Feasibility means it checks the action against
those recorded facts: you do not schedule a workload onto a node pool
that the inventory says is full. Minimal and reversible means small
steps with a known rollback path, recorded before the step runs.
Verify means an observable check, not a log line that says "success."
Write-back means the inventory and the append-only JOURNAL.md reflect
the new reality. Commit means the next session — mine or another
agent's — inherits all of it.
This loop is implemented in resource-ledger, the git-tracked resource
memory and feasibility CLI. A simplified feasibility gate looks like
this:
def can_schedule(inventory: dict, request: dict) -> tuple[bool, str]:
"""Check a placement request against recorded capacity."""
free_cpu = inventory["cpu_total"] - inventory["cpu_allocated"]
free_mem = inventory["mem_total_gb"] - inventory["mem_allocated_gb"]
if request["cpu"] > free_cpu:
return False, f"cpu short: need {request['cpu']}, free {free_cpu}"
if request["mem_gb"] > free_mem:
return False, f"mem short: need {request['mem_gb']}, free {free_mem}"
return True, "ok"It is fifteen lines. It is not clever. But it turns "the agent decided it was fine" into "the recorded capacity says it is fine, and here is the arithmetic." That distinction is what lets me run many agents without watching each one.
The other reason the fleet scales is that I never let a model be responsible for a fact it could get wrong. Counting failures, reading an exact status, extracting an error signature — those are done by cheap deterministic scripts before the agent reasons. The agent gets the hard facts handed to it and spends its budget on judgment, which is the thing it is actually good at.
In state-triage this is explicit: deterministic pre-fetch and parse
produce a state.json, and the agent fills typed sections of that file.
The final report's counts and statuses never depend on a model counting
correctly. When a director asks "how many of the runs hit this error,"
the answer came from grep, not from a guess. That is the difference
between a tool you can put in front of an incident review and a toy.
Concrete outcomes from running the fleet rather than doing the work by hand:
- Triage that used to take an afternoon takes minutes. A failed run
comes in, the Triage agent has already sliced the logs with
loglens, classified the failure, and searched prior incidents before I look. - Knowledge survives turnover. The journals are the institutional
memory. When I hand a resource to someone else, the
RUNBOOK.mdandJOURNAL.mdcarry two years of "why we do it this way" that would otherwise live in my head. - More surface area covered. I can keep many investigations in
flight because each one persists its own state. I am not holding nine
contexts in my head; nine
state.jsonfiles are.
This is not free, and pretending it is would be exactly the hype the brief tells me to avoid.
- Contracts rot. An
AGENTS.mdthat no longer matches reality is worse than none, because the agent trusts it. The discipline is: reality wins; when the file and the world disagree, fix the file immediately, in the same change. I have shipped a bad day because an inventory said a mount existed that had been moved. - Over-decomposition has a cost. Nine agents means nine contracts to maintain. If a job genuinely is one job, splitting it into three agents adds handoff overhead and gains nothing. I split only when the blast radius or the reasoning genuinely differs.
- Verification is the hard part, not the acting. Writing the action is easy. Writing the observable check that proves it worked — and that fails loudly when it did not — is most of the engineering. Teams that skip this get agents that confidently report success into a broken system.
- Supervision does not go to zero. The leverage is maybe 5–10x on the right work, not infinite. Risky, irreversible, or novel steps still need a human in the loop. The skill is knowing which steps those are and gating them.
- A confident wrong agent is dangerous. The whole point of read-first, feasibility, and verify is to bound this, but no bound is perfect. I keep changes minimal and reversible precisely because some fraction will be wrong and I want cheap rollback, not heroics.
Start with one resource and one loop, not nine agents. Build the memory
first — INVENTORY.yaml, AGENTS.md, RUNBOOK.md, JOURNAL.md — and
make one agent obey the read-first loop on it. Get the verification
honest before you scale. The instinct is to add agents; the leverage
comes from the boundaries. Add the second agent only when the first one
is boring and trustworthy.
And measure the right thing. The metric is not "how much did the agent do." It is "how many changes landed reversibly with verification, and how many had to be rolled back." If the rollback rate is low and the verification is honest, add more surface area. If it is high, your contracts or your checks are wrong — fix those before you scale.
- Leverage comes from boundaries (contract, memory, verification), not from a bigger model.
- Prefer many narrow agents over one general one; the seams are where you debug and constrain.
- Run every agent through the same read-first → feasibility → minimal act → verify → write-back → commit loop.
- Never let a model own a fact a script could get right; parse hard facts first.
- Keep changes minimal and reversible because some fraction will be wrong.
Where this is heading: as the contracts and journals accumulate, the fleet gets cheaper to run, because each new task starts from more recorded reality. The supervisor's job slowly shifts from operating to curating the memory that the operators read.