Build a staged agent pipeline for PRs

Create a multi-step system that assigns issues, tests changes, and leaves the final merge to a person.

Done with Custom agent· Advanced

What they did
They described a software-factory pattern with five parts: selecting work, keeping each run separate, giving agents access to the right tools, checking the output, and deciding whether to merge. The example pulled ideas from Stripe, Spotify, Shopify, and Ramp, and used an issue rule, one worktree per agent, a shared MCP tool setup, a screenshot-checking step, and merge rules with different levels of permission. A human made the last call.
How it went
Data from Microsoft’s dotnet/runtime project showed agent-made PRs merging 67.9% of the time, versus 87.1% for engineers. In fully autonomous runs, that fell to 55.1%. Review time became the constraint, and the best results were mainly on repetitive migrations.
Tips
Put the checkpoints in place before scaling up the agent pool, and begin with the step that creates the most rework. Worktrees start with no .env file, no installed dependencies, and no open port, and unattended runs do not tidy up afterward.

Try it yourself with Codex

For [repo name], design an agent workflow that picks up issues labeled [label], works in its own isolated branch or worktree, makes the needed code changes, runs tests, and opens a pull request. Add a second pass for review, then stop before any merge, deletion, submission, payment, or other irreversible action and ask for my approval. Include the configuration, the decision rules for merging, and a short explanation of how the process runs.

Fill in the [brackets]. Agents can make mistakes, so review anything before it is sent, paid or deleted.

Read the original on firecrawl.dev ↗

Get 3 agent uses like this every morning

With the day's top AI news. Free, and one click to unsubscribe.