Ship, scale or kill: the decision rules every agent needs before launch

Most agent projects have a launch plan and no exit plan. A new public registry, shippedorstalled.ai, tags named AI agent projects at large organizations as Pilot, Production, Scaled or Killed, each with a public source. The useful lesson is not the count. It is that "killed" is a normal status, and teams that never defined it cannot use it on purpose. This article is a way to write those rules before launch.

What the registry shows

On 21 October 2026, the registry listed 101 projects: 49 in Production, 24 Scaled, 11 in Pilot and 17 Killed. It is a small, self-selected list of publicly documented projects, so it says nothing about the market as a whole. What it does show is that agents get switched off, and that the status is recorded in public.

Rule 1: one workflow, one owner, one number

An agent without a named workflow cannot be judged. Write down, before anything is built:

• The workflow: where the work starts, where it ends, and what counts as "done".
• The owner: a person in the operation, not in IT, who answers for the outcome.
• The metric: one number that already exists or can be measured from day one, such as share of requests resolved, time to resolution, or cost per completed unit.

If the metric needs a new dashboard to exist, build the dashboard first.

Rule 2: measure the baseline before the agent exists

A result with no baseline is an anecdote. Capture two weeks of the current process: volume, outcome, time, cost. If there is no earlier data, say so and treat the first window as the baseline, not as proof.

Sentynel's Rodo case is a good example of that honesty. Its case record reports that 82% of 604 live-created enquiries reached Resolved, with a median of about one hour, and labels it a first measured window with no comparable earlier baseline. The resolution cohort covers 31 August–24 September, from the Rodo operational report of 24 September 2026, and the figures describe pipeline records, not all conversations. That caveat is what makes the next window comparable.

Rule 3: write the four thresholds in advance

Pick the numbers with the owner, on paper, before launch. Each reader's numbers will differ; the structure does not.

1. Entry to production: the metric the pilot must reach, on a stated volume, with the human-review rate it must stay under.
2. Floor: the level below which the agent is paused automatically or by one person, with no meeting needed.
3. Scale condition: how long the metric must hold, and what must be true of the surrounding process (hand-offs owned, exceptions routed).
4. Kill condition: the review date after which an agent below its entry number is switched off or redesigned, and who decides.

Rule 4: design the exit, not only the entry

Switching an agent off must be boring. Before launch, confirm:

• Fallback: the work returns to a person or a queue that already exists and has capacity.
• Handover state: open items are recorded where the team can see them, not inside the agent's session.
• Data: what the agent wrote to systems of record can be traced and corrected.
• Cost: usage and spend are visible per workflow, so a kill decision can use them.

If any of these four is missing, the agent is not a pilot yet. It is a dependency.

Rule 5: review on a calendar, with the owner in the room

Put the review on the calendar at launch: weekly in the pilot, then monthly. The agenda has three lines: the metric against the floor, the exceptions that needed a person, and one process change that would remove a class of exceptions. Most of the value comes from the third line, because agents run inside an operation, and improving the operation is what moves the number.

What to do this week

Take the agent you are about to launch, or the one already running, and fill in one page: workflow, owner, metric, baseline, floor, kill date, fallback. If you cannot fill a line, that line is your first piece of work. An agent you can switch off with confidence is one you can also scale with confidence.