Skip to content

FAQ · AUTOMATION AND ADVANCED

Automations, CLI and advanced

My automation failed — is it the provider or the automation?

Ask which phase failed. Drafting in the builder runs on a provider and model like any chat, so a failure there is usually a provider problem. Approving or saving the tile is a product step, and a failure there is more likely an automations problem such as an unsupported tile type. A run failure has its own session in the run history. Check one thing first: whether your build has automations at all.

Why this comes up: An automation is built by talking, so the first failure looks like a chat failing. Berd's own help tells the agent to ask which phase failed before assuming a cause.

What to do:

  1. Drafting stalls or errors: a provider issue; see I saved my key and got an error. A draft rejected as not a valid automation is different: rephrase.
  2. Approving or saving fails: that is Berd. Note the exact message and report it.
  3. A run fails: open the history. Each run has output and, where one exists, a chat session you can read.
  4. Check the effect, not the status.
  5. No Automations surface at all: not a failure. Automations need Block-only services and the public release workflow at v0.6.4 compiles them off. Morgan's code-review automation on On The Block ran on Block's internal build.

Why it matters: Two failure phases, two owners, and a third possibility the app never announces: the feature is not in your build. See Automations: built by talking and Build an automation by chatting.

Can my agent change Berd for me?

Yes, within limits. Berd bundles a command-line tool, berdctl, that agents use to drive the visible app: create, rename, fork, move, archive and send to sessions; create and archive projects and attach folders; create and list agents and skills; list harnesses, models and context. Every verb maps to something you can watch happen. Settings are not on the list.

Why this comes up: Morgan, Berd's design lead, on On The Block: Berd has "a CLI that gives the agent the ability to change things in the app itself" — "I promise I'm gonna be less helpful than your own agent." People then ask for a theme change.

What to do:

  1. Ask in plain words: "archive everything older than a month in this project," "start a new chat for this and send it the brief."
  2. For a setting, expect directions, not a change; the CLI has no settings verbs at v0.6.4.
  3. Trust the visible result; if the agent claims something you cannot see in the app, distrust the claim.
  4. Do not expect berdctl in your own terminal. It goes on the agent's path when Berd starts its Goose backend; the sources do not describe putting it on yours. See Drive Berd from the command line.

Why it matters: This is the mechanism behind "just ask your agent," with a trust boundary: any process running as you can reach the same broker, and the app's command registry enforces the bounds. The result in the app is your check.

What is the difference between feedback open and feedback submit?

berdctl feedback open prefills the feedback form and sends nothing; you review, edit, attach screenshots and submit it yourself. berdctl feedback submit files a ticket the moment it runs, with no review step and no confirmation. On a public build neither exists: the feedback commands and the in-app Send feedback action are compiled only into builds with Block's feedback service, so the route is a GitHub issue you file yourself.

Why this comes up: An agent helping you report a problem may reach for the CLI. Berd's help skill tells it to prefer open under any ambiguity and, since v0.6.3, to check that the command exists before recommending it.

What to do:

  1. Find your route: berdctl feedback --help, or a visible Send feedback action. Absent both, use the issue forms at github.com/block/berd/issues.
  2. Where the command exists, ask for open, and say so; ask for submit only when you have decided to file exactly what is drafted.
  3. Attach logs only on purpose. They are opt-in, hold safe local metadata and sanitised logs, and exclude prompts, responses, tool payloads and session databases.
  4. For a GitHub issue, follow the contributing guide: search first, reproduce on the current version, one issue per issue, exact version and OS, a scrubbed log excerpt. An agent may draft it; you read it first.

Why it matters: submit is the one Berd command that reaches outside your laptop without showing you what it sends. See Keep Berd current and report problems.

Should I turn experiments on?

Not as a policy. Experiments are per-device opt-ins to in-progress features, and Berd's own description says they can change, break or disappear. In a production build an untouched experiment stays off unless it declares its own default; at v0.6.4 the ones on by default are Voice Conversation and the transcript renderer. Turn one on when you want the specific thing it does, one at a time.

Why this comes up: The release notes list experiments alongside features — chat on canvas, prompt pins, PR tracking, remote SSH, Realtime voice — without saying they are opt-in on a public build.

What to do:

  1. Open Settings → experiments and read each description; Reset to auto returns one to its default.
  2. Low stakes, Home only: chat on canvas and prompt pins change what a pinned item can do on the canvas. Try them freely.
  3. Higher stakes: remote SSH sessions starts Goose on a host from your SSH config, which is why it is manual-enable only. Know which host before you switch it on.
  4. Experiments that do not appear are not missing: Builderbot and skill discovery need Block-internal services, and the onboarding resets are developer-only.
  5. Re-read the list after each release; graduations are announced in What changed.

Why it matters: An experiment that breaks mid-engagement costs time you cannot bill; on a quiet afternoon it costs nothing. The setting is per device, so a colleague's Berd will not match yours. See Berd moves fast.

What does the monitor skill do for me?

It lets an agent hand a long-running command — a build, a test run, a poll — to a small bundled tool, berd-monitor, that keeps running after the turn ends and sends each output line back into your session as a message. Read from source, you should see a message labelled as sent by Berd from another session, source berd-monitor, prefixed [monitor]. None of this has been watched in the app.

Why this comes up: Berd bundled berd-monitor and berd-orchestrator in v0.6.3 as skills written for the agent, not for you, and the changelog says nothing about what a person sees.

What to do:

  1. Ask for it when work will outlive the turn: "run the test suite and tell me when it finishes."
  2. Expect the wake-up as an event in the chat; by default it steers a running turn or starts a new one.
  3. Check the work, not the summary; the monitor delivers output lines and does not judge them.
  4. Ask the agent to stop a monitor by its state key; no app control is described.
  5. For work in another conversation, the orchestrator skill delegates through berdctl session send and brings back one result or decision with a session link.

Why it matters: This is the closest Berd comes to work that continues while you are elsewhere, and it is unattended execution, which is why the task page is structure-only until someone has run it. See Run long work outside the turn.

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