A Factory Is Queues and Gates, Not a Smarter Agent

In August, Spotify merged roughly 17,000 changes in a month, up from roughly 8,100 a year earlier (Spotify Engineering, observed 2026-10-28). The extra volume travelled the same path as before: automated checks, a review, a release with a few deliberate stops. Then the monthly incident retrospective began producing an awkward finding. Spotify's own write-up says change volume grew faster than its review, testing, rollout, observability and rollback controls could adapt. One automated dependency upgrade passed every check and still broke the app for real users. The company did not blame the agents: it reports that no reviewed incident has AI-written code as a material direct cause so far, and its rework metric did not rise. The weakness was in the route. More work arrived at stages sized for less, and nothing in front of those stages decided what was allowed to arrive. The bill was production failures that the checks had already waved through, plus a list of controls bolted on afterwards. Decide now: you have budget for one change this quarter. Do you add more agents, or a gate?

This lesson gives you factory/line-map.md - your delivery line as stages, queues, gates and the named approver for each gate. It serves the Slice stage of the course loop (Slice, Gate, Run, Wrap, Prove): before you cut any release into work, you draw the line that the work has to travel through.

What is actually going on

Start with what a delivery line is. Work moves through stages: someone decides what to build, something builds it, someone reviews it, it merges, it reaches staging. Between two stages the work waits, and that waiting place is a queue. A gate is a check that decides which waiting items may leave the queue. An approver is the named person who answers for that check. Every team already has all four. Most have never drawn them, so the queues are invisible and the gates are habits.

A line moves at the speed of its slowest stage. A better model speeds up the build stage. If the next stage is a human review with a fixed number of hours in a day, the line speeds up only until the review queue fills, and after that every extra change just waits longer. Anthropic describes exactly this about its own engineering: with most of its merged code now written by Claude, it names human review as the new bottleneck, and it runs an automated Claude reviewer over every proposed change before merge (Anthropic Institute, self-reported, observed 2026-10-28). Look at where that reviewer sits. It is in front of the scarce queue, not beside the builders.

People are a queue with a hard limit of their own. OpenAI reports that most people can supervise three to five interactive agent sessions before switching between them starts to hurt (OpenAI, self-reported observation, observed 2026-10-28). Treat that as one company's observation about one person's capacity as a stage, not as a study.

The same skeleton appears in every published factory. Stripe's agents work on isolated machines, pass automated checks, then wait for a human reviewer. OpenAI's Symphony spec turns ticket states into the queues. One open-source pipeline splits an intake queue, a build queue and a merge queue, each with its own check on the way out. The diagram draws the generic version; look for three queues and a check on every exit.

The picture shows why "agent or gate?" has an answer. The build stage widens cheaply. The queue exits do not, because each exit is a judgment. Widen the build stage without a check on the next exit and you have made a queue longer, not the line faster. Anthropic's own write-up on running its engineering org tracks PR cycle time next to how many commits Claude helped with, and it warns that throughput alone is not success (Anthropic, observed 2026-10-28).

The rule and its condition

Use an agent where a queue in front of a stage is the measured bottleneck and the gate behind that stage can check what comes out. Add a gate before you add throughput. Otherwise leave the stage alone and fix who owns clearing the queue.

The condition is observable in your own system. For each queue you can read the age of its oldest item and name who clears it. If you cannot read the age, you do not know where the bottleneck is, and an added agent is a guess. If you cannot name the approver, the gate is decoration: when it lets something bad through, nobody's job is to change it.

A queue without a gate is a pile; a gate without a name is a wish.

The naming applies to automated gates too. A linter has an approver: the person who owns its configuration and answers when it misses. You do not need a human to look at every item. You need a human to own every check.

Spotify's retrospective is the working example of the second row arriving late: the company added questions to its incident reviews about whether volume overloaded review, testing and rollout, after the volume had already landed (Spotify Engineering, observed 2026-10-28).

The fleet-side version of this argument, with review throughput as the ceiling on everything, is Agent Fleets, lessons 1 and 11. Whether a task deserves a loop at all is Loop Engineering, lecture 2; this course starts after you have said yes.

Worked case

Stripe publishes the most detailed line of any company in this course's sources. Read the facts first, then draw them.

An engineer starts a "minion" by tagging a Slack app in a thread, or from a command line, a web page or a ticket button. Deterministic code, with no model involved, gathers context from the links in the thread before the agent begins. The agent then works on a pre-warmed isolated machine that starts in about ten seconds, holds no production data and has no internet egress, which is why it can run without confirmation prompts. Linters run on every push in under five seconds, and CI draws on a suite of more than three million tests (Stripe, self-reported, observed 2026-10-28). If CI fails and no autofix applies, the agent gets one more attempt; after the second CI round the run stops and a human takes over. The result is a drafted PR. The engineer who launched it requests review from another engineer, and humans review every minion PR (Stripe, observed 2026-10-28).

Read it from the top: the first half is cheap and automatic, and everything that can fail loudly fails before a person is asked to look. Only the PR gate depends on human hours.

Decide now. Leadership wants twice the output from this line next quarter. You can (a) double the devbox capacity and the number of runs, (b) add a pre-review gate in front of the human review queue, or (c) do nothing until you have measured how old the oldest PR in that queue is. Which comes first, and which one do you refuse for now?

Here is the reasoning. Devboxes are treated as disposable machines, so the build stage widens at the cost of compute. Human review does not widen at all. Doubling the runs doubles arrivals at the one queue whose capacity is fixed, and the posts publish no number for how long that queue is. That reading is mine, drawn from the published design; Stripe does not say it. So you do (c) first, because it is free and tells you whether the bottleneck is review or something else. If review is the oldest queue, you do (b): a second automated screen, such as an independent review of the diff, owned by a named person, so that humans see fewer broken changes. You refuse (a), because it adds arrivals to the queue you have not yet read.

