About ninety days after an AI contract is signed, the conversation changes. The client stops discussing the successful demo and starts asking why Tuesday's batch failed, what the system costs per month, and what happens when an input looks like this.
A demo runs on selected input in a meeting with the builders present. Production receives whatever the workflow produces, including malformed input and provider failures, while the builders are elsewhere. In the deployments we have shipped, the model's average quality has rarely explained the support burden by itself.
The unglamorous list
What actually gets judged after day ninety:
- Does it degrade gracefully when an upstream provider hiccups, or does it take the client's workflow down with it?
- When it's wrong (and on a long enough timeline it is always sometimes wrong), does anyone find out before the customer does?
- Can the client's own team understand what it did and why, or does every anomaly become a support ticket to us?
- Is the cost curve flat as volume grows, or does success itself become the budget problem?
These questions rarely appear in the sales demo. They determine how much attention the system requires after launch and whether the client can operate it without us.
Operational routes
The boring system knows where an exception goes
Illustrative routes for the article’s provider failures, cost anomalies, and regressions. Recovery depends on the operation and its configured policy.
Scenario
The ordinary lane still leaves inspectable evidence.
Sequence
- Observe the resultCurrent
- Confirm deliveryUpcoming
- Retain the evidenceUpcoming
Observe the result
Track the workflow run and whether its expected output landed where the client works.
Read the full explanation
Successful run
The ordinary lane still leaves inspectable evidence.
- Observe the result. Track the workflow run and whether its expected output landed where the client works.
- Confirm delivery. The expected result is available to the client. A successful run still belongs in the operational record.
- Retain the evidence. Keep the run context and result available so the client team can inspect what happened.
Provider failure
Illustrative routing of the article’s failure class; recovery depends on the operation and policy.
- Observe the provider failure. The upstream provider fails while the workflow is running; preserve what is known about completed side effects.
- Detect and isolate. Associate the failed call with its workflow and affected output rather than silently losing the request.
- Check the recovery policy. This lane is eligible only if the configured retry or degraded-mode policy is safe for this operation. Recovery is not guaranteed; otherwise use manual handling.
- Assign the incident owner. A named operations or engineering owner can inspect the failure and decide the next safe action.
- Make the pause visible. Tell the client that processing is delayed or paused and how the workflow will be handled next; do not report success before recovery.
- Retain the decision. Preserve provider errors, attempted recovery, side-effect state, and the owner decision so the run can be reconstructed.
Cost anomaly
Illustrative routing; no spending threshold or renewal claim is invented.
- Observe workflow cost. Cost attributed to a workflow makes a change in spending visible without guessing which client caused it.
- Detect the anomaly. Inspect the cost signal with the affected workflow, usage, and output context. These are sample diagnostic fields for the article’s cost-per-workflow signal.
- Pause for inspection. Route the affected automation for manual assessment under its configured budget policy.
- Assign the cost owner. The named owner inspects the usage trace and decides whether to constrain, correct, or resume the workflow.
- Explain the workflow state. Make any service impact and next action understandable to the client team.
- Preserve cost evidence. Keep the usage context and the decision with the run so the anomaly is explainable later.
Regression
Illustrative routing of a failed behavior check; no invented incident or service target.
- Observe changed behavior. A changed prompt, model, or retrieval path can alter the behavior the workflow depends on.
- Surface the failed check. An eval failure or production exception identifies the affected behavior and points to run evidence.
- Hold the affected path. Pause or route the affected workflow for human handling while the regression is investigated.
- Assign the engineering owner. The owner receives the failing case and version context, then determines the correction and validation needed.
- Show the client what changed. State that the affected automation is paused and identify the available manual workflow.
- Keep the regression trace. Preserve the case, version context, owner decision, and outcome for diagnosis and future evaluation.
Successful run
The ordinary lane still leaves inspectable evidence.
- Observe the result. Track the workflow run and whether its expected output landed where the client works.
- Confirm delivery. The expected result is available to the client. A successful run still belongs in the operational record.
- Retain the evidence. Keep the run context and result available so the client team can inspect what happened.
Provider failure
Illustrative routing of the article’s failure class; recovery depends on the operation and policy.
- Observe the provider failure. The upstream provider fails while the workflow is running; preserve what is known about completed side effects.
- Detect and isolate. Associate the failed call with its workflow and affected output rather than silently losing the request.
- Check the recovery policy. This lane is eligible only if the configured retry or degraded-mode policy is safe for this operation. Recovery is not guaranteed; otherwise use manual handling.
- Assign the incident owner. A named operations or engineering owner can inspect the failure and decide the next safe action.
- Make the pause visible. Tell the client that processing is delayed or paused and how the workflow will be handled next; do not report success before recovery.
- Retain the decision. Preserve provider errors, attempted recovery, side-effect state, and the owner decision so the run can be reconstructed.
Cost anomaly
Illustrative routing; no spending threshold or renewal claim is invented.
- Observe workflow cost. Cost attributed to a workflow makes a change in spending visible without guessing which client caused it.
- Detect the anomaly. Inspect the cost signal with the affected workflow, usage, and output context. These are sample diagnostic fields for the article’s cost-per-workflow signal.
- Pause for inspection. Route the affected automation for manual assessment under its configured budget policy.
- Assign the cost owner. The named owner inspects the usage trace and decides whether to constrain, correct, or resume the workflow.
- Explain the workflow state. Make any service impact and next action understandable to the client team.
- Preserve cost evidence. Keep the usage context and the decision with the run so the anomaly is explainable later.
Regression
Illustrative routing of a failed behavior check; no invented incident or service target.
- Observe changed behavior. A changed prompt, model, or retrieval path can alter the behavior the workflow depends on.
- Surface the failed check. An eval failure or production exception identifies the affected behavior and points to run evidence.
- Hold the affected path. Pause or route the affected workflow for human handling while the regression is investigated.
- Assign the engineering owner. The owner receives the failing case and version context, then determines the correction and validation needed.
- Show the client what changed. State that the affected automation is paused and identify the available manual workflow.
- Keep the regression trace. Preserve the case, version context, owner decision, and outcome for diagnosis and future evaluation.
Decide what happens after the failure
Exercise a sample runbook by changing the failure, recovery conditions, and handoff. Retry eligibility is conditional; this widget does not assume a provider switch or retry succeeds.
Handoff gaps: Assign an incident owner. Publish a client-visible workflow status.
Inspect why “just retry” can be wrong
Unknown side effects require inspection. A committed side effect requires reconciliation, not blind repetition. Only a provider failure with confirmed no effects and a policy allowing retry reaches the retry lane here. Cost anomalies and regressions pause for manual assessment under their own policies.
Owner assignment and communication make the pause operable. They do not prove safety or authorize a broader action. This runbook has no invented incident dates, spending thresholds, or service targets.
Owner: named person or team for workflow errors, model regressions, provider incidents, and cost anomalies.
Signals: eval pass rate, exception queue size, latency p95, cost per workflow, failed tool calls, and unresolved customer-visible errors.
Fallbacks: manual lane, retry policy, degraded mode, provider switch criteria, and the message users see when automation pauses.
Client handoff: where they inspect a run, correct an exception, export evidence, and decide whether engineering needs to be called.
- The Principles of Production AIDescribes the eval, guardrail, orchestration, and observability work required to move an AI system past a pilot.
- Datadog LLM guardrails best practicesCovers runtime validation, sensitive-data handling, tool misuse, and monitoring the guardrails themselves.
- Implementing SLOsThe SRE framing is useful here: production trust comes from explicit service targets and agreed policies, not reassuring language.
The trap
At signing time, two vendors can produce similar demonstrations while only one has retries, idempotency, observability, fallbacks, and an eval suite. The difference may remain invisible until volume grows or a provider has a bad day. Building that operational layer before the client can see its value requires judgment about the failures likely to arrive later.
I use "boring" for a system whose common failures already have owners, signals, and recovery paths. The client's ops team can inspect an anomaly and correct it without turning each one into an engineering incident. Reaching that point takes work that the original demo does not show.
A strong demo still matters because the model can do work worth showing. After the contract, the client lives with the runbook, exception queue, and monthly bill. Those are also what an existing customer will discuss when a prospect asks them for a reference.