Published: 2026-11-10
Summary

One manager agent over up to 20 builder agents: ticket board, a 15-minute automation, a three-pass review loop, video proof and a merge manager

Chapters / key moments (click to jump — plays here on the page)

A conference talk from a founder whose company sells to family law firms. The agents run in the cloud in Devin, but the structure does not depend on that product. It is one company's current practice, described by the speaker as likely to change within a week.

Source video

"How One Founder Manages 20 AI Coding Agents at Once - Ryan Carson, Untangle" by AI Engineer — Watch on YouTube → The speaker names Devin as his harness; the roles below are generic sessions, as he says himself.

The structure

  1. Humans at the top set priorities and talk to customers.
  2. A manager agent is just a session (he names it "engineer manager") that never writes code. He talks to it, mostly by voice.
  3. The manager works from a ticket board (Linear here). One ticket should be one pull request, and the manager pulls tickets by dependency.
  4. One manager runs about 5 to 25 builder agents at once, about 20 typically. The limit is how much you can follow by talking to the manager. You never open or talk to the builder sessions directly.
  5. An automation forces the manager to read every child session every 15 minutes (the setting says 10, he settled on 15) and push things along. It is a scripted automation, because the manager cannot be trusted to do this on its own.
  6. Each builder calls a review agent and loops at most about three times. If important bugs remain after three passes, the problem bubbles up to the manager and, if needed, to a human.
  7. A QA agent runs as a child of the builder. He says agents are cheap enough to spin up freely as long as they do not hold up the merge queue.
  8. Every builder records a video of the feature being used and its tests passing (a built-in test feature in Devin; build your own if your harness lacks it). A human product owner has to watch it before shipping.
  9. A merge-queue manager coordinates the wave of PRs, for example database migration numbers that agents would otherwise collide on. They also use GitHub merge queues.

Across a team

  • With about 10 people, each has one or two engineering-manager sessions, and the sessions message each other. He says this is built into Devin and probably into whatever harness you use, and that allowing it is important.
  • He argues against local development: coding with a cloud agent is what makes this possible.
  • His advice on the video step: it is the one place not to cut corners. On a phone he could not see the video well enough and was tempted to approve it anyway.

How they hire (the speaker's method)

  1. No pre-screens or video calls at first, because they bias the decision. The only question is whether the candidate can operate an agent.
  2. Candidates submit a roughly 45-minute full-screen recording of shipping a feature (a PR) on an app they already maintain, with no instructions.
  3. The videos go to a ranking agent that watches them and stack-ranks the candidates. He first ignored its top pick and later thought it had been right.
  4. The top five are paid a fixed fee for a 16-hour project, under an NDA with the screen recorded, to get a real PR ready to merge, and those videos are ranked too. He watched all 16 hours of the last round himself.
  5. A call happens only with the finalists, at the end.

Caveats

  • One company's practice in one product area. The numbers (20 builders, 15 minutes, three review passes) are his tuning, not recommendations.
  • He expects the process to be obsolete within a week; read it as a snapshot.
  • Candidate videos fed to a model raise privacy and consent questions that the talk does not address.
  • No commands or configuration files are shown; the reproducible part is the structure above.