Block has built its internal software factory in layers. Goose gives individuals an open agent engine. Builderbot coordinates work across the company codebase. Buzz experiments with a shared room where people and several agents can work, review, and remember together.
What are Goose, Builderbot, and Buzz?
Goose began inside Block and is now an open-source agent. 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 newer 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 dogfooding, or use by its own builders. It does not establish 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. The public Projects feature is under Experiments, and Block describes Buzz as early and rough.
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.
What can a product team copy?
Build the layers in order. Prepare repositories and reusable skills. Give individuals a bounded agent. Add shared intake and coordination once repeated work appears. Keep repeatable checks and specialist review around the agent. Add multiplayer coordination only when parallel work creates a real coordination problem.
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.