I like your idea of an additional human summary, that does definitely help.

> That’s funny, because I find the lack of automation to be the lazy choice.

Automation is cheap these days. Many automations make things that exceed human ability, but this isn't one of those cases. You'll get something good-enough, but not great. Perhaps that's what your organisation has time and budget for, in which case your use of automation makes sense, but if we're trying to make the best audience-tailored summaries of software releases with specific purpose, the strategy falls short.

> Forgetting to add to the changelog because the requirement is checked by humans,

Individual developers definitely can, which is why you must also have organizational process. If a valid changelog checked by a release manager is a requirement for a software release, it can't be forgotten.

> fix things below some bar of noteworthiness that is entirely subjective and driven by lack of structure. Not writing commit messages worth putting in release notes (fix sht, asdasdasd, etc.)

I'm curious about the implication of insignificant commits coming from a lack of structure. I think it's entirely normal to have single commits fix something innocuous. If there's a typo in one file, you wouldn't fix it as part of creating a feature, because that's work outside the scope of the feature. So it would have to be in its own commit, or alongside other similar refinements. And those examples are indeed unacceptable commit messages that would not make it through code review in any serious shop, but I get what you mean, and it's part of my point: developers are supposed to write commit messages for developers, and the needs of developers are different to the needs of people reading a changelog, so it's only natural that the text should be changed for the different audience.

> I’ll ask my AI agent to go over the links in the changelog and summaries for me what are the breaking changes and what manual steps do I need to take.

I really think this is backwards and exactly the thing I was advocating against. The changelog you have is so large and poorly-structured that you need to use an AI to summarise it for you, and gather the information that should have been in the changelog in the first place. If that needs to be done to make the changelog useful, clearly its original state is deficient?