What is Block’s Berd? The open-source desktop workspace for AI agents

How Berd connects different agents

Berd uses the Agent Client Protocol, or ACP, as the interoperability layer between the desktop client and agent harnesses. The goal of ACP is to avoid a separate, bespoke interface for every agent: an ACP-compatible harness can communicate with a compatible client through a common protocol. Berd reporting describes Goose, Claude Code, Codex, and other tools as part of this interchangeable workflow.

In practice, Berd is an interface and coordinator, not a universal replacement for every provider’s setup. Goose can be used as Block’s bundled or closely integrated runtime, while Claude Code and Codex still rely on their own installations, accounts, subscriptions, or credentials. The selected agent also determines which model provider receives prompts, code, and tool outputs.

Architecture and operating-system support

The reported stack combines Tauri 2 with a React 19 front end. That produces a desktop application rather than a browser-only workspace, with builds available for macOS, Windows, and Linux.

This distribution model makes Berd suitable for developers who want project files and agent sessions alongside their normal local development environment. It also leaves users responsible for the usual desktop concerns: installing updates, managing local permissions, configuring agents, and protecting credentials.

What “local-first” privacy means

Berd’s local-first design means the application and its project or conversation history are stored locally rather than in a hosted Block workspace. That is a meaningful privacy boundary, but it should not be confused with fully local AI processing.

When an agent uses a cloud model, remote API, or external tool, the relevant prompts, source code, files, and tool results may still leave the computer. Privacy therefore depends on the selected harness, model provider, tools, and configuration as well as on Berd itself.

The available material does not establish a definitive Berd telemetry policy or identify a specific operating-system credential vault or keychain implementation. Anyone evaluating Berd for sensitive work should verify those details in the current repository’s security and privacy documentation before deployment.

Is Berd free, and what does it cost to use?

Berd itself is free to use under the Apache-2.0 license. That does not make every agent interaction free. Users generally bring the subscriptions or API keys required by the model and harness they choose, and those providers may charge for usage.

The practical cost model is therefore split:

• Berd: open source and available under Apache-2.0.
• Agent runtime: may be bundled, installed locally, or configured separately depending on the harness.
• Model access: may require a provider subscription or API key.
• Usage: may generate separate charges from the selected model provider.

What enterprise “distribution seams” mean

Berd appears designed first as an individual, local-first developer tool, not as a finished enterprise administration platform. The phrase “distribution seams” describes the operational work needed to move from a useful desktop application to a centrally managed company product.

Those boundaries can include managed installation and updates, identity and access controls, credential provisioning, network and proxy policies, audit logs, support, and organizational rules for agent actions. The available evidence does not show that Berd already provides a complete layer for all of those requirements. Enterprises should treat those capabilities as deployment questions to validate, not as implied features of the Apache-2.0 release.

Why does the repository close external pull requests?

An automatically closed external pull request is a contribution-process decision. It may indicate that maintainers want proposed changes discussed through issues first or that the public repository mirrors an internal source of truth.

That behavior does not cancel the Apache-2.0 license: people can still inspect, use, modify, and fork the code under the license terms. However, the provided evidence does not establish Block’s precise reason for closing external pull requests. It would be speculative to attribute the policy to security, licensing, or opposition to outside contributions.

Berd versus Buzz

Berd and Buzz address different collaboration levels.

Berd is the individual desktop workspace. One person uses it to direct agents across local projects, files, skills, and sessions.

Buzz is the collaborative workspace. Block launched Buzz on July 21, 2026 as a shared environment where humans and AI agents communicate. Its design emphasizes persistent project identity, permissions, and history even when the model or agent harness changes. Buzz supports Claude Code, Codex, Goose, and other ACP-compatible agents.

Buzz can also be configured with a self-run relay, including a relay running locally or on infrastructure controlled by the operator. That means the collaboration layer does not inherently require Block-hosted infrastructure, although deployment and security responsibilities shift to the operator.

The two projects are related by their model- and harness-neutral approach, but the available material does not establish a planned Berd–Buzz merger or a shared future product roadmap.

What Block has—and has not—announced about Berd’s future

Block’s public framing positions Berd as an adaptable workspace spanning projects, tools, skills, models, and agent runtimes rather than as a Goose-only interface. That interoperability is the clearest direction supported by the available evidence.

There is not enough confirmed information here to state a roadmap for enterprise administration, telemetry commitments, pricing changes, or a formal Berd–Buzz integration. Those questions should remain open until Block documents them in the project repository or a future announcement.