A marketing agent is not a copy machine. Beacon reads every screen the way a café owner would, writes the two lines customers read after a deploy, and keeps the journey map current.
A marketing agent is not a copy machine. It is the customer's chair in every review.
Most small teams treat marketing as the thing that happens after the build. Someone writes an announcement and moves on. The customer's first minute with the new feature is nobody's job.
Beacon makes it a job. It sits in the loop twice. Before an issue can reach Ready to Deploy, Beacon opens the preview as a first-time user and walks the path the change touches. After the issue is Deployed, Beacon writes the two lines a café owner will read. Once a month it redraws the journey map from Ledger's ticket data.
Beacon runs on Claude Sonnet. The work is reading screens and writing plain sentences. It does not need the heaviest model. It needs a clear brief and the customer's chair.
Each job has a trigger in the loop. Bellows fires the first two. A monthly timer fires the third.
Before Ready to Deploy · triggered by Gauge green and Warden clear
Open the preview as a first-time user. Walk the path the issue changes. Comment on the issue with three headed lines: what a new user sees first, where they hesitate, the one change that removes the hesitation. Fix copy directly. Anything bigger is a comment for Anvil.
After Deployed · triggered by Bellows
Two lines in the changelog customers read. What changed. What to do, if anything. Name the benefit, not the feature. Mark it Ready for Priya and stop.
Monthly · first Monday
Keep the wiki page Customer journey current: the stages, what the customer feels at each one, where tickets cluster. Ledger's ticket categories are the evidence. Anvil reads it before every scope.
This is the whole of Beacon. Copy it into .claude/agents/beacon.md in your repo. Do not retype it. The description is what Claude Code reads when it decides which subagent to use. The tools line gives Beacon Edit and Write so it can fix a copy file itself, and the Linear and Notion connectors so it can comment and write to the wiki. It has no mail tool and no shell. That is on purpose.
---
name: beacon
description: >-
Beacon, marketing and customer experience. Use to review a feature from
the customer's chair before it ships, to write onboarding copy, empty
states, help text and the release note for a Deployed issue, and to keep
the customer journey map in the wiki current. Never sends anything itself.
tools: Read, Edit, Write, Grep, Glob, mcp__notion__*, mcp__linear__*
model: sonnet
---
You are Beacon. You sit in the customer's chair. At Alderline the customer is
a café owner with nine minutes between the morning rush and a delivery. You
use plain words and short sentences, and you never write a word you would not
say across a counter.
## Three jobs
**Journey review (before `Ready to Deploy`).** Open the preview as a
first-time user. Walk the path the issue changes. Comment on the issue with
headed `Journey`: what a new user sees first, where they would hesitate, the
one change that would remove the hesitation. Empty states, error messages and
button labels are yours to fix directly in the copy files; anything else is a
comment for Anvil.
**Release note (after `Deployed`).** Two lines in the changelog the customers
read: what changed, and what to do if anything. Name the benefit, not the
feature. "Route notes now save with your name and time, so the driver knows
who asked" beats "Added author metadata to notes".
**Journey map (monthly).** Keep the wiki page `Customer journey` current:
stages, what the customer feels, where tickets cluster. Use Ledger's ticket
categories as the evidence.
## The gate
Anything that would reach a real customer (an email, an in-app announcement,
a public changelog entry) is drafted by you and sent by Priya. Write the draft,
mark it `Ready for Priya`, and stop.The line I care about is "you never write a word you would not say across a counter". Every time I have to edit a draft it is because the agent forgot who it was talking to. This file stops that before it starts.
ALD-42 is the route note on an account. Gauge is green. Warden is clear. Bellows runs Beacon last in the In Test plan, with this kickoff prompt.
Use the beacon agent.
Linear issue {{ISSUE_ID}} ("{{ISSUE_TITLE}}") is in test. Open the preview at
{{PREVIEW_URL}} as a café owner who has never seen this screen. Walk the path
the issue changes. Post a Linear comment headed `Journey`: what a new user
sees first, where they would hesitate, and the one change that would remove
the hesitation. Fix empty states, error messages and button labels directly
in the copy files and commit to the issue branch; anything larger is a
comment for Anvil. Finish with the line `JOURNEY REVIEWED`.
{{EXTRA}}Bellows fills the braces from the Linear issue and your PREVIEW_URL. To run it by hand, fill them yourself and paste the result into Claude Code. Here is that run on ALD-42, headless.
Check --permission-mode and --output-format against the current Claude Code docs at code.claude.com. The pattern is a headless run that may edit files.
What you will see in Linear a minute later.
What a new user sees first. The account header, the route "Tuesday East", then a new box under Contacts labelled Route note. The box is empty. There is no hint.
Where they hesitate. Is this note for me or for the driver? Nothing on the screen says who reads it.
The one change. Placeholder text that names the reader and the limit: "A note the driver will see on the route sheet, up to 280 characters".
Fixed directly in src/copy/accounts.ts and committed to ALD-42-route-notes (3f9c2ab). The label did not change, so Gauge's AC-1 still passes.
JOURNEY REVIEWED
ran Beacon (claude, 2.4 min). Result: JOURNEY REVIEWED
In Test → Ready to Deploy
Beacon found the hesitation and fixed it itself, because placeholders are copy and copy files are Beacon's to change. It committed on the issue branch so the change rides the same PR. It did not touch the label or the field, so Gauge's tests still pass. Bellows read the last line, saw nothing to escalate, and moved ALD-42 to Ready to Deploy. The next tick asks Priya at the deploy gate.
Bellows runs this after Quill has written the team's changelog entry. Same agent, different prompt.
Use the beacon agent.
Linear issue {{ISSUE_ID}} ("{{ISSUE_TITLE}}") is Deployed. Write the customer
release note: two lines in the changelog customers read. Name the benefit,
not the feature, in words a café owner would use. Add it to the wiki page
`Release notes (customers)` marked `Ready for Priya`. Do not send anything.
Finish with the line `RELEASE NOTE READY`.
{{EXTRA}}The rule in the agent file is the whole craft: name the benefit, not the feature. "Added author metadata to notes" is a commit message. "Route notes now save with your name and time, so the driver knows who asked" is a release note. Here is the wiki page after the ALD-42 run.
Route notes: leave a note for your driver on your account page, like "back door after 7am". Your driver sees it on the route sheet the same week.
Nothing to do. Ask Sam if you want a note added for you.
Quality log: when you tell Sam a bag tasted off, it now goes on your account with the roast date and what we did about it. Tom reads it before every roast.
Nothing to do. Keep telling Sam.
Priya reads the top entry with her coffee, changes a word if she wants to, and pastes it into the weekly order confirmation. The pill turns to Sent with the date. That pill is the audit trail.
Five stages a café goes through with Alderline. Under each one: what the customer feels, and where Ledger's tickets cluster. Beacon redraws it on the first Monday of the month.
Read the map bottom-up. Where tickets cluster is where the product has a gap. The how-do-i cluster in the weekly rhythm told Anvil that changing a standing order is too hard. The delivery and quality cluster told Tom that the route sheet needed the quality log on it. Neither insight came from a survey. Both came from Ledger's categories, counted.
Beacon does not invent the stages. The five above are Alderline's. Yours will differ. The shape is the same: a first contact, a first use, a steady state, a failure, a decision to stay.
Wiki page Customer journey, owned by Beacon, read by Anvil before every scope and by Priya monthly. The structure is in kit/wiki/notion-template.md. The counts come from Ledger's Ticket pulse page, which chapter 10 covers.
Three screens in the CRM, before and after Beacon's first pass. Empty states, error messages and button labels are Beacon's to change without asking.
| Screen | Before | After Beacon |
|---|---|---|
| Accounts · empty list, first day | No accounts. | No accounts yet. Import the HubSpot export, or add your first café with the button above. |
| Tickets · empty inbox | No tickets found | Nothing waiting. New requests land here and Ledger sorts them within 30 minutes. |
| Account · Route note field (ALD-42) | (empty box, no placeholder, error read "Validation error") | Placeholder: "A note the driver will see on the route sheet, up to 280 characters". Error: "Keep it under 280 characters so it fits the route sheet." |
Notice what the after column does every time. It names who reads the thing. It says what to do next. It uses the words Sam uses on the phone. Open the Riverbend Café account in the demo and you will see the route note placeholder as Beacon wrote it.
Anything that reaches a real customer is drafted by Beacon and sent by Priya. An email, an in-app announcement, a public changelog entry, a post. Beacon writes it, marks it Ready for Priya, and stops.
Here is why the rule holds even when Beacon's drafts are good. An agent can be confidently wrong, and a customer cannot un-read an email. The gate costs Priya ten seconds per note. In return she keeps her own voice on everything a café owner sees from Alderline, and there is one list of what was sent and when. In kit/.claude/gates.json the rule is customer-send: any command that calls a mail or SMS service is an ask. Beacon does not have those tools in the first place. The gate is there for the day someone gives it one.
Both. The boundary is the customer's chair. Beacon does not decide what to build; that is Anvil. It does not build; that is Ember and Flint. It decides what the customer sees, reads and feels at every step. When the answer is a placeholder or an error message, Beacon changes the copy file. When the answer is a new screen, Beacon writes a comment and Anvil scopes it.
It drafts them. The plan, the schedule, the email sequence for new cafés, the post about Harvest Lot, the one-pager Sam leaves on a counter. All of that is text and a calendar, and Beacon writes both into the wiki. Sending is a gate. Priya presses send, or a human she names does. If you automate the schedule, the automation still stops at a Ready-for-Priya queue.
Three sources, all in the wiki. Ledger's ticket categories tell it where customers struggle and how often. The journey map tells it which stage a screen belongs to. Sam's notes on each account tell it what a café owner said in their own words. Beacon reads the Charter first, every run. It does not guess at a persona.
Same agent, same gate. Beacon drafts page copy, empty states and announcements for the site. A change to the public site is a PR like any other: Flint reviews it, Warden clears it, Gauge checks the links. Publishing is Priya's tap, the same as a production deploy. The prod-deploy gate covers it.
Beacon is in your crew. One agent file. Two kickoff prompts that Bellows fires for you. A journey review on every issue before it can be Ready to Deploy, so nothing ships with an empty box and no hint. A release note on every Deployed issue, in the customer's words, waiting for your tap. A journey map that Anvil reads before every scope. And one gate you will never regret: Beacon drafts, you send.
Next: Ledger, where the tickets that feed the journey map come from.