The fastest way to lose credibility on an AI project is to ship an agent where a formula field would have done.

It happens for understandable reasons. The budget was approved for AI, the demo used an agent, and reaching for something simpler feels like underdelivering. The result is a system that costs more, runs slower, and is less reliable than the thing it replaced, which sets the whole programme back further than doing nothing would have.

If the logic is deterministic, use deterministic tooling

A validation rule that fires every time beats a model that fires almost every time. It costs nothing per invocation, it runs instantly, and it can be read by the administrator who inherits it in two years.

Anything expressible as if this then that belongs in a flow. Putting it behind a model adds latency, adds cost, adds a dependency on an external service, and introduces a new way to be wrong that did not previously exist.

• Field updates driven by other field values.

• Routing based on a known set of criteria.

• Validation that can be expressed as a rule.

• Any calculation with a defined formula.

If the output must be reproducible, do not use an agent

Regulatory calculations, pricing, entitlement decisions, and anything that gets audited want reproducibility more than they want flexibility.

A sampled model will not promise you the same output twice, and the fact that it usually produces the same output is not the same as guaranteeing it. When someone asks why this customer was quoted differently from that one, the answer cannot be that the model varied.

This holds even when the agent is right every time you check. The problem is not accuracy, it is that you cannot prove determinism, and for a regulated process that proof is the requirement.

If there is no human and no undo, think hard

The value of an agent comes from handling variation, and handling variation means occasionally handling it wrong.

That is acceptable when a person reviews the result, or when the write is cheap to undo. It is not acceptable when neither is true. An agent making irreversible changes with nobody watching is a design that only works while it works.

• Irreversible plus unattended is the combination to avoid.

• Either add review, or make the action reversible, or do not automate it.

• Batch operations deserve more scrutiny than single record ones, not less.

Where agents genuinely earn their place

This is not an argument against agents. The category where they win is large and clearly defined.

Agents earn their place on unstructured input, where the shape of what arrives cannot be predicted. On ambiguous language, where the same request is phrased forty ways. On synthesis, where the answer requires combining sources no rule could enumerate. And most of all on work a person would otherwise skip entirely, because the honest baseline for a lot of CRM hygiene is that nobody does it at all.

That last case is the strongest and the most often overlooked. An agent that captures sixty percent of post call updates is not competing with a perfect process. It is competing with nothing.

A test before you build

Ask two questions. Could a competent administrator express this as a rule in an afternoon. And does the input arrive in a predictable shape.

Two yeses mean build the rule. Two noes mean an agent is probably right. One of each means decompose the problem, because there is usually a deterministic core with a small ambiguous edge, and the edge is the only part that needs a model.

The short version

Agents are for variation, ambiguity, and work that otherwise does not happen. They are not for logic you could write down.

That is a genuinely large category. It is just smaller than the one people reach for, and being honest about the boundary is what makes the projects inside it succeed.