Release notes by agents

The problem

Before every release someone opened the change page, read every linked ticket, decided which changes were customer-facing, wrote a documentation page for each and composed the notification email. Hours of careful, repetitive work, every release, and a missed change meant customers blindsided.

What I built

• Code where it must be exact. The link is validated and fetched by code, and ticket IDs come out by pattern match. No model touches an identifier.
• Agents where it is fuzzy. One reads the release page, one classifies each ticket, one drafts the docs into a fixed template, one writes the email.
• A reviewer that is not the writer. A separate agent checks the drafts against the source tickets and flags what does not match.
• A person at the gate. Flags land on a human's screen with the draft. Nothing publishes or sends until they approve, and sending goes only to an allow-list.

What I would flag

• The walkthrough uses an illustrative release and invented ticket keys. The stages, prompts and controls are the real operating pattern.
• It is deliberately a fixed pipeline, not an autonomous agent: near a production release, predictability is worth more than flexibility.

Who acts at each stop

1. Paste the release linkOne URL. That is the whole input.
2. Fetch the pageTicket IDs come out by pattern match. An ID has to be exact, so no model yet.
3. Read version and datesThe things a pattern cannot find: dates written in prose.
4. Fetch every ticketAll linked tickets, in parallel. Nothing left to memory.
5. Sort the ticketsOne call per ticket: customer-facing or internal.
6. Write the docsA fixed template per change, one email grouped by type of change.
7. Write the emailA fixed template per change, one email grouped by type of change.
8. Review the draftsA separate reviewer reads the drafts against the source tickets.
9. ApproveFlags land on a person's screen with the draft. They fix, they approve.
10. Publish and sendOnly now, and only to an allow-list of recipients.