When a Pilot Hits Its Stop Condition: A Shutdown Checklist

Sequence matters more than speed. The instinct to investigate first is wrong, because an agent in a loop keeps taking steps while people read dashboards. Oracle's explanation of the agent loop is blunt about the mechanism: the loop repeats until the task completes or a defined stopping condition is reached, which means the loop has no reason to pause while humans convene.

Revoke in this order, and note the timestamp of each step:

1. Identity first. Disable or deactivate the agent's service account in your identity provider. This kills every downstream token minted from it, including ones you forgot existed.
2. Keys second. Rotate or revoke every API key, OAuth grant and webhook secret the pilot used. Rotation beats deletion because it preserves the audit trail of what the key was used for.
3. Triggers third. Pause the scheduler, cron job, queue consumer or event subscription. An agent with no credentials but a live trigger will simply log failures and fill your alerting.
4. Flags fourth. Turn off the feature flag or routing rule that exposes the agent to users.
5. Workflow fifth. If the agent created work items (tickets, orders, drafts, outbound messages), record the count and stop downstream processing before anyone "cleans up" the queue.

Then write a one-paragraph factual note to yourself while it is fresh: what fired, when you saw it, what you did, in what order. Memory decays fast and the postmortem needs the sequence.

Do not delete anything yet. Deletion is the most common way a team loses the ability to decide whether to retry.

Logs are the only record of what the agent actually did, and they are also the first thing a well-meaning engineer wants to clear out. Freeze first. Export to an archive that is separate from the systems the pilot touched, ideally with write-once or object-lock retention so the archive cannot be edited later even by an administrator.

Export these categories, each with a checksum and an export timestamp:

Capture the configuration too. A trace without the prompt version and permission set is not reproducible, and an unreproducible incident cannot support a confident retry.

For anything with personal data, legal hold and privacy obligations apply before you copy it around. PagerDuty's guidance on incident postmortems notes that an analysis of how your incident response process itself performed belongs in the review, which means the archive should also include the response timeline: who was paged, how long revocation took, and where the process stalled.

Stakeholders do not need the reasoning trace. They need to know what happened, who is affected, what is stopped, what is not, and when they will hear more. Send the first brief within hours, even if the facts are thin, because silence gets filled with worse guesses.

Use a fixed five-part format so every brief is comparable:

• What fired: the stop condition, in its charter wording, with the threshold and the observed value.
• What is stopped: the specific capability, and confirmation that credentials are revoked.
• What is not affected: the systems you have checked and cleared.
• Impact so far: counts of affected records, users, orders or messages, with the time window.
• Next update: a specific time, and who owns it.

Send a second brief when the archive is complete and a third after the postmortem, with the decision. Three briefs is usually enough. Resist the urge to explain root cause in the first one; you will be wrong, and correcting an early diagnosis costs more trust than a short delay.

Two stakeholder groups are easy to miss. The team that owns the downstream system (billing, CRM, fulfillment) needs to know what the agent touched, because their reconciliation may be the first place the damage shows up. Legal or compliance needs notice if the stop involved regulated data, an external communication or a contractual obligation. Pertama Partners' AI incident postmortem guide lists regulatory notification as a category that always warrants a formal review, which is a useful default: if you are unsure whether to notify, run the review and let it decide.

Hold the postmortem three to seven days after the stop, long enough for emotions to settle and short enough that memory holds. The Pertama guide recommends that window and a facilitator who was not involved in the incident, which matters when the person who built the pilot is also the person answering questions about it.

Blameless does not mean conclusion-free. PagerDuty's blameless postmortem guidance is explicit that the point is to understand how a mistake was made rather than who made it, and that postmortems should trigger after any major incident even if it was later discovered to be minor. Apply the same rule to a stop: run the review even if the trigger turned out to be a false alarm, because a false alarm is a finding about the stop condition itself.

The review answers six questions, in this order:

1. What did the agent do, in sequence, based on the traces?
2. Which control should have prevented it, and did that control exist, fire, or get bypassed?
3. Was the stop condition itself well designed? Was the threshold right, was it measured correctly, and did it fire early enough?
4. What was the blast radius, measured in affected records and remediation hours?
5. What did the human oversight layer do, and how long did each human step take?
6. What change would make a repeat impossible, and is that change cheaper than the value the pilot was creating?

Question three is the one teams skip, and it is the one that decides the retry. A stop condition that fires late is a design defect. A stop condition that fires on a measurement artifact is a monitoring defect. A stop condition that fires correctly on a real boundary breach is the system working, which is a very different input to the retry decision.

Retry, revise or retire is a decision, not a mood. Score the postmortem findings against a small set of gates and let the gates decide.

Worked example. A support-triage pilot runs eight weeks with a stop condition of "routing accuracy below 90 percent over a rolling 200 tickets" and a guardrail of "no autonomous sends to customers." In week five the accuracy condition fires at 86 percent. The team revokes credentials within 40 minutes, exports traces, and finds the agent had been routing tickets from a product line added in week four, for which no labeled examples existed in the evaluation set.

Score it. Root cause understood and reproduced: retry column. The failing control was the evaluation set's coverage, which is cheap to extend: retry column, with a condition. Stop condition quality: it fired correctly and within the rolling window, so the design held. Blast radius: about 60 misrouted tickets over two days, all reassignable, so reversible. Value: the pilot had cut first-response time on the original queues, which the business valued. Oversight load: agents kept up.

The decision is retry with three changes: extend the evaluation set to every product line before new lines are enabled, add a coverage check to the pre-run checklist, and narrow the agent's scope to lines with at least a stated minimum of labeled examples. Note what the retry does not change: the stop condition, which behaved exactly as intended. Teams that "fix" a working stop condition after an incident usually make the next one later.

The decision rule in one line: retry only when you can name the control that failed, show the fix, and show that the stop condition fired early enough that the blast radius stayed reversible.

If your pilot ran on a mix of model providers and the postmortem needs the same traces replayed across them, one API key covering text, image and embedding models simplifies the comparison; Quanta Inference is built for that. And if the review concludes the use case was never well chosen, the selection discipline matters more than the pilot: Unit8's AI project selection guide argues for choosing projects that are both feasible and valuable, and Agility at Scale's prioritization framework separates finding candidates from choosing which few to fund, which is exactly the distinction a failed pilot exposes.

Every stop should produce at least one charter change, or the organization has paid for an incident and bought nothing. Fold the postmortem findings back into the documents that govern the next pilot.

Add to the charter: a tested kill switch with a named owner, a log retention commitment that survives cleanup, a notification list with owners, and a postmortem date booked at launch. The Institute of AI PM's pilot program template makes the point that pilots produce ambiguity when exit criteria are defined after the fact, and a stop condition with no response plan is the same failure one level down. The AI Assembly Lines success-criteria framework makes the companion argument for guardrail metrics defined before launch; a stop condition is a guardrail that has already been breached, so it deserves the same pre-launch rigor.

Two smaller habits pay for themselves. Keep a stop log across all pilots, one line per stop, so you can see whether one class of condition keeps firing. And rehearse the kill switch on a schedule, because a control nobody has exercised is a hypothesis.

Where a pilot is being rebuilt with a broader scope than the first attempt, a 30-minute scoping conversation can save a second incident: Quanta Consulting runs a free discovery call to map goals to a tailored recommendation.