Everything I build ships through one factory: seven live products and the factory itself. Each agent works its own line: patchrelay from Linear, Claude Code and Codex from sessions I start. Every pull request now goes through review-quill, and merge-steward merges all of them into one queue. The figure below is a simulation, not a live feed.
Fig 1Software factory · three lines, one queueruns on its own · point at a machinewarming up
Issue card, then pull request; the heavy outline is the one followedStacked candidate, built on the one below; its gauge fills as CI runsGreen CIChanges requested: lifted back to its machine. Red in the queue: repaired in placesimulated ·
Stations
01
Intake
Issues live in Linear. Delegating one to the patchrelay app lets it write the feature; undelegating pauses it. Once a PR is approved and green, patchrelay may still repair its merge candidate, never the branch.
I triage and plan in an ordinary Claude Code or Codex session: split the work into issues and set blockedBy between the ones that touch the same ground. When patchrelay picks an issue up, a short Codex pass only decides whether it is implementation or an umbrella that coordinates child issues.
One durable worktree per issue. patchrelay drives Codex straight from Linear; I pick up the rest in Claude Code or Codex. Every path ends in a pull request.
review-quill checks out the exact head, reads it against the repo’s REVIEW_WORKFLOW.md, and posts a plain GitHub approve or request changes. Requested changes come back as a review_fix run when patchrelay wrote the code, or land in the waiting ship-pr session when I did.
merge-steward admits a PR approved on its exact head with green checks, then builds future-main candidates, each on top of the one ahead, and runs CI on those SHAs in parallel. A candidate that conflicts with the ones below, or goes red, is repaired in place on its candidate ref, rechecked by a narrow integration review, and tested again; the approved PR head stays frozen, and nothing is stacked on a conflict until it has a candidate.
Landing is a fast-forward of main to the SHA that passed. If main moved first, the candidate is rebuilt on the new tip and tested again, not reviewed again.
A push to main runs the repo’s own Actions: stage and production on Cloudflare Workers, from the same SHA at once. On UserTold each runs a smoke test, and the issue is Done only when both pass.
UserTold interviews the people using what shipped. Interviews become evidence, evidence becomes findings, and the findings I send land in Linear’s Triage as the next work on the line.
Every repair loop (review_fix, ci_repair, queue and integration repair) has a budget, ten tries each on my repos. When one runs out, the issue moves to Human Needed. The agents are told to stop and ask before touching auth, migrations, bindings or dependencies.
Eleven frozen cases from seven PRs in UserTold, MakeFX, Inventory and Subtitles, replayed through the real prompt in a throwaway worktree. Each is graded on the verdict, how many concerns it raised, no nits where none belong, findings anchored to changed lines, and required or forbidden markers.
patchrelay has no model eval yet. What it has around it is 34 merge-steward scenario suites (speculative cascades, a CI failure mid-chain, crash recovery, a broken main) and 134 test files in its own repo.
pull requests merged across 11 repositories, the products below added up
6,863
of them reviewed by review-quill and landed by merge-steward
83%
review passes; about half asked for changes
14,284
written by agents in the last 30 days
96%
from a person’s accountby patchrelay (Codex)by agent sessions I start6,841 merged since March by people and agents; 14 bot PRs and 8 from 2025 are left out.
Since Opus 5.5, a Claude Code session carries an issue to a pull request on its own, and those sessions have taken over most of what patchrelay’s Codex runs used to do: in October every agent PR came from one. The delivery pipeline stayed. Review, the merge queue and the deploy are still what land the work, whoever wrote it. The spring and summer peak includes building two products twice; both first versions are still counted.