OPERATING AI
FIELD NOTE 03 / 06Stop asking AI to behave like software.
A different answer is not automatically a broken answer. The mistake is putting a probabilistic system into production with deterministic expectations and no way to manage the variation.
Do not try to remove uncertainty. Constrain it, measure it and route it.
SHARE THIS FIELD NOTE
Pass the useful signal on.
Traditional software follows a path. AI interprets a situation.
A calculator should not develop a fresh perspective on seven multiplied by nine. A CRM workflow should not occasionally send an opportunity to a different stage because the language felt right. We expect the same input to follow the same rules and produce the same result.
Generative AI is different. It predicts and constructs an answer from probabilities. Small changes in context can alter the path. The same request can produce two different responses that are both useful, one useful and one weak, or two polished answers that are wrong in different ways.
This variability is not an unfortunate defect attached to the intelligence. It is part of what makes the system able to summarise an ambiguous call, adapt a reply or recognise that two customers described the same problem in different words.
The capability and the uncertainty arrive in the same box.
One impressive output proves almost nothing.
Most AI projects are approved through theatre. Someone chooses a friendly example, the model produces an unusually good answer and the room silently assumes the system will behave like that forever.
A production question is different: across hundreds of varied cases, how often is the output useful, how bad are the failures, can the system recognise uncertainty and how quickly will someone notice when behaviour drifts?
This is why prompt approval is not quality assurance. A person reading one output can judge that output. They cannot infer the distribution of future behaviour from it. Revenue teams need to sample across common cases, difficult cases and costly exceptions.
Put probabilistic judgement inside a deterministic shell.
Not every part of an AI system should be intelligent. Identity, permissions, required fields, spend limits, approval states and audit logs are usually better as ordinary rules. Use AI where interpretation creates value. Use deterministic controls where consistency protects the business.
Consider an AI system that recommends which account a seller should contact next. AI might interpret recent signals and explain why they matter. A rule should still prevent the system from contacting an opted-out person. Another rule can require human approval above a commercial threshold. A log should record the evidence and action every time.
The goal is not maximum autonomy. It is useful autonomy with a visible boundary.
Manage variation through a five-part control loop.
A dependable AI system is not one that never varies. It is one where acceptable variation is defined, failure is observable and uncertain cases have somewhere safe to go.
Constrain → Evaluate → Abstain → Escalate → Learn
- 01Constrain
Bound the task with relevant context, explicit exclusions, examples and permissions.
- 02Evaluate
Test representative cases against a rubric, rules and outcome measures.
- 03Abstain
Let the system say when evidence is missing or confidence is insufficient.
- 04Escalate
Route consequential or unusual cases to the right human, with the reasoning attached.
- 05Learn
Turn corrections and outcomes into updated context, tests and decision rules.
Evaluation only works when the team has made its judgment criteria explicit.
The most valuable AI skill is knowing what good looks like.↗Quality is a distribution, not a thumbs-up.
For open-ended work there may be no single correct answer. That does not make evaluation subjective chaos. A sales-call summary can be assessed for factual accuracy, coverage of agreed fields, separation of fact from inference, actionability and the absence of unsupported claims.
Some checks can be deterministic. Did the brief cite a source? Did it include an account owner? Other checks need a rubric or comparison. Is the recommended next action supported by the evidence? Is the tone appropriate to the relationship? A human reviewer, a model-based evaluator and downstream business data can each catch different failures.
The useful unit is not ‘did the AI work?’ It is the failure profile. What goes wrong, how often, with what consequence and under which conditions? Once that is visible, the team can improve the system deliberately rather than reacting to whichever bad screenshot reached leadership last.
- Track pass rates by case type, not only an overall average.
- Keep a permanent set of difficult and high-consequence examples.
- Measure false confidence separately from ordinary low quality.
- Review the cases humans override most often.
- Connect quality measures to revenue outcomes where the link is real.
Define the uncertainty contract before launch.
Every AI system should have an uncertainty contract: the variation the business accepts, the decisions the system may make, the evidence it must retain and the point at which a person takes over.
For a content ideation system, the contract can tolerate broad variation because a human chooses what survives. For an account-routing system, the acceptable variation is narrower. For a customer-facing promise involving price, eligibility or legal terms, it may be narrower still.
This reframes the leadership conversation. The choice is not between trusting AI and distrusting it. The choice is where to let probabilistic judgement create value, and what deterministic structure must surround it. That is how a variable system becomes a dependable part of revenue work.
Reliability is not the absence of uncertainty. It is the ability to operate safely in its presence.
SOURCES & FURTHER READING