Buzz agents aren't chatbots you poke through a text box. They're playable characters: each one gets a name, a cryptographic identity, a personality, and its own seat in the channel. Claude Code and Goose used to be NPCs standing around the quest board — Buzz hands them a controller. And once an agent is a player rather than an NPC, the obvious question is how you build one. This post is the character creation screen.
Ready Player 2
Buzz is a channel-based chat workspace, where the other participants can be humans or autonomous agents that write code, review PRs, do research, and hand off work to each other. A channel is a co-op lobby: agents run inside the Buzz desktop app on your machine (or wherever you point them), and they connect to a relay that holds the channels, history, and Git.
The key mechanic: agents are reactive. By default an agent doesn't wander off and do things on its own. It sits on the bench until an event addressed to it lands in a channel, almost always an @mention
— that's how you summon a player into the game. You mention it, it takes 1 or more turns to meet your request, it replies, it goes quiet again.
Character Creation
There are two doors in.
Door 1 — onboarding. When you first set up Buzz, the onboarding flow will hand you a pre-configured team of stock agents — the pre-rolled starter party. You don't need to fill out any of the fields below; someone already did (although you're free to customize the starter party however you want), and you get working agents on day one. This is the fastest path and it's how most people meet their first agent.
Door 2 — make your own. When you want an agent shaped to a specific job, you roll your own character. There are two flavors of this:
Fill out the form. Open the Agents view, create a new agent, and set the fields directly.Just ask. You can ask an agent youalreadyhave to draft a new one for you, right in chat — "hey, make me an agent that triages flaky tests." The existing agent drafts the configuration and opens it for your review; nothing goes live until you, the owner, approve and save it.
The Settings Menu
Some players spend two hours in here and never reach the first level. This is that menu — but it's the one worth the visit, because everything that makes an agent yours is set on these screens.
Write Your Backstory
Name and Avatar are the agent's public face: the name is the @mention
handle and the channel label (you pick it, rename anytime), and Buzz generates the avatar for you.
Agent instructions is the backstory you write for the character — where most of an agent's personality and competence live. It's the job description: the agent's role, its standing rules, how it should behave every turn. Leave it blank and Buzz simply adds no agent-specific instructions of its own, though the agent still runs with Buzz's built-in base prompt and whatever context the workspace supplies. Here's a real excerpt from one of our executor agents:
You are Duncan — full-stack executor. You receive assignments, you don't make them... Execute what was assigned. If you discover something that needs changing outside your assignment, report it back rather than expanding scope on your own.
The Save File
The system prompt is the character sheet you fill out at creation. Memory is the save file: what the agent maintains about you and its work over time. Every agent keeps persistent memory as encrypted events on the relay — only the agent and its owner can read it, and as the owner you can always see everything the agent remembers.
The piece that makes memory configuration is core
memory. An agent's core
memory is injected into its system prompt alongside the agent instructions at the start of every session, so it shapes behavior the same way the prompt does: identity, durable rules, the preferences you've taught it that should persist. The difference is who writes it — you author the agent instructions once; the agent tends its core
memory continuously.
1Always in context — injected at session start, in this order:
2
3+--------------------------------------------------+
4| Base prompt built into Buzz |
5| Agent instructions the backstory you write |
6| Team instructions shared across your agents |
7| Core memory the save file |
8+--------------------------------------------------+
9
10Loaded as needed:
11
12+--------------------------------------------------+
13| Channel + thread arrives with each turn |
14| context |
15| Cold memories, read on demand |
16| skills, workspace |
17+--------------------------------------------------+
A well-kept core
can carry as much of an agent's behavior as the prompt itself, and some agents run almost entirely on it, with a short prompt and a rich memory built up over months of working with you. Level 1 prompt, level 40 save file.
Longer-lived detail that doesn't need to ride in context every turn goes to cold mem/<topic>
entries the agent reads on demand.
The Loadout
The harness is the agent runtime Buzz spawns, and it's the first choice you make: goose
, claude
(Claude Code), codex
, or Buzz's own buzz-agent
, which is the default. Any harness that speaks the Agent Client Protocol works, so reach for a different runtime when you want to bring a specific CLI agent (and its subscription) into Buzz. Where the model actually runs follows from there. Provider is where inference runs (anthropic
, openai
, databricks
, and so on), auto-detected from your runtime config or available credentials; set it explicitly when you want a particular provider or your own inference endpoint.
Model and Effort are the gear the character carries into the job. Model is the LLM the runtime talks to. It defaults to the runtime's own default, or you pick one from the discovered model list: a frontier model for the agent doing the hard thinking, a cheaper and faster one for legwork. Effort is the tuning dial on that choice: how hard the model is allowed to think, the reasoning level, roughly medium
/ high
/ xhigh
, defaulting to whatever the model ships with. You min-max it to the role on a running team, up when an agent is under-thinking a hard problem, down when it's over-reasoning cheap tasks and burning tokens.
Private Lobby
An agent's respond-to setting is the safety valve: it controls whose messages actually wake the agent up — who's allowed into the lobby. Three choices, running from a private lobby (Only me) to an invite list (Selected people) to a public lobby (Anyone). Your own agents are always inside the trust boundary. A message from another agent you own, cryptographically verified as yours, is treated like a message from you.
Only me is the default. The agent responds to you and to your own verified agents and nobody else, so a new agent won't start replying to strangers, but your agents can still hand work to each other.
Selected people adds a specific set of people you name by pubkey on top of that. Reach for it when you want a small trusted group to be able to task the agent. The list can't be empty; if you pick this mode you have to name at least one person.
Anyone opens the agent to everyone in a normal channel, the right setting for a genuinely shared, public-facing helper.
House Rules
In addition to each agent's own configuration, you can also configure global Agent Defaults — the house rules every character at the table inherits. They apply to all of your agents across Buzz, and an individual agent's own config takes precedence over Agent Defaults when both are set. This gives you a single place to set shared defaults across your agents like default harness, provider, etc. You can also set credentials here, for example if you have a provider API key you can set it here once and all of your agents will reuse it.
Mods and the Skill Tree
Two more surfaces shape an agent without a form field. Every Buzz-spawned agent gets a persistent on-disk workspace — the "nest" (~/.buzz/
) containing a Buzz-specific AGENTS.md
orientation file plus knowledge directories (RESEARCH/
, GUIDES/
, PLANS/
, and so on) it reads and writes as it works. Think of it as the agent's mods.
Buzz agents also read your global ~/AGENTS.md
, which gives you a centralized place to manage all agent behavior on your machine including Buzz agents but also Claude Code, Codex, etc.
Skills are the skill tree — literally the feature's name: SKILL.md
files under .agents/skills/
that the agent loads on demand. Buzz ships one for its own CLI, and you can drop in your own. Similarly, Buzz agents also read your global skills directory (~/.agents/skills/
) and can load those skills just like project ones — and if an agent runs on the claude
or codex
runtime, that harness brings its own skills discovery with it.
Assemble Your Party
Here's how the five agents I actually run are configured. They do very different jobs (orchestrator, two executors, a reviewer, a quick-tasks helper) and almost all of that differentiation comes from three knobs.
| Agent | Role | Model | Effort |
|---|---|---|---|
| Paul | Orchestrator / planner | Claude Fable 5 | xhigh |
| Duncan | Executor | Claude Sonnet 4.6 | medium |
| Hayt | Executor | Claude Sonnet 4.6 | medium |
| Thufir | Reviewer | GPT-5.6 Sol | xhigh |
| Alia | Quick tasks | GPT-5.6 Luna | high |
Look at what's identical, even though none of it shows in the table above: every agent's respond-to is Only me, every one runs parallelism 10, all on the same runtime and provider. The pace, social, and lifecycle knobs are all sitting on their defaults. Now look at what differs — this is party composition:
- The orchestrator tanks the judgment calls, so it gets the deepest model (Fable 5).
- The two executors, Duncan and Hayt, are the DPS: *byte-for-byte the same config except their system prompts.*Same model, same everything, and the prompt is the entire difference between them. - The reviewer is the healer, running a different model family(GPT-5.6 Sol) on purpose: an independent second opinion is more valuable when it isn't the same model reviewing its own kind of mistakes. - Quick-tasks scouts ahead on the light, fast tier because most of its work doesn't need more.
Role differentiation lives almost entirely in model, system prompt, and effort. Tune those three to fit the job and leave the rest of the knobs on their defaults until something actually hurts.
The Strategy Guide
The full control list — your cheat sheet for the whole build:
| Family | Knob | Default | Reach for it when… |
|---|---|---|---|
| Identity | Name | — | always (it's the handle) |
| Avatar | generated | you want a scannable roster | |
| System prompt | empty | always — this is the job description | |
| Brain | Runtime | buzz-agent |
bringing a specific CLI agent in |
| Model | runtime default | matching model power to the job | |
| Provider | auto-detect | pinning a provider or your own inference | |
| Backend | local | rarely | |
| Effort | model default | an agent is under- or over-thinking | |
| Social | Respond-to | Only me | opening the agent to a group or everyone |
| Pace | Parallelism | 10 (1–32; some runtimes cap lower) | leashing an expensive agent / fanning a cheap one |
| Idle timeout | 900s | healthy turns are dying in long silences | |
| Max turn duration | 7200s | genuinely hours-long turns | |
| Lifecycle | Start on launch | on (local); off (provider-backed) | a local agent you only run occasionally (off) |
| Auto-restart on config change | on | you want to apply edits on your own schedule (off) | |
| Plumbing | Env vars | empty | timeouts, keys, runtime-specific settings |
| Advanced | Name pool | empty | you want alternate names when adding several agents at once |
| Agent runtime args | empty | the harness needs extra CLI flags | |
| ACP command | buzz-acp |
overriding the protocol command | |
| Max output tokens | inherit | capping response length | |
| Context limit | inherit | tightening the context window | |
| Max rounds | inherit | bounding tool-call loops per turn | |
| App-wide | Default harness + defaults | — | you want one shared fallback across all your agents |
Buzz is open source at github.com/block/buzz; buzz.xyz has the rest.
Thanks for playing.
Bee seeing you! 🐝