At Block, a Slack request can become a tested code change through Builderbot, a company workflow built on the open-source Goose agent. A separate project, Buzz, explores how people and several agents can share work. The public accounts cover both a deployed coding system and experiments in coordinating agent teams.
What are Goose, Builderbot, and Buzz?
Goose is an open-source agent that began inside Block. It is model-agnostic, meaning teams can connect it to several model providers. Goose can read and change files, run tools, use Model Context Protocol (MCP) extensions, follow reusable recipes, and delegate to smaller agents. MCP is a common way for an agent to call approved tools.
Builderbot is Block's organization-scale coordination layer built on Goose. A team can mention Builderbot in Slack, provide a ticket, follow the same research, plan, and implementation thread, then receive a branch and pull request. The system watches continuous integration (CI), the automated build-and-test process for proposed code, and can iterate on feedback. In its rollout account, Block reports more than 200,000 operations per day, roughly 1,500 merged pull requests per week, and about 15 percent of production code changes.
Buzz is a self-hostable workspace and experimental code-hosting and review system for people and agents. It combines channels, projects, issues, repositories, review, automation, and durable memory. In the launch account, Block says its team built Buzz and wrote the post inside Buzz. That establishes use by its own builders, without showing company-wide adoption.
How does Builderbot turn a request into software?
A request can begin in a shared Slack thread or a Linear or Jira ticket. Builderbot researches the codebase, proposes a plan, implements the change, creates a branch, opens a pull request, observes CI, and responds to feedback. Teammates can watch and steer the work in the same conversation.
Block keeps company knowledge close to the code through nested AGENTS.md instruction files and reusable skills. Specialist review agents can inspect architecture, security, operations, or other risks in parallel. Repeatable repository checks run before a change is uploaded and again in CI. Block's review account says a person gives the final approval.
Builderbot operates on source code and configuration rather than customer data, payment information, or personally identifiable information. Authentication and data boundaries stay outside the model's judgment.
How does Block test agent behavior?
Block publishes a layered testing pyramid:
- Deterministic tests use mock models for retries, tool schemas, maximum turns, extensions, and subagents.
- Record-and-replay tests check the sequence of model and tool interactions without requiring identical prose.
- Probabilistic benchmarks run several times and report success rates.
- Model judges and a live self-test add another signal.
- Human validation remains above the automated layers.
Block keeps live-model tests out of CI because they are slower and variable. This is a useful distinction between tests, which should be repeatable enough to block a change, and evals, which measure probabilistic behavior across repeated runs.
What does Buzz add?
Buzz addresses the coordination bottleneck that appears when one person runs several agents. Agents get their own digital signing keys. A human signs a narrowly scoped authorization, and agents sign their work. The resulting history can show who authorized, uploaded, reviewed, approved, or merged a change and whether that record was altered.
Signed provenance establishes attribution. It does not make the work correct or the permission safe by itself. Block's launch account describes Buzz as experimental.
In a published Buzz comparison, a Block engineer reports that a coordinator, one to ten workers, and an independent verifier helped migrate more than 2,000 apps and projects. None of the 12 team configurations beat the equivalent solo agent on price-performance for the short benchmark tasks. Agent teams helped long, parallelizable work and added overhead to small work.
What has Block learned about risk?
Block publicly red-teamed Goose through a simulated prompt-injection attack that compromised an employee laptop in the exercise. Red teaming means testing a system by deliberately trying to break or misuse it. The company responded with stronger activity records, event correlation, and incident runbooks. Its account says coding agents cannot reliably isolate every piece of untrusted context.
The practical boundary is clear: authenticate outside the model, sanitize and limit inputs, monitor behavior, prepare incident response, and keep testing the system as an adversary would.
Where do agent teams help?
Block's accounts suggest different designs for different workloads. Builderbot supplies a familiar path from a ticket to a reviewed change. Buzz's reported comparison points to a reason to add workers: a long job with parts that can run in parallel. Short tasks may finish more cheaply with one agent because there is less work to spread across a team.
The public Builderbot repository and Buzz repository are Apache-licensed. Public evidence does not establish that either repository contains the complete internal production service. Block's scale and time-saved figures are company reports, not independent audits.