Skip to content
Andrew Concepcion
[search /]
SYSTEMS DEBRIEF technical 4 min read 7 sections

Running an Agent Fleet Without Losing the Plot

Lessons from multi-agent engineering work: define output contracts, instrument repeated effort, match verification to risk, and preserve trustworthy handoffs.

RSS
A hand holds a smartphone against blurred colored lights.
More screens do not create coordination; the workflow between them does.
Authored by Andrew Concepcion SYSTEMS DEBRIEF
#ai_ops#prompt_engineering#team_process#technical
[systems debrief] 7 sections

Running several coding agents at once looks like a capacity problem: add more workers and finish more tasks. In practice, the bottleneck moves quickly from typing to coordination. Agents need clear ownership, short feedback loops, and a shared definition of what counts as evidence.

The useful lesson from my early fleet experiments was not that one stack “wins” or that a large token budget fixes weak instructions. It was that agent throughput is constrained by the same things that constrain teams: ambiguous plans, slow integration feedback, duplicated work, and handoffs that do not preserve state.

01. More agents amplify the plan they receive

A vague task given to one agent produces one vague implementation. Given to several agents, it produces several interpretations that now have to be reconciled. Before parallel work starts, I want one written outcome, explicit non-goals, and a map of which surfaces can change independently.

A frozen plan helped when the work was already understood. It stopped a planning role from inventing a new roadmap every iteration. But freezing uncertainty is not discipline. If the live repository or a failing check disproves the plan, the right move is to reopen the decision and record why.

02. Roles need outputs, not personalities

Planner, implementer, tester, and reviewer can be useful labels, but only when each role leaves a concrete artifact for the next one.

  • Planner: owning files, behavioral boundary, risks, and acceptance evidence.
  • Implementer: focused diff, assumptions, and the checks already run.
  • Tester: scenario coverage, commands, results, and what was not exercised.
  • Reviewer: findings ordered by impact, accidental scope, and the final re-check.

The reviewer should not blindly stage or publish whatever the preceding roles produced. External actions still require the user's authority, and failed validation remains a blocker or an explicitly documented limitation—not a reason to create a reassuring checkpoint.

03. Feedback latency shapes fleet velocity

Web projects often give agents quick signals through type checks, component tests, and browser automation. Mobile and multiplatform projects may require slower compilers, packaging, emulators, devices, signing, or platform-specific integration. That does not make one ecosystem inherently better for agents. It changes the cost of a wrong assumption.

When feedback is slow, the fleet benefits from smaller patches and more selective checks. Run the narrow task that can falsify the current assumption first; reserve full packaging and broad smoke coverage for the point where integration risk justifies them.

04. Instrument repetition, not just token totals

Raw token counts can show that a run was expensive, but repeated behavior explains why. I pay more attention to the same file being reread, the same command being run by several roles, or a tester recreating evidence the implementer already captured. 

role
duration
files inspected
commands and exit codes
repeated commands
changed paths
handoff completeness

Once those signals are visible, prompt changes can target a real waste pattern. “Be more efficient” is vague. “Reuse the previous role's passing lint result unless the relevant files changed” is an operating rule.

05. Verification should follow the diff and the risk

Every role running the heaviest validation command is not rigor; it is duplication. The fleet needs a shared map from changed surface to relevant evidence. A prose-only edit may need link, rendering, and publication checks. A state-management change may need focused unit tests plus an end-to-end scenario. A release change may need the full build and artifact inspection.

The important distinction is between “a command passed” and “the behavior is proven.” Build success does not prove a user flow. A screenshot does not prove persistence. A local check does not prove a remote deployment.

06. Handoffs make parallel work durable

Agent sessions are disposable; repository state and external side effects are not. Each bounded task should leave a short re-entry point: what changed, why, what passed, what remains uncertain, and the next command that would verify the result again.

This is also where privacy and company context matter. A fleet that moves between repositories can easily paste the wrong ticket, client detail, or account identity into a public artifact. Visible text needs a final context scrub just as code needs a diff review.

07. The operating rules I kept

  1. Parallelize independent discovery before parallelizing edits.
  2. Give every role an output contract another role can consume.
  3. Freeze understood scope, not unresolved assumptions.
  4. Use the narrowest check that can disprove the current hypothesis.
  5. Measure repeated work and handoff gaps, not activity for its own sake.
  6. Keep external writes and publication behind explicit authority.
  7. End with evidence a human can reproduce.

The fleet became more useful when it behaved less like a swarm and more like a disciplined delivery pipeline. Coordination is not overhead added after the agents become fast. It is the system that lets their speed survive contact with real work.