A lot of AI agent projects do not fail during the demo.

They fail the week after somebody says:

looks good, let’s turn it on.

That is the dangerous moment.

Because now the conversation changes. It is no longer:

  • can the agent produce something impressive?
  • can it answer the prompt?
  • can it complete the happy path?

Now the question is:

is this thing actually ready to touch real work?

Real work means:

  • real customers
  • real records
  • real approvals
  • real downstream systems
  • real money
  • real consequences when the workflow is wrong

That is what go-live means. Not “the prototype works.” Not “the founder is excited.” Not “the pilot looked promising.”

If you want to ship AI agents without creating a second job called cleaning up after the AI agent, you need a go-live checklist.

Not a giant enterprise ceremony. Just a hard set of questions that force honesty before the workflow goes from interesting to operational.

What a go-live checklist actually does#

A go-live checklist is not bureaucracy.

It is a forcing function.

It makes the team answer the boring questions that decide whether the launch is sane:

  • what the agent is allowed to do
  • what it is not allowed to do
  • who watches it
  • who catches edge cases
  • what counts as failure
  • how it is paused
  • how the buyer knows it is working

Most AI agent launches go sideways because one of those questions was assumed instead of answered.

That is the whole point of the checklist. Turn assumptions into explicit decisions before the workflow goes live.

The 15 go-live questions#

1. Is the workflow boundary painfully clear?#

Can a normal adult describe exactly what the agent does in one paragraph?

For example:

The agent reviews inbound intake submissions, checks required fields, assembles a routing packet, and sends unclear or high-risk cases to a human review queue. It does not directly update the system of record without approval.

That is a workflow boundary.

If the description sounds like this instead:

  • helps teams move faster
  • handles ops tasks intelligently
  • automates business workflows end to end

then the boundary is still fuzzy. And fuzzy systems create fuzzy accountability.

2. Is there a clear action policy?#

Before go-live, the team should be able to say:

  • these actions run automatically
  • these actions require approval
  • these actions are forbidden entirely

If that split is not defined, the workflow is not ready.

Because the agent will eventually find the edge of its authority for you. And that is a stupid way to discover policy.

3. Do we know what data the agent sees and writes?#

You should be able to answer:

  • what systems are read from
  • what systems are written to
  • what fields are touched
  • whether PII, financial data, legal content, or internal notes are in scope
  • whether logs or prompts contain sensitive content

If the team cannot map the data path clearly, the workflow is not operationally understood. It is just technically assembled.

4. Is there an exception path that humans can actually use?#

“Escalates to a human” is not enough.

The real questions are:

  • where does the exception land?
  • who owns that queue?
  • what context does the human get?
  • what action can the human take next?
  • what happens if nobody looks at it for four hours?

A fake exception path is one of the fastest ways to turn automation into silent backlog.

5. Is the success metric defined in business terms?#

Do not go live measuring only model behavior.

Measure the workflow.

Examples:

  • turnaround time
  • review load removed
  • exception rate
  • error rate
  • approval latency
  • recovery time after failure
  • margin improvement
  • fraud exposure reduced

If the only dashboard says things like token count, average confidence, and prompt success rate, that is not enough. The buyer needs proof in operating terms.

6. Is there a baseline from before launch?#

A lot of teams launch into a measurement vacuum. Then three weeks later everyone argues about whether the system helped.

Bad.

Before go-live, capture the ugly before-state:

  • current volume
  • current labor time
  • current cycle time
  • current error or rework pattern
  • current exception burden

If there is no baseline, the launch will produce opinions instead of evidence.

7. Are the stop rules defined now, not later?#

What would make you pause the workflow?

Examples:

  • exception rate crosses a threshold
  • approval queue backs up past SLA
  • a wrong action reaches a real customer
  • data freshness fails
  • reconciliation gap appears
  • economics go negative

The point is not pessimism. The point is to define the kill criteria before momentum makes everyone lie to themselves.

