Skip to content

SUPPORTING KNOWLEDGE · 0003

App vs harness: where Berd stops

The model is the thing that thinks; the harness is the runtime that lets it act, holds the tools and the session, and talks to the model on your behalf. That distinction is the same in Berd as in Buzz, and the Buzz Guide's Model vs. harness explains it once for both. What this page adds is where Berd itself sits: above the harness, as the app around it.

A Berd session runs on one harness, chosen per session. The help skill names them: goose, claude-acp, codex-acp, copilot-acp, amp-acp, cursor-agent, and since v0.6.4 Pi is offered at onboarding with one-click install. Goose is the one Berd bundles and starts as a sidecar; the others are separate tools Berd can drive through the ACP protocol.

Berd's help draws a hard line. Questions about the app around the harness (where a setting lives, how a session started, how to export a chat, how to file a Berd bug) are in scope. Questions about a harness's own behaviour, output or errors are not, and the instruction to the help agent is to say so rather than guess.

Why it matters to you

Three practical things follow from the line, and none of them is obvious from the interface.

Some Berd features are Goose features. Voice Conversation needs a Goose session. Steering (pushing a queued message into the running turn) is offered only for the Goose harness, and one error string says steering may be unavailable even in some Goose backends. Auto-compaction of older context is labelled Goose-only in Settings. Berdy's memory and global hints live under ~/.config/goose/, and the sources do not say whether another harness reads them.

Errors have two addresses. A provider error (key rejected, wrong URL, throttling) is Berd's to explain; see Provider errors mean four things. A harness refusing a tool, looping, or misreading a file is not. Berd's reporting route says a harness problem is out of scope for its feedback flow and belongs with that harness's own channel.

Skills belong to the harness's world too. Berd shows and manages skills in its own interface, but they are SKILL.md folders the harness loads. That is why the same skill idea works in both products.

How to apply it

Default to Goose unless you need a specific harness's own tooling. You lose nothing you use daily, and you keep voice, steering and memory.

When something goes wrong, ask first which side it is on. "The chat will not start" and "the key was rejected" are Berd. "It rewrote the wrong file" is the harness. Berd's help will make the same split, so making it yourself saves a round.

Where the harness is chosen in a new chat today, and whether a non-Goose session can be switched to Goose in place, is not verified from the sources; the composer toolbar has pickers for agent, model and provider, and the harness sits among those choices.

If you ignore this

You spend an afternoon looking in Settings for a voice option that will never appear in a Codex session. Or you file a careful Berd bug about something Goose did, and it is closed as out of scope, correctly.

Examples

Berd is the office; the harness is the colleague's own working method and toolkit; the model is what they know. You can change the office layout and you can pick which colleague to work with. You cannot ask the office why the colleague did something.

A consultant starts a review in a Claude ACP session, reaches for Voice Conversation and finds it needs Goose. They start a fresh Goose session for the spoken part and keep the Claude one for the written review.

Asking Berdy to explain why a Codex session produced a diff in the wrong format. Berdy will load the help skill, find the scope rule, and tell you that question belongs to Codex.

Do it: Choose a harness for a session

Last checked: Berd v0.6.4, 2026-09-11.

Reference

Verified
Berd v0.6.4 · 2026-09-11
NEVER BESTUCK AGAINCLICK ME

Guide built with Berd, Claude and Codex · verified against Berd v0.6.4, 2026-09-11 · read from source, not yet tested in the app · Buzz Guide · About · not affiliated with Block