Release notes & changelog draft
Release notes and changelog draft removes the scramble on release day. The agent collects what actually shipped from the tracker and the release channel, sorts customer-facing changes from internal ones, and writes the notes in plain language for each audience you publish to. The release owner edits and approves before anything is published.
Step by step
Collect what actually shipped
Tickets marked done in the release, plus the release thread, are gathered so the notes match reality rather than the plan.
Sort by who cares
Customer-facing changes, admin changes and internal work are separated, because publishing them together is what makes changelogs unreadable.
Write in plain language
Each item is rewritten from ticket shorthand into a sentence a customer can act on, keeping the ticket link for the team.
Flag the breaking changes
Anything that changes an interface or requires action from a customer is pulled to the top and marked.
Draft the versions you publish
A public changelog entry and an internal summary are drafted from the same set of changes.
Release owner approves before publishing
The drafts wait for the release owner. Nothing reaches the changelog space until that approval is given.
Exactly what this agent can see, touch and change
The same five controls sit behind every ollo agent. These are this one's settings — visible before you build it, not buried in an admin screen afterwards.
Context
What reaches the modelTeams shipping often enough that the changelog is always late, and product managers who end up writing notes from a ticket list on a Friday.
Escalation
When it asks a personThe release owner approves the notes before they are published
Applications & Rights
Which tools it uses, and what it may do in each
JiraRead only
SlackRead only
ConfluenceReadWrites newCreates new records or documents. Never edits, moves or deletes anything that was already there.Verification
How you know it’s rightEvery claim links to the document it came from. A statement the agent cannot cite does not make it into the output — which is what makes the result reviewable in minutes rather than re-read end to end.
Who it’s for
Teams shipping often enough that the changelog is always late, and product managers who end up writing notes from a ticket list on a Friday.
What you’ll need
- Tracker release fields used consistently
- Changelog space connected
- Audience versions agreed
- Release owner named as approver
What you get
- A drafted customer changelog entry
- An internal release summary
- A marked list of breaking changes
What it doesn’t do
It writes from what the tickets say. If a ticket title is misleading the note will be too, and it does not decide whether a change is ready to be announced.
We build the first one with you
Not a template you configure alone. We sit with your team, build it on real data, and hand over the controls.
Scope
One session with the people who actually do the work. We agree what the agent reads, what it may write, and who approves.
Co-build
Built on your own data, not a sandbox. You watch it being made, so you know why it behaves the way it does.
Handover
You own the controls. Change the context, tighten the rights, move the approval gate — without coming back to us.
Parts of the work currently spread across the categories below. It does not replace any of those products outright.
Frequently asked
What if a ticket was never updated?
It will not appear, because the agent works from what the tracker says shipped. The draft lists the tickets it used, so a release owner can spot the gap quickly, but tidy release fields are what make the output good.
Can it publish to our public changelog?
It publishes to the connected space once the release owner approves. If your public changelog lives somewhere without a connector, the approved text is prepared for a person to paste, and we agree that route during the co-build.
Does it write marketing copy?
No. It writes plain descriptions of what changed and what a customer needs to do. Positioning a release is a marketing decision, and an agent guessing at it produces exactly the changelog nobody trusts.
How does it treat security fixes?
They are separated and flagged rather than written into the public draft by default, because disclosure timing is a decision your team owns. The rule for handling them is set in the controls at handover.