Automatic, and deliberately not
A single line runs through this product. Everything on the left of it happens while you are doing something else; everything on the right waits for you.
| Step | Runs without you | Waits for a person |
|---|---|---|
| Noticing a merge | The GitHub App reports merges on the repositories you granted | Nothing — you are told, not asked |
| Deciding it is worth a word | Repository upkeep is flagged with the reason and left out of the default selection | Overriding that flag, which stays yours to do |
| Working out the impact | Analysis runs on every watched merge and produces its evidence and assumptions | Nothing |
| Writing the wording | One draft per enabled channel, written for that channel rather than pasted between them | Editing it, which never counts against a regeneration cap |
| A second related merge | Appended to an Update that is still open and compatible instead of opening a rival one | Splitting it out, if it is really a second story |
| Telling the reviewer | An email when the Update is ready, plus a mergelay.update.ready_for_review webhook | Reading it |
| Publishing | Nothing at all, unless you have turned on auto-publication for internal communication | An explicit approval, bound to the exact revision you read |
| Publishing a draft with an unverified claim | Refused by every unattended path, whatever the settings say | A deliberate human approval, with the flag still on the record |
Any content edit creates a new revision, and a new revision asks again. That is the whole reason the right-hand column cannot be emptied by a setting.
The controls that exist today
These are reachable and they work. What they are not yet is a place in the product you would find on your own — promoting them to a Settings section is planned, not shipped, and calling that anything else would be dishonest.
- Analyse new merges
Whether a newly merged pull request is analysed at all, per workspace.
- Draft meaningful changes
Whether an analysed change goes on to produce channel drafts, or simply sits in the record as something that happened.
- Require approval before publication
The switch that keeps the boundary where the table above puts it. Turning it off does not turn off the unverified-claim refusal.
- Optionally auto-publish internal communication
The one thing that can go out unattended: the message aimed at your own team, never the customer-facing ones.
- Repository and branch scope
Which repositories, and which branches inside them, are in play at all.
- Ignored paths and labels
The parts of the tree and the labels that should never wake the pipeline — generated code, vendored directories, a label your bots already use.
- Immediate or digest cadence
Whether a merge starts an Update straight away or waits to be batched with what follows it.
When something fails
Publishing is not one event. Each destination gets its own attempt and its own recorded outcome, which is what makes a partial failure survivable: you retry the destination that failed, and the ones that already landed are not sent a second time. Nobody on the receiving end reads the same release twice because a webhook timed out.
The record distinguishes a degradation from a failure, and the distinction is not cosmetic. When the model produces nothing usable, the deterministic path still produces the result, and Activity reads Fallback rather than Error — because something exists, it is just plainer than it would have been. The technical reason stays in the entry’s details for whoever has to care.
And when a real error does happen, the message describes what happened and what to do next, rather than exposing a stack trace or an internal instruction. A product that publishes on your behalf owes you a readable account of the times it did not.
Driving it from a coding agent
A workspace can also be driven from Claude Code or another MCP client, through seven workspace-bound tools: list updates, get an update, draft from a chosen merge, revise a draft, review an update, publish a draft, and retry one failed publication. It is shipped and governed rather than experimental.
Three access levels decide what a token may do. Read only can look. Editor — the default — can write drafts, which deliberately leaves the approval with a person. Operator adds the decision, and the interface says plainly what that means: a token at that level can approve and publish customer communication on its own. Tokens are named, stored hashed, scoped to exactly one workspace, expire after 30, 90 or 365 days, and can be revoked with immediate effect.
Be clear about what this is, though. It is an engineering surface for people who already live in a terminal, not an activation path we would put in front of a new customer, and it is described that way everywhere in the product.
What stays manual, and will
Not gaps waiting on a sprint — deliberate stopping points.
- No setting and no schedule in the product turns customer publication into an unattended job: the customer email and the social post wait for a person. The one credential that can decide in your place is an Operator MCP token, issued deliberately from Settings and revocable with immediate effect.
- The automation controls are reachable but are not a section of Settings yet. If you want them discoverable by a colleague who has not read this page, that is planned and not shipped.
- An Update speaks for at most ten sources. Past that it is a second release, and Mergelay asks you to say so rather than folding a month of work into one message.
- There is no flow to invite a teammate into a workspace yet, so “route it to a reviewer” today means routing it to the operator the workspace already has. Invitations are planned and named as planned.
Questions
Can I let it publish without me?
Only inwards. Internal communication can be auto-published if you switch that on. Customer-facing publication requires an approval, and a draft carrying an unverified claim is refused by every unattended path regardless of what the settings say — so the answer to “can I automate my way past the flag” is no.
Will every dependency bump become an update?
No. Merges that look like repository upkeep — bot authors, dependency labels, chore titles — are flagged with the reason and left out of the default selection. They stay choosable, because the signal decides what is proposed and never what is allowed, but you have to reach for them.
Immediate or batched?
Both exist, alongside repository and branch scope and the ignored paths and labels. The honest caveat is where they live: those controls are reachable but are not yet a section of Settings you would stumble into. Planned, not shipped.
How do I know something was sent?
Activity records the detected changes, the prepared communication, the decisions and the publications, and every approval is attributed. What it will not do is flatter the run: a model fallback that still produced a result is recorded as a fallback rather than quietly counted as a success.
Where to read next
- GitHub release notes in SlackOne reviewed message per release, instead of an event feed.
- Customer-facing release notesWhat it takes to put a draft in a customer’s inbox.
- GitHub integrationThe exact permissions the App holds, and how to remove it.
- PricingBoth plans, and what the plan actually changes.
Automate the noticing. Keep the deciding.
Your first Update is free. No card required.