Quick answerAssign changelog ownership to whoever is closest to the customer relationship, usually product ops or support leadership, not engineering, since engineering knows what shipped but not what a customer will notice or worry about. Give that owner a written rubric with three yes triggers (a refusal boundary moved, a default behavior a customer would notice changed, a past limitation got fixed) and a default no for internal-only changes. Set a 48-hour entry-drafting SLA from the day a qualifying change ships, and give engineering and support a defined escalation path for the roughly one change in ten that is genuinely ambiguous, rather than letting it sit undecided until a customer notices first.
Why the design question and the ownership question are separate problems
Our post on how to design an AI agent changelog customers actually read covers what a good entry looks like once someone has decided to write one: plain language, batched trivial tweaks, a way to ask about a specific change. It assumes the hard call, is this change changelog-worthy at all, has already been made correctly and consistently. In practice that decision is where most changelogs quietly fail. Engineering ships dozens of small prompt and routing tweaks a week. Nobody is naturally positioned to catch the one in ten that a customer will actually notice, and by default it falls to whoever happens to remember to mention it, which means it depends on who is in the room, not on a repeatable process.
Put a rubric in someone's hands, not a vague expectation
A changelog owner without a rubric will either under-publish, waiting for something dramatic enough to obviously qualify, or over-publish, listing every prompt tweak and burying the entries customers actually care about. Give the owner three concrete yes triggers: a refusal or escalation boundary moved in either direction, a default customer-visible behavior changed (tone, response length, what the agent will and won't attempt), or a previously known limitation got fixed. Everything else defaults to no unless a specific person overrides it in writing. This is a different question from how often to proactively tell customers what changed in your AI agent's behavior, which is about push cadence once something is already changelog-worthy; ownership decides worthiness itself, before cadence ever becomes a question.
Give the rubric an escalation path for the genuinely ambiguous cases
Some changes will not cleanly resolve under the rubric, typically because engineering and support disagree about whether customers will actually notice. Route those to a standing weekly 15-minute sync between the changelog owner and one engineering lead, not an ad hoc thread that dies when someone gets busy. Default to publishing when genuinely unsure; a redundant entry costs a customer ten seconds of reading, while a skipped entry that should have run costs a support ticket and a moment of eroded trust. Keep this decision separate from the higher-stakes question of what counts as a material change that requires re-running your AI agent's compliance sign-off, since that threshold triggers a formal internal review, while routine changelog judgment calls should stay lightweight enough to resolve in a single weekly sync.
Measure the process, not just the changelog itself
Track two numbers monthly: the percentage of qualifying changes that got an entry within the 48-hour SLA, and the number of support tickets that reference a change with no corresponding entry. The second number is the real forcing function. If it climbs, the rubric's yes triggers are too narrow or the escalation sync is getting skipped, and that is worth fixing before it becomes the customer's first source of truth instead of the changelog.
FAQ
Should engineering or product own the changelog decision?
Product or support ops, not engineering. Engineering has the most accurate picture of what shipped but the least visibility into what a customer will actually notice or worry about; the owner needs to sit closer to the customer relationship than to the codebase.
What if the changelog owner and engineering disagree on whether something qualifies?
Route it to the standing weekly sync and default to publishing when genuinely unsure. An unnecessary entry is a minor cost; a skipped one that should have run becomes a support ticket.
Does every prompt tweak need its own entry?
No. Batch trivial tweaks into periodic summaries and reserve individual entries for changes that meet one of the three yes triggers: a moved refusal boundary, a changed default customer-visible behavior, or a fixed known limitation.