Short answer: do not use an agent where the outcome must be identical every time, where a regulator or an auditor will ask why a decision was made, or where the work is a fixed sequence with no interpretation in it. Those three cases cover most of the agent projects that get built, run for a quarter, and are quietly switched off. The technology is not the problem. The fit is.
Deterministic work
If the requirement contains the word “always”, it is not agent work.
Always apply a 12 per cent discount to renewals over three years. Always route claims above a threshold to the specialist queue. Always send the confirmation within one minute. Each of these is a rule, and a rule executed by a model is a rule followed most of the time.
Most of the time sounds acceptable until you count it. A rule applied correctly in 97 per cent of cases, running two thousand times a month, is wrong sixty times. In a flow it would be wrong zero times.
The useful test: could this be a formula, a validation rule or a flow? If yes, it should be. The agent’s legitimate role is deciding which button to press, not being the button.
Regulated decisions
Lending, insurance underwriting, eligibility for a benefit, clinical triage, employment screening, anything with a legal consequence for the person on the other end. These are not agent work, and the reason is not accuracy.
The reason is that you have to be able to state the basis for the decision, show that the same basis was applied to everyone, and demonstrate it did not turn on a protected characteristic. A model cannot give you any of those. It produces an output, and asked to explain itself, it produces a plausible narrative that is generated text rather than a record of what happened.
Several jurisdictions also give people rights over automated decisions with legal or similarly significant effects. That is a conversation with legal, not with an architect.
Where an agent can sit near this work: gathering information, explaining a decision made elsewhere, checking whether an application is complete. The decision belongs in code with rules someone wrote down.
Anything needing an audit trail of reasoning
This is the subtlest of the three and the one that catches teams late.
An agent’s logs tell you what was asked and what was answered. They do not tell you why, because there is no why to record. Any explanation you ask for is a second generation produced after the fact, unconnected to whatever determined the first output. It will be coherent. It may describe reasoning that did not occur.
So if your process requires a defensible answer to “why was this done”, the agent cannot supply it. Deterministic logic can: the rule fired, here is the rule, here is the input, here is the version that was live that day.
Three more that look tempting
- Anything numeric. Totals, prorations, forecasts, reconciliations. Models handle digits as text and are wrong occasionally rather than obviously. Calculate elsewhere and let the agent read the answer out.
- Long transactional sequences. Six dependent steps with a rollback requirement. There is no rollback across a chain of agent actions, and the realistic failure is a partial completion nobody notices for a week.
- Bulk processing. Ten thousand records needing the same treatment is batch Apex. An agent doing it is slower, costlier and less reliable.
The honest test before building
Four questions. If any answer is yes, reach for a flow or Apex instead.
- Must the output be identical for identical input?
- Will anyone need to see why, in a way that holds up to challenge?
- Is the path fixed, with no genuine interpretation of what the user meant?
- Does an error cost more than a person’s time to correct?
What remains after those four is real, and it is where agents earn their place: understanding a request phrased any of a hundred ways, summarising something a human will read critically, drafting text a person edits, answering from grounded content where being wrong is inconvenient rather than expensive.
Frequently asked
What if leadership has already decided on an agent? Agree to the agent and put the deterministic parts in actions behind it. You get the conversational interface and the guaranteed behaviour, and everyone is satisfied.
Will this change as models improve? Accuracy improves. Determinism and explainability are properties of the approach, not missing features, so do not plan on them arriving.
How do I argue this without sounding negative? Bring the list of what the agent will do alongside what the flow behind it will do. Sponsors accept the split easily when they see it before go-live.
