Your agent works. The promises that get it live were never filed.
The work still standing between your pilot and production comes out of your own tickets, with a person's name and a date against each item, in a form your change process already accepts.
The situation
Getting one of yours live means a security review, somewhere for it to run, a decision about what it may write to, and legal looking at the data scope. Each of those is a promise one team made another. Your change process handles the ones somebody filed, where a change record carries a backout plan and a named approver and nothing ships without them. The ones that stall a go-live got made in a ticket comment or a thread, never went in as a change, and so never reached the gate that would have put a name on them.
(PwC AI Agent Survey, n=308 US senior executives, fielded 22–28 April 2025.)
What the diagnostic does
Every promise between the pilot and production comes out of your own tickets, each one carrying a person's name and a date. It counts how long each promise has been open from the day it was made, whatever the due date says now. The list separates what blocks the go-live from what can run late, and puts them in order.
Not everything that stops a go-live has a ticket. The diagnostic goes looking for what no ticket shows, including the rollback nobody has written and the approvals nobody has asked for yet, and answers what happens on the day the agent writes the wrong thing to a customer record.
What comes back is built to be filed. Each item arrives with an owner and a date against whatever it blocks, laid out the way your own change process already wants it, so it can go to whoever signs the go-live without you having to walk them through it.
How it runs
The diagnostic starts with whatever you can already share, before anything is proposed. Then what "in production" means here is agreed in writing, with acceptance criteria someone could test. The list is built from the real tickets, and the report comes back with named owners and a sequence. At the end you have the named risks and the choice of acting on them yourself or bringing Project Cutover back for the go-live itself.
Who runs it
Jona Venzor has spent about ten years on enterprise deployment and cutover work. The Amadeus cutover ran to roughly 3,200 interdependent deployment tasks planned across five months, on top of two and a half years of preparation, and the planning framework built for it was reused for the rollouts that came after.
None of that involved an agent. The part that carries over is a promise between two teams with a name and a date on it, settled before the go-live window opens rather than during it. That job is the same here.