Running AI agents like an engineering team

The premise

Most AI-assisted engineering is one person prompting one agent in one branch. That scales to the speed of a single reviewer. The interesting constraint was never generation. It was coordination and verification.

So I built the coordination and verification layer first and let throughput follow. What follows is the surviving version of that loop, including the parts I deleted.

The topology

The loop has three kinds of actor. The standing session is the one long-running conversation I actually talk to. It owns the backlog, sequences work, dispatches everything, watches CI, and controls every merge. It carries one hard prohibition: it never writes warehouse code or SQL itself. The moment an orchestrator starts building, it loses the thread of the queue and starts marking its own homework. Separating "decides what happens" from "does the work" mattered as much for agents as it does for people.

Worker agents are background sessions spawned with a written brief. Each gets a throwaway git worktree and a descriptively named branch: one task, one worktree, one branch. Workers commit but never push, so the standing session controls push timing and CI runs land in a deliberate order instead of a stampede.

Reviewer agents are spawned fresh, with clean context, one per review. A reviewer that watched the code get written inherits the builder's assumptions. A reviewer holding only the diff, the rubric, and repo access has to reconstruct the reasoning, and that reconstruction is where defects surface.

The work-order brief

Delegation quality is brief quality. A worker sees nothing but its brief and the repository, so briefs are written like a work order for a contractor who starts in five minutes and cannot call you back: the task in one sentence, the branch name, context the worker cannot rediscover, acceptance criteria as observable outcomes, the validation venue, and bounded fallbacks.

Two habits paid for themselves. Every factual claim in a brief is labeled either verified against the live system just now or inferred, and workers re-verify the inferred ones before building on them. Stale premises cost more agent-hours than bad code did. And every brief ends with the same demand: report every unspecified change you made, and anything you had to discover that this brief should have carried. That line is how the briefs improved.

Parallelism is decided by file overlap, computed before dispatch by diffing candidate task file lists. Non-overlapping tasks dispatch concurrently. Work in progress stays capped at two write-capable builders plus one reviewer or investigator, however large the backlog. I tried more, and coordination cost ate the gains.

The merge gate

Nothing reaches main without green CI on five required checks, a review verdict posted as a pull request comment, and my explicit acknowledgement on a ship summary. The posted verdict is the merge token: if the comment is not on the pull request, the merge does not happen, no matter what any session claims in chat. Durable state lives on GitHub, where it can be checked. Chat is not a system of record.

Reviews are sized by risk. Routine diffs get one merged review applying two rubrics, a craft pass then an adversarial pass. Security-relevant code, meaning anything touching grants, row filters, or access-control config, gets the fully sequenced version: two separate fresh agents, craft first, so the adversarial reviewer reads conventions-clean code. When a diff changes model or load logic, the review adds a read-only reconciliation against production aggregates, which caught more real defects than any other single instrument.

One honest caveat that most agent-workflow writing skips: agent review is independent reasoning, not independent authority. Every agent in the loop acts with my credentials. The separation of duties is me, at the merge acknowledgement and at every production grant. I designed the gates around that fact rather than pretending the agents were accountable colleagues.

• Lint and SQL governance rules
• Secret scanning
• Bundle validation
• An execution gate that builds the models against the dev catalog
• Tests

Deleting my own process

The loop above is the version that survived. Earlier versions carried more ceremony, and the most useful thing I did in week six was audit and delete much of it.

I had run two standing sessions, one for priorities and one for execution, with defined protocols for how they messaged each other: an elegant org chart for a team of zero humans. I merged them into a single session with two registers and deleted every seam protocol, because each seam was coordination overhead with no referent in a one-person world.

Three days later I replaced per-dispatch approval with an outcome envelope. The session proposes one screen at the start of the day: at most two active outcomes with observable done-conditions, one fallback, what it may do autonomously, and what still stops for me. I approve the envelope once. Inside it, the session dispatches and re-ranks on its own and narrates material changes. My explicit yes stays reserved for merges, production mutations, and genuine rulings.

The same audit produced a standing budget: work on the control plane itself, new monitors, validation machinery, and process rules, is capped at roughly a quarter of active capacity, and any proposed rule must name the concrete failure it catches and the condition that retires it. Process is a codebase. It bloats the way code does, and agents will generate infinite amounts of it if you reward tidiness over throughput.

The loop runs without me

By the final month a meaningful share of the work was not dispatched by me at all. Recurring jobs ran as scheduled skills: a daily release note compiling merged pull requests into a plain-language Slack post, a weekday sweep reading the warehouse query history for consumer friction and filing deduplicated issues, and a reconciler checking the open backlog against what is actually deployed.

The hard part of scheduled automation was teaching it when not to act. The release-note job posts nothing when nothing merged. The friction sweep verifies each finding against the catalog and dedupes against issues it already filed. Every run that decides to do nothing records an explicit no-op with a reason, because a scheduled job that silently produces nothing is indistinguishable from one that silently died. I learned that distinction from the dying kind.

The loop, measured

Agent usage telemetry for the final month puts numbers on the team framing: 95 sessions, 529 hours of logged session time, 251 sub-agent dispatches, and roughly 2,800 shell commands. 529 hours is about 17 hours a day. One person cannot produce that clock time. A person directing parallel agents and scheduled jobs can.

The other telling number: the most-written file type across those sessions was Markdown, around 900 files, ahead of any programming language. Briefs, verdicts, ship summaries, decision records, day files. The orchestration layer's job is writing systems of record. The SQL was the part I delegated.

Rules with scars attached

Most of the playbook was not designed up front. It accreted, one failure at a time. None of these are hypothetical hardening; each is a specific afternoon I lost.

• Pushes fail silently through flaky SSH, so after every push the session verifies by API that the remote head equals the local head
• Parallel fetches clobber git's FETCH_HEAD, so pull request heads are fetched to private refs (found while reviewing one PR's code under another PR's number)
• Every resumed agent re-verifies its worktree before touching git, after a crash-recovered agent re-created its branch inside the main checkout
• The absence of an expected artifact is itself an alarm, after an expired credential made scheduled runs produce nothing while the health probe still reported healthy
• Failing checks are verified from the API, and two failed fix rounds on one failure class end speculative patching in favor of a bounded root-cause investigation

What transfers

The load-bearing choices: separate the orchestrator from the builders and forbid it to build; write briefs as self-contained work orders and make workers report what the brief should have contained; give reviewers fresh context and make their verdicts durable artifacts; keep the human gates at decisions and blast radius, never at keystrokes; and audit your process with the same suspicion you would audit code, because half of what you invent deserves deletion.

The result held: eleven weeks, 632 commits, 384 reviewed pull requests, 17 hours of agent time a day at peak, one accountable human, and a security posture that got stricter as the loop got faster.