8. Is there a human override and pause path?#

Someone should be able to answer, immediately:

  • who can pause the workflow?
  • how do they do it?
  • how fast does it stop?
  • what happens to in-flight items?
  • how do we resume safely?

If the answer is “engineering can probably disable it,” that is not a real control. That is a wish.

9. Are the ugly inputs tested, not just the clean ones?#

Happy-path tests do not mean much.

Before go-live, the workflow should be tested against:

  • incomplete submissions
  • contradictory records
  • stale context
  • duplicate events
  • missing IDs
  • weird formatting
  • ambiguous requests
  • multi-tenant edge cases

The system will meet ugly inputs in production. It is better if that is not your first introduction.

10. Is there proof the workflow can recover from partial failure?#

Real systems fail halfway.

The question is not whether that will happen. It will.

The question is whether the team knows how to detect and recover when:

  • a downstream write succeeds but the receipt is missing
  • an external system times out after acting
  • the queue receives duplicates
  • one step completes and the next one does not
  • the workflow state and system of record drift apart

If no recovery path exists, you do not have a production workflow. You have a fragile chain reaction.

11. Are responsibilities assigned by name, not by department?#

Do not say:

  • ops owns it
  • engineering owns it
  • the business will review edge cases

Say:

  • this person owns workflow outcome
  • this person owns runtime health
  • this person owns exception review
  • this person owns approvals
  • this person approves changes to scope or permissions

If ownership is abstract, incidents become political immediately.

12. Is the support window clear?#

The buyer should know exactly what happens after launch.

For example:

  • daily check for the first week
  • same-day response for launch-critical defects
  • weekly review for 30 days
  • change requests handled separately from break/fix

If support expectations are vague, the first post-launch issue becomes a pricing argument. And that is not a great way to begin a client relationship.

13. Is the handoff packet complete?#

Before go-live, the operator should already have:

  • workflow boundary summary
  • action policy
  • exception ownership
  • stop rules
  • rollback or pause instructions
  • support rules
  • review cadence
  • success metrics

If the system only makes sense when the builder is on Zoom explaining it live, the handoff is not done.

14. Is the change policy defined?#

A lot of workflows break not because the original build was weak, but because the business quietly starts changing the job.

Now the agent is expected to:

  • handle more systems
  • approve more cases automatically
  • cover adjacent workflows
  • support new records or policies

That is not free.

Before go-live, define what counts as:

  • a defect
  • a tuning change
  • a scope expansion
  • a new phase of work

Without that, every “small tweak” becomes a margin leak.

15. Is the first launch narrow enough to survive?#

This one matters most.

A lot of AI launches fail because the team tries to win too much too early.

Better first launches usually look like this:

  • one workflow
  • one queue
  • one business unit
  • one clear decision type
  • one operator group
  • one obvious success metric

Go-live is not the moment to prove the system can do everything. It is the moment to prove it can do one bounded job safely and profitably.

What a strong go-live packet looks like#

If you wanted to compress all of this into something a buyer or builder could actually use, the go-live packet would usually contain:

  1. workflow boundary summary
  2. action/approval policy
  3. system and data map
  4. exception path and ownership
  5. baseline metrics
  6. target metrics and review cadence
  7. stop rules
  8. pause/resume instructions
  9. support and warranty boundary
  10. change policy

That packet does two things.

First, it makes the launch safer. Second, it makes the work more sellable.

Because buyers trust teams that can explain how the workflow goes live in boring detail. That is what operational credibility looks like.

The practical rule#

Do not ask whether the AI agent is impressive enough to launch.

Ask whether the workflow is boring enough to trust.

That is the better standard.

A boring, bounded, measurable launch beats an impressive, fuzzy one every time.

Because the money is not in flipping on autonomy. The money is in launching a workflow that can survive contact with reality.

If you want help designing the checklist, boundary, approval policy, and launch packet for a real workflow, work with me.