A multi-agent orchestration layer built on goose + MCP that coordinates agents across Block's entire codebase, invoked in Slack to take a ticket end-to-end to a reviewed PR.
Anyone tags @builderbot in Slack with a short description and it researches, plans, and implements in that thread while teammates steer in real time[Source 1]
Ticket-driven flow
Linear/Jira ticket → branch → code → PR → CI watch, end to end[Source 1]
Where people stay involved
People review, approve, or guide the agent’s work here.
Reported: Colleagues steer runs in the Slack thread; the engineering post adds that humans grant the final stamp of approval on pull requests (lines 46, 50).
Not reportedThe captures name the goose orchestration framework but no underlying model; the public repository README names apps and crates only.
Harness
Multi-agent orchestration built on goose (open-source agent framework) + MCP; multi-player, real-time, operating inside Slack threads[Source 1]
Sandbox
Not reported
Tool access
MCP connects agents to internal tools and data; picks up Linear/Jira tickets, creates the branch, writes code, opens the PR, watches CI[Source 1]The launch post also limits operation to source code and system configuration, with no customer data or PII.
Knowledge
Company-wide code context across hundreds of millions of lines and hundreds of services; Block also frames Builderbot as an 'agentic protector' around its software world model[Source 1, Source 2]
Context management
Progressive disclosure pairs a global world model with hyperlocal context through nested AGENTS.md files, module-scoped .agents/checks review prompts, and hundreds of internal Agent Skills from an internal Skills Marketplace[Source 2]
Credentials
Not reportedCredential handling is not documented; the source-code-only boundary is a data restriction, not a credential mechanism.
Interfaces
Slack, Linear, and Jira are named in the launch post; the pull-request host is not named in the captures.
Coordinates multiple agents over one codebase instead of running a single loop[Source 1]
Review protector gate
The sq agents review entrypoint dispatches parallel global and module-scoped review subagents against a pull request and verifies world-model alignment before humans grant final approval[Source 2]
Validation and failure handling
CI watch and iteration
After opening the pull request, Builderbot watches CI and iterates based on feedback; humans step in where they add the most value[Source 1]
Reported observations
These results come from the sources. Notes below each result explain what it covers and any reported limits.
Headline claim
~1,500 PRs merged per week (~15% of all production code changes at Block)[Source 1]
Reported by
Block
Scope
Builderbot merged pull requests per week at Block
Denominator
All production code changes across Block for the approximately 15% share
About this result
Category
Adoption output
Evidence type
Reported measurement
What it covers
Builderbot merged pull requests per week and their share of Block production code changes
Reported: Colleagues steer runs in the Slack thread; the engineering post adds that humans grant the final stamp of approval on pull requests (lines 46, 50).
implementation
Reported
validation
Reported: The launch post documents CI watch and feedback iteration; the pre-push just checks in the engineering post cover local agents generally and are not tied to Builderbot's runs.
