---
schema: "swft.publication/v1"
id: "company-block-builderbot-buzz"
title: "Block's AI software factory: Goose, Builderbot, and the Buzz workspace"
description: "How Block combines Goose, Builderbot, agent skills, tests, human review, signed provenance, and the experimental Buzz multiplayer workspace."
summary: "Block's factory has three layers: Goose is the open agent engine, Builderbot is the mature shared workflow from Slack or tickets to reviewed pull requests, and Buzz is an early multiplayer workspace for people and agents. The layers show how individual tools can grow into company infrastructure."
canonical: "https://swft.io/companies/block-builderbot-goose-buzz"
author: "SWFT Editorial"
author_type: "Organization"
published: "2026-09-01"
modified: "2026-09-02"
kind: "case-study"
section: "Companies"
tags: ["Block Builderbot", "Block Goose", "Block Buzz", "multi-agent software development", "AI software factory"]
evidence_labels: ["INFERENCE", "OBS", "SELF-REPORT"]
source_ids: ["block-agent-red-team", "block-agent-testing-pyramid", "block-ai-assisted-development", "block-builderbot-github", "block-builderbot-rollout", "block-buzz-github", "block-buzz-launch", "block-buzz-projects", "block-buzz-teams", "block-goose-github", "block-protecting-systems"]
authorship_disclosure: "AI-drafted from the cited public sources and independently checked by a second AI editorial-review agent (Codex) for source fit, claim boundaries, overlap, and reader utility. SWFT Editorial is responsible for corrections."
---

# Block's AI software factory: Goose, Builderbot, and the Buzz workspace

Block connects an open agent engine, a shared workflow that turns Slack requests into reviewed code changes, layered tests and review, and an early multiplayer workspace.

> **Authorship:** AI-drafted from the cited public sources and independently checked by a second AI editorial-review agent (Codex) for source fit, claim boundaries, overlap, and reader utility. SWFT Editorial is responsible for corrections.

## Quick answer

