Write the procedure before you deploy the agent

This week a public registry started counting what happens to enterprise AI agent projects after the announcement. A growing number of vendors now sell the same answer: agents that follow an approved procedure instead of improvising. The procedure is the part you can build, review and measure, so write it first and put the agent second.

What the registry shows

Shipped or Stalled went live on 17 October 2026. According to its launch release, it tracks 59 named enterprise agent projects, each linked to a public source, and records whether they stayed in pilot, reached production, scaled or were shut down. The release gives one reason for a shutdown: McDonald's switched off an automated order taker in 2024 after testing it in more than 100 US restaurants, with press reports citing accuracy problems. It gives none for the other 13 killed projects.

Read it with care: it is a registry of cases that someone made public, not the whole market. But 14 of 59 killed is enough to make the point that reaching production is not the same as staying there.

The vendors are converging on procedures

Two launches this week point the same way. Oracle announced AI Agent Studio for Industry Applications, a low-code and no-code environment to build, test, deploy and manage agents for industry processes. Kognitos describes its finance "AI employees" as agents hired into a role with a job description, the procedures to do it and clear limits, where the same plain-English procedure is executed deterministically and every run leaves a journal an auditor can read. Those are the vendors' own descriptions, and we have not tested either product.

Whichever tool you choose, the pattern is the useful part. It moves the risk from "what will the model decide?" to "what did we approve?"

Anatomy of a procedure an agent can follow

A procedure is a document before it is code. Write these five parts, in this order.

1. Trigger. One event that starts the work: an invoice arrives, a customer writes, a stock level drops. If you cannot name the trigger, you do not have a process yet.
2. Steps. What happens, in plain language, with one owner per step. If two people describe the steps differently, fix that before any automation.
3. Limits. The actions the agent may take, as a list. Anything not on the list escalates. Include amounts, systems and customer types.
4. Escalation. Who decides what the agent cannot, and what context travels with the case so nobody asks twice.
5. Journal. Each action by agent or person is written to the record. The journal is what makes the procedure auditable and improvable.

How to know it works

Treat the procedure like any production system and measure it:

• Completion rate: share of cases that reach the defined end state, over a stated window.
• Time to completion: the median, not the average.
• Escalation rate and reasons: where the agent stops. Each reason is a line in your revision backlog.
• Exceptions outside the list: any action the journal shows that the limits did not allow. This should be zero, and a non-zero count is a bug in the system.

Run it in shadow first: the agent proposes, a person acts, and you compare. Widen the limits only when the journal earns it.

What it looks like in a real operation

For Rodo, a retailer in Argentina, enquiries from WhatsApp, social and web were brought into a service pipeline with explicit stages. In the first measured window, 82% of the 604 enquiries created live reached Resolved, with a median of about one hour.

Keep the caveats with the number: it was a first window, with no comparable earlier baseline, and it describes pipeline records, not every conversation.

Where to start

Pick one process that already hurts. Write the five parts on a single page, have the people who do the work correct it, and run it in shadow for two weeks. If the page is hard to write, that is the finding: the operation needs redesigning before an agent can work inside it.