Illustrative composite. Say four reviewers each clear ten PRs a day, forty in all. Doubling the runs takes arrivals from forty to eighty a day. The review queue then grows by forty a day, and after a week about two hundred eighty PRs are waiting, each older than the one before. Nothing in the build stage would show it, which is why the line map has an age column for every queue.

Now write the line down. This is the deliverable, filled in for the line as Stripe published it. Cells marked "not published" are unknowns, not blanks.

Notice that the named-approver column is the hardest to fill and the most useful. For your own line, put a real name in every cell, and put "none" where you find a gate nobody owns. That cell is your first finding.

Faded case

Skip to the open case if this is familiar. OpenAI's Symphony spec draws its line with ticket states instead of machines (OpenAI, observed 2026-10-28). A human moves a ticket from Backlog to Todo; Backlog is explicitly out of scope for agents. The agent moves it to In Progress, keeps a single running comment as its record, runs any validation plan the ticket carries, and attaches a PR with proof of work: CI status, review feedback and a walkthrough. Then it hands the ticket to Human Review. A human approves by moving the ticket to Merging. The agent must follow a land procedure at that point and must not call a raw merge command itself. If a reviewer asks for changes, the ticket goes to Rework, the agent re-plans and sweeps the feedback, and the ticket returns to Human Review. Done is terminal. Anything the agent discovers outside its task becomes a new Backlog ticket instead of widening the current one.

Fill in the same line map for this ticket line. Classify each state as a stage or a queue, list the gates, and name the approver of each. One gate is not a human, and one transition is easy to miss because it is a refusal, not a move.

Open case

Illustrative composite. A six-person team runs this line. Product posts tickets in a shared channel. Agents pick them up and open pull requests. Two senior engineers review every PR, and a PR merges the moment its tests are green. Merged changes go straight to production on Fridays. Last month the team doubled its agent count. PR volume rose sharply. The two reviewers now report that their oldest waiting PR is eleven days old, and two production incidents came from changes approved in a hurry. Leadership offers to double the agents again.

Draw this line on one page: its stages, its queues, its gates and the approver of each gate. Then say what you add first and what you refuse to add yet. The quiz grades your choice.

Where this breaks

No denominators. This course quotes no company's merge rate, and you should not either. Stripe says its agents produce over 1,300 merged PRs a week, self-reported, but it publishes no share of all PRs, no merge rate and no revert rate (Stripe, observed 2026-10-28). Spotify's doubling counts all merged changes and cannot be split into agent-written and human-written. A count without a denominator tells you the line is busy, not that it is safe.

Vendor volume figures mix scopes. Anthropic reports that more than 80% of its merged code was written by Claude as of May 2026, self-reported with the method not verified (Anthropic Institute, observed 2026-10-28). Other Anthropic pages quote different shares for different scopes. Never put two of them in one chart.

A drawn line is a model, not a measurement. The map shows where you think queues are. Only the oldest-item age shows where work is stuck, and it needs data your tooling may not collect yet. A map also rots: the first reorganisation or new tool changes the line, and the file goes quietly wrong.

Gates can be theatre. A named approver who stamps what arrives is a gate in name only. Naming is the first step, not the last; later lessons say what makes a gate hold.

Key Takeaways

• Draw the line before changing it: stages, queues between them, and a gate on every queue exit.
• Add an agent only where a measured queue is the bottleneck and the next gate can check its output.
• Put a gate in front of the scarcest queue, usually human review, before raising volume upstream.
• Name one approver per gate; for automated gates, name the owner who answers when it fails.
• A queue without a gate is a pile; a gate without a name is a wish.
• Quote throughput only with its denominator and its source, or leave the number out.

What You Have Now

factory/line-map.md - your delivery line as stages, queues, gates and the named approver for each gate. It is the first file of the factory/ directory you build across this course, and it holds the oldest-item age of every queue, which is the number that tells you where an agent belongs. Lesson 2 splits a release into work that fits this line, and Lesson 3 sets how much of the line may run unattended. This is the Slice stage: you cannot cut work well until you know the route it will take and who can stop it on the way.

Further Reading

• Spotify Engineering, "AI changed how Spotify builds: what we learned and fixed about quality at higher velocity": the company's own account of volume outrunning controls, including what it found and what it did not.
• Stripe, "Minions: Stripe's one-shot, end-to-end coding agents" (part 1): the trigger, devbox, blueprint and review steps in the order they run.
• Stripe, "Minions" (part 2): the CI-round cap and the feedback-left-shift detail, with Stripe's own scale figures.
• OpenAI, "Open-source Codex orchestration: Symphony": a line drawn as ticket states, with human review and merging as explicit states.
• Anthropic Institute, "Recursive self-improvement": a vendor's report that review becomes the bottleneck when authoring gets cheap.
• Anthropic, "Running an AI-native engineering org": process changes as part of the factory, and the case against judging by throughput alone.

Exercises

1. Draw your line from the last ten merged changes. For each, note where it waited and for whom. List the stages and queues you find, even the ones nobody named.
2. Fill in factory/line-map.md for your own line. Write the oldest-item age for every queue (use "unknown" if you cannot read it) and a real person's name beside every gate. Mark any gate with no owner as "none".
3. Pick one agent your team is considering. Name the queue it feeds, the stage it speeds up and the gate that will check its output. Decide whether to add it now, add a gate first, or defer, and write the evidence that would change your mind.

Check your understanding