Block's factory has three layers: Goose is the open agent engine, Builderbot is the mature shared workflow from Slack or tickets to reviewed pull requests, and Buzz is an early multiplayer workspace for people and agents. The layers show how individual tools can grow into company infrastructure.

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](https://github.com/block/goose). 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](https://block.xyz/inside/block-rolls-out-builderbot-a-new-suite-of-ai-native-tools-that-changes-the-way-we-ship), 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](https://engineering.block.xyz/blog/buzz), 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](https://engineering.block.xyz/blog/protecting-our-systems-with-intelligence) 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](https://engineering.block.xyz/blog/testing-pyramid-for-ai-agents):

1. Deterministic tests use mock models for retries, tool schemas, maximum turns, extensions, and subagents.
2. Record-and-replay tests check the sequence of model and tool interactions without requiring identical prose.
3. Probabilistic benchmarks run several times and report success rates.
4. Model judges and a live self-test add another signal.
5. 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](https://engineering.block.xyz/blog/effective-teams-buzz), 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](https://engineering.block.xyz/blog/how-we-red-teamed-our-own-ai-agent-) 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](https://github.com/block/builderbot) and [Buzz repository](https://github.com/block/buzz) 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.

## How we know

- **First-party report (SELF-REPORT)** Block describes Builderbot's workflow, data boundary, daily operations, merged-PR scale, production-change share, and human steering. Sources: [Block rolls out Builderbot, a new suite of AI-native tools that changes the way we ship](https://block.xyz/inside/block-rolls-out-builderbot-a-new-suite-of-ai-native-tools-that-changes-the-way-we-ship); [Protecting Our Systems with Intelligence](https://engineering.block.xyz/blog/protecting-our-systems-with-intelligence).
- **Observed artifact (OBS)** Goose, Builderbot, and Buzz have public Apache-licensed repositories; internal and public implementation parity is not established for Builderbot or Buzz. Sources: [Goose](https://github.com/block/goose); [Builderbot](https://github.com/block/builderbot); [Buzz](https://github.com/block/buzz).
- **First-party report (SELF-REPORT)** Block publishes its repository-readiness practice, agent testing pyramid, prompt-injection red team, Buzz dogfooding, long-work benefit, short-work penalty, and beta forge. Sources: [AI-Assisted Development at Block](https://engineering.block.xyz/blog/ai-assisted-development-at-block); [Testing Pyramid for AI Agents](https://engineering.block.xyz/blog/testing-pyramid-for-ai-agents); [How We Red-Teamed Our Own AI Agent](https://engineering.block.xyz/blog/how-we-red-teamed-our-own-ai-agent-); [Buzz!](https://engineering.block.xyz/blog/buzz); [Efficient Tokens & Effective Teams in Buzz](https://engineering.block.xyz/blog/effective-teams-buzz); [Projects in Buzz](https://engineering.block.xyz/blog/projects-in-buzz).
- **Analysis (INFERENCE)** SWFT treats Block's engine, orchestration, and coordination layers as an evolutionary path rather than interchangeable products. Sources: [Block rolls out Builderbot, a new suite of AI-native tools that changes the way we ship](https://block.xyz/inside/block-rolls-out-builderbot-a-new-suite-of-ai-native-tools-that-changes-the-way-we-ship); [Buzz!](https://engineering.block.xyz/blog/buzz).

## Sources

- **First-party report (SELF-REPORT)** [How We Red-Teamed Our Own AI Agent](https://engineering.block.xyz/blog/how-we-red-teamed-our-own-ai-agent-) — Block Engineering; published 2026-01-15; accessed 2026-09-01. Block's candid prompt-injection exercise and resulting emphasis on authentication outside the model, telemetry, incident response, and red teaming.
- **First-party report (SELF-REPORT)** [Testing Pyramid for AI Agents](https://engineering.block.xyz/blog/testing-pyramid-for-ai-agents) — Block Engineering; published 2026-01-12; accessed 2026-09-01. Block's layered testing approach: deterministic mocked tests, record and replay, repeated probabilistic benchmarks, model judges, and human validation.
- **First-party report (SELF-REPORT)** [AI-Assisted Development at Block](https://engineering.block.xyz/blog/ai-assisted-development-at-block) — Block Engineering; published 2026-01-18; accessed 2026-09-01. Block's historical account of repository readiness, Research-Plan-Implement practice, parallel agents, enablement, and company-reported changes in AI-authored work.
- **Observed artifact (OBS)** [Builderbot](https://github.com/block/builderbot) — Block; accessed 2026-09-01. Block's Apache-licensed experimental Builderbot repository; the public evidence does not establish parity with the full internal orchestration service.
- **First-party report (SELF-REPORT)** [Block rolls out Builderbot, a new suite of AI-native tools that changes the way we ship](https://block.xyz/inside/block-rolls-out-builderbot-a-new-suite-of-ai-native-tools-that-changes-the-way-we-ship) — Block; published 2026-06-17; accessed 2026-09-01. Block's account of Builderbot's Slack-to-PR workflow, Goose foundation, data boundary, human steering, and company-reported scale.
- **Observed artifact (OBS)** [Buzz](https://github.com/block/buzz) — Block; accessed 2026-09-01. The Apache-licensed Buzz repository, including a Block-internal build path; it does not publish organization-wide adoption.
- **First-party report (SELF-REPORT)** [Buzz!](https://engineering.block.xyz/blog/buzz) — Block Engineering; published 2026-07-21; accessed 2026-09-01. Block's launch account of the self-hostable people-and-agents workspace, signed delegation, internal dogfooding, and explicit early-stage limitations.
- **First-party report (SELF-REPORT)** [Projects in Buzz](https://engineering.block.xyz/blog/projects-in-buzz) — Block Engineering; published 2026-08-18; accessed 2026-09-01. Block's description of Buzz's experimental Git forge, signed actions, review flow, and acknowledged beta limitations.
- **First-party report (SELF-REPORT)** [Efficient Tokens & Effective Teams in Buzz](https://engineering.block.xyz/blog/effective-teams-buzz) — Block Engineering; published 2026-08-06; accessed 2026-09-01. A Block engineer's multi-agent migration and benchmark account, including the finding that no tested team configuration beat its solo equivalent on price-performance for short tasks.
- **Observed artifact (OBS)** [Goose](https://github.com/block/goose) — Block and the Agentic AI Foundation; accessed 2026-09-01. The Apache-2.0 agent foundation that began inside Block and supports multiple model providers, MCP extensions, recipes, subagents, and permission controls.
- **First-party report (SELF-REPORT)** [Protecting Our Systems with Intelligence](https://engineering.block.xyz/blog/protecting-our-systems-with-intelligence) — Block Engineering; published 2026-04-02; accessed 2026-09-01. Block's account of layered repository context, specialist review agents, deterministic pre-push checks, reviewed policy updates, and human final approval.

## Read next

- [Stripe Minions: how developer infrastructure became an AI software factory](/companies/stripe-minions)
- [Spotify Honk: adding an agent to a software factory that already worked](/companies/spotify-honk)
- [How an AI software factory works](/software-factory-architecture)