If it's creating more overhead, it's not agile. It may wear the label, but it's not the real thing.
If the existing process was already the optimal one, the agile thing to do is to not change it. If the "agile" changes are adding overhead, the actually agile thing to do is to go back to the previous process.
"The perfect way to do project management"
With this definition in place the future is solid, no criticism can bring agile down because agile can evolve into whatever you want it to be.
Literally, what is the difference between "agile" and "whatever works"?
Many places say "We will be agile according to this rigidly defined process". The contradiction is obvious.
Look at the difference between the principles of Theory of Constraints, and what most organizations do. Most organizations want to remove constraints, they know they're a problem (since, well, they're constraints). The difference between ToC and what most people do is that ToC emphasizes a deliberate focus on the singular constraint in the process. I've seen teams and offices optimize the hell out of areas that aren't the bottleneck. Meanwhile, they still spend 3 months at the end of their projects running their massive, manual test suite. Do the tests bring value? Yes, immense. Do they bring value at the right time? No, because they take 3 months to run so they're delayed until the end of the project, so the project schedule leaves 3-6 months of buffer after that testing to conduct rework. A deliberate focus, then, should be brought to the testing activities and identifying how they can be conducted more rapidly, ideally automatically, and feedback brought in at an earlier stage.
Agile, as described in the manifesto, brings in a set of values that are intended to provide focus on what's important for both the team and the customer. To a large extent, it means "whatever works", but with focus on the values you share with your team and customers, and the tradeoffs that will be incurred based on the choices made.