SUPPORTING KNOWLEDGE · 0012
Automations: built by talking, failing in two places¶
An automation is a saved, re-runnable task with its own builder, run history and detail view. What sets it apart from a form is how it is made: you describe what you want in a builder chat, the builder drafts and revises with you, and then you approve the draft into a real, savable tile. Only then does it have a schedule and a history.
The builder is a chat with a preview beside it. The empty state says Describe what you want to automate; the draft appears in the preview. If the builder's last response was not a valid automation, the tile is rejected with Automation rejected and a suggestion to rephrase. Once saved, an automation has a title, instructions, a schedule (hourly, daily, weekdays, weekly, none, or a cron expression) with a time zone, a Run now action, a run history, and the option to duplicate it, edit it with chat, or pin its latest output to Home.
Morgan, Berd's design lead, on Block's On The Block (September 2026), built one by asking her agent: every twenty minutes it checks GitHub for her team's contributions and does her usual code review. She estimates it saves about two hours a day.
Not in the public build
At v0.6.4 the public release compiles automations off (VITE_AUTOMATIONS=0 in the release workflow), so none of the surfaces above are in a public build; Block's internal distribution has them, which is why Morgan and Berdy talk about them. This page describes what exists in the source for the day a distribution you run enables it. In the public build, "do it on its own" means the bundled berd-monitor and berd-orchestrator skills — see Run long work outside the turn. Last checked: Berd v0.6.4, 2026-09-11.
Why it matters to you¶
The shape that makes automations easy to create makes their failures easy to misread. Berd's help is explicit that a creation failure can come from two places with different likely causes:
- While drafting or revising in the builder session. This is a chat on a provider and model like any other. A provider problem (key rejected, wrong URL, nothing answering, throttling) blocks it as it would block a conversation. See Provider errors mean four things.
- While approving or saving the tile. This is a product step. A failure here (an unsupported tile type, for instance) is an automations issue, and no amount of key-checking will fix it.
The help skill tells the agent to ask which phase failed before assuming a cause. Make the same split yourself.
Then there is the third failure the sources say nothing about: a run that completes without doing the work. An automation is an agent acting unattended, on a schedule. The Coach's rule for scheduled work in either product: check that the work happened, not that the run finished.
How to apply it¶
Describe the outcome and the cadence, not the steps. "Every weekday at 08:00, summarise what changed in the client's shared folder into notes/daily/" is a draft the builder can work from; a list of clicks is not.
Run it once by hand with Run now, then read the run in History and the actual output, before you trust the schedule.
Pin the latest output to Home if you will check it daily; the pin shows its state at a glance.
Diagnose by phase. Draft failed: provider. Save failed: product. Ran but wrong: instructions, or a connection it could not use.
One control the Coach names without promising: the edit form has a notifications field labelled Slack notifications, for when the automation succeeds, fails or needs input. Whether that reaches anywhere in the public build is not verified; the label reads as Block-internal residue, as does the sticky note about "G2 automations".
If you ignore this¶
You spend an hour on provider settings because a save failed, or an hour on the draft because the provider was throttling. Or an automation reports success every morning for a month while writing an empty file.
Examples¶
Briefing an assistant for every Monday. The briefing can fail because the phone line is bad (provider); the diary entry can fail because the diary rejects the format (product); and Monday can arrive with the task marked done and not done (unattended).
A weekday automation that reads a folder of interview notes and drafts a one-paragraph status, saved to disk for you to post by hand. First run via Run now; history checked; output read; then the schedule is trusted.
Rebuilding the whole automation from scratch when the draft is rejected. Automation rejected means the builder's last message was not a valid automation; rephrase and continue in the same builder chat.
Do it: Build an automation by chatting
Last checked: Berd v0.6.4, 2026-09-11.
Reference¶
- block/berd — distro/skills/berd-help/references/automations.md — the two failure phases
- block/berd — src/shared/i18n/locales/en/automations.json — builder, draft states, schedule presets, history, notifications field
- block/berd — src/shared/i18n/locales/en/home.json — the automation output pin and its states
- Morgan, Berd's design lead, on Block's On The Block (September 2026) — the twenty-minute code-review automation
- Verified
- Berd v0.6.4 · 2026-09-11