Minions: Stripe’s one-shot, end-to-end coding agents

Summary

Stripe’s Minions are homegrown, fully unattended coding agents designed to complete tasks in a single run, beginning with an invocation such as a Slack thread and ending with a pull request ready for human review. More than 1,000 pull requests merged weekly at Stripe are minion-produced and contain no human-written code, although engineers review them and can provide follow-up instructions. Each run uses an isolated, pre-warmed devbox and a customized fork of Block’s coding agent goose, combining agent loops with deterministic operations for version control, linting, and testing. Minions use curated MCP tools, including Stripe’s Toolshed with more than 400 tools, to retrieve internal context before and during work. Local checks and selective CI provide feedback, with no more than two CI rounds, balancing correction against token, compute, and time costs.

Context

Stripe needed agents capable of making changes in a codebase spanning hundreds of millions of lines, a relatively uncommon Ruby and Sorbet stack, numerous homegrown libraries, and systems subject to payment, regulatory, and compliance constraints. Developer attention is constrained, while unattended agents enable parallel task execution.

Approach / What changed

Minions integrate with Stripe’s existing developer productivity tooling and can be launched from Slack, internal applications, the CLI, or the web. They run in isolated pre-warmed devboxes, use a customized goose-based orchestration loop, curated MCP tools and conditionally applied agent rules, then apply local linting, selective CI, autofixes, and limited retry behavior before preparing a branch and pull request.

Takeaways

• More than 1,000 weekly merged pull requests at Stripe are completely minion-produced, with human review but no human-written code.
• Minions combine agent-driven work with deterministic git, linting, and testing steps, and use isolated devboxes to support unattended parallel execution.
• Feedback is shifted left through local checks; CI runs at most twice, because additional rounds consume tokens, compute, and time with diminishing returns.

Related reading