Start from the decision, not from the model
A transformation programme buys a general capability and then looks for work to apply it to. The result is a portfolio of tasks that happen to be doable by a model, several of which would have been cheaper as a scheduled job. The opposite order works better: name the decision the task has to make, describe the inputs as they arrive, state the consequence of error, then choose the mechanism.
Most tasks turn out to have a narrower input than the business assumed. A renewal review that looks like judgement from a distance is usually a contract date, a notice window, a support backlog and a value threshold, and all four are fields. Once a task is described that way, the mechanism becomes a decision about variability and error tolerance.
Four mechanisms and four different kinds of certainty
| Mechanism | Suits | Breaks when |
|---|---|---|
| Business rule | A stated condition with a stated outcome, applied to structured fields | The condition is not yet known or the fields are not there |
| Conventional automation | A fixed sequence over known inputs and known systems | Anything varies, anything is missing, anything needs judgement |
| AI component | Unstructured or varied input that must be turned into structure | The output is unverified and consequential |
| Human decision | The consequence of error is borne by the organisation | Volume exceeds the time the people have |
These are not competitors. Most live workflows contain one of each, and the design question is where the boundary falls. The failure mode to avoid is not using a model where a rule would do; it is using a rule where the business has not decided, and shipping a guess as policy.
When a rule is the right answer
A business rule is the right answer when the condition and the outcome are known and both accepted by the business. It is explicable in one sentence, testable by anyone, and repeatable.
Rules should also be the default for anything that changes often, because a rule can be amended by an owner in a versioned table with a record of who changed it and why. A prompt in prose cannot be reviewed that way, and a threshold change at short notice becomes a five-minute task rather than a redployment.
When conventional automation is the right answer
If the steps, inputs and systems are known, a scheduled job or a scripted integration is more reliable than anything that reasons. It runs at three in the morning without a model in the loop, it produces a deterministic result, and it can be tested with ordinary software practice.
The honest question is whether the task is actually interesting. A workflow that pulls an order from a system, checks a quantity against a rule and writes a confirmation is a workflow, and it should be built as one. Wrapping it in a model adds a cost, a variance and a failure mode without adding capability. Automation is wrong where the input is prose, incomplete, or written in a way that varies by customer, supplier and author.
Where a model earns its place
A model earns its place when the input is genuinely varied and the output is a structured extraction or a proposal a person will check. Free text, images, attachments and messages written under time pressure are the classic cases. The output should be verifiable: fields against a schema, a classification against a defined set, a summary against a source document.
The tasks that look like good model candidates and are not tend to share three properties: the consequence of a silent error is large, there is no source a reviewer can check against, and the volume is high enough that nobody will read the output. The problem is then neither the model nor the prompt; it is that the task has not been specified. The difference between data access and usable context is in why an AI agent needs more than database access, and the diagnostic for an unspecified process is in your company does not need more AI agents.
Combinations beat single mechanisms
The most reliable workflows are layered, and each layer has a job. A model reads the unstructured material and produces structured fields. A rule checks those fields against the versioned policy. A script performs the mechanical part of the write. A person approves the consequential part, and the exception queue receives whatever falls outside the expected path.
The value of layering is that each layer can be tested on its own. A rule set can be reviewed by a business owner who does not read code. A model's contribution can be measured against a labelled sample. A permission boundary can be asserted in a test.
A sequence for choosing per task
- Describe one task as a decision: the input, the output, the consequence of error and who bears it.
- Check whether the input is actually structured. If it is, start with a rule or a script, and treat a model as unnecessary until proven otherwise.
- Identify the part of the task that involves interpretation, and apply a model to that part only, with a schema for the output.
- Decide where the human decision sits, and place the gate before the write rather than after it, as described in designing AI workflows with human approval and exception handling.
- Record the choice and the reason in a short decision note attached to the workflow, so the next reviewer can challenge the choice rather than rediscover it.
The measure of a good choice is not elegance. It is the ratio of value recovered to effort and risk carried, and the organisations that get this right hold two things at once: a model doing the reading people should not be doing, and rules doing the deciding they should not trust a model with. The difference between answering and acting is in moving from a chatbot to business execution, and the task-level method is in identifying which tasks need people, AI or both.