A go/no-go decision is a formal decision, made by a named person at a set point, on whether something goes live. For AI agents, it decides whether an agent, or one capability at a new depth, starts acting for real. It is made on evidence, against criteria agreed in advance, and the outcome and reasons are recorded.
Why make it formal?
Because launches have momentum. Once a date is announced, the team has been trained and the business case approved, nobody wants to be the person who says no. A formal go/no-go decision gives that person a structure: if the criteria are not met, the answer is no, and it is not a personal judgement against the project.
It also settles who answers for the launch. If the decision is spread across a steering group, nobody owns it. A single named decision-maker, advised by others, makes accountability visible. That is a design choice, argued in who answers for an AI agent is a design decision.
What evidence goes into it?
The criteria vary by deployment, but for an agent they usually cover:
- Certification. The agent holds a current certificate at the depth requested, earned on the business's own cases.
- People. Reviewers for held actions are trained, certified and on a rota, with cover.
- Red lines. The cases the agent must never act on have been tested, including attempts to push it over them.
- Escalation. Held and refused cases reach named people within target times.
- Fallback. There is a tested way to drop the agent to draft-only mode or switch it off.
- Sign-offs. Risk, data protection and the process owner have given their views.
The AI agent go-live approval checklist turns these into a form, and how to red-team an AI agent before go-live covers the red-line testing.
An example
Take a hypothetical utility. Its billing agent has run in shadow for six weeks and is proposed to go live at depth 3 for routine bill explanations and payment-plan setups. At the go/no-go meeting, the evidence shows the agent passed certification at depth 3, but the payment-plan cases show it did not hold cases where customers mentioned financial hardship. The head of customer operations decides go for bill explanations, no-go for payment plans, which stay at depth 2 until a fresh run passes. The decision and its reasons are filed.
How is it different from go-live readiness?
Go-live readiness is the state of being ready, assessed against the criteria. A go/no-go decision is the act of deciding on that assessment. Readiness can be partial; the decision must be clear. In the example above, readiness was mixed and the decision split it into one go and one no-go, which is often the right answer. Go-live is rarely all or nothing.
Does it happen only once?
No. Every move to a higher depth is a new go/no-go decision, because the risk changes. Moving a capability from depth 3 to depth 4, where the agent may take actions that are hard to undo, deserves the same discipline as the first launch. The people side matters each time; the argument for certifying staff first is in the case for certifying customer support agents before AI agents go live. The guide to AI agent skills by role shows who typically holds the decision.
Questions people ask
Who should make the go/no-go decision?
The executive accountable for the process the agent works in. Risk and data protection advise; they should not be the decision-makers, or their independence suffers.
What if the criteria are met but the decision-maker still has doubts?
They may say no, provided they record why. A doubt that cannot be put into words is worth exploring before launch, and often becomes a new criterion next time.