A retailer proposes an agent to handle returns, a process which at the moment starts with a customer filling in a form or sending an email to say they want to send something back, after which someone on the returns desk checks the order, decides whether the return is allowed, tells the customer, and issues the refund when the item arrives. The agent would do all of that in their place, reading the customer’s message, checking the order, deciding, replying and refunding, and on paper that sounds like exactly what the technology is for.
Most of what the agent would be deciding is already decided. The returns policy has been written down for years and is printed on the back of the receipt: thirty days from delivery, unworn with the tags still on, and no returns on earrings, underwear or anything personalised. Every one of those is a fact the order system already holds, so for the great majority of returns the decision is a rule, and IBM’s explainer on rules against agents makes the same point about refunds, that most decisions are clear-cut and a rules engine settles them cheaply before an agent is involved (AI Agents vs Business Rules, August 2026). Telling the customer is a template, chasing a parcel that has not arrived is a timer, and issuing the refund is the payment system doing what it already does.
What is left for a model is the return that the rules cannot settle: a message saying the jacket arrived with a tear, a photograph of the tear, or a reason that needs judging, such as the customer who wants to return a tent because it rained. That is a small and specific job, and a far smaller one than the agent that was proposed, and in my experience the products that handle returns well already work this way, with the rules deciding the ordinary case and a model reading the message and the photograph.
The question I’d want asked of every agent proposal is what is left for a model to do once the ordinary rules and workflow have been written down. It is rarely asked that way round, because the question that usually gets asked is what a model could do in the process, and the answer to that is always most of it, which is how a rule, a template and a timer turn into an agent.
The rules test
The test I’d suggest is that if the logic can be written down and kept true, you write it, because a rule is cheaper to run than a model call, it can be tested against known inputs, and it produces the same answer every time. If the logic cannot be written down, either because the input is free text in unpredictable forms or because the cases are ones nobody has anticipated, that is the work to give a model.
The qualification about keeping the rules true matters, and it is the one honest objection to the test. Rules have a failure mode of their own, which is the decision table that has grown to thousands of lines, changes every week and is understood by nobody who still works there. A rule costs more to maintain than to run, so where the logic would be that large or that volatile, a model may be the cheaper option even for logic that could technically be written down. That is a judgement about scale and rate of change, and it should be made deliberately.
The companies selling the models and the platforms say the same thing in their own guidance. Anthropic’s guidance on building agents opens by recommending “the simplest solution possible, and only increasing complexity when needed”, and observes that “agentic systems often trade latency and cost for better task performance” (Building effective agents, December 2024). OpenAI’s guide for enterprises lists three conditions under which an agent is the right choice, namely nuanced decision-making, rulesets that have become too intricate to maintain, and heavy reliance on unstructured data, and says that if a use case does not meet them clearly, “a deterministic solution may suffice” (A practical guide to building agents). IBM’s explainer on the same question puts the rules engine first in the flow because rules are cheap and quick to run, and sends a request to an agent only when the rules cannot decide (AI Agents vs Business Rules, August 2026).
Five things that come with a model call
I wrote recently about the anatomy of an agent, and the short version is that a model predicts text and executes nothing, while tools let it look things up and act. The loop is what makes it an agent, because it calls a tool, reads the result, decides what to do next and carries on until it judges the task complete. Four of the five things below come from that loop and the fifth from the model call itself, and none of them comes with a rule.
The first is that the same input can produce a different output, because a rules engine evaluates a fixed condition whereas a model samples from a distribution of likely answers. The same return submitted twice can be accepted the first time and refused the second, and no setting removes that entirely. In regulated work this is also the audit problem, and IBM’s explainer makes the point more neatly than I can: the rule that fired is, by definition, the explanation, and a rules engine can point at the exact condition that produced a decision. For a probabilistic system the explanation has to be manufactured afterwards, and it is never quite the same thing as the decision.
The second is that the system changes underneath you, because a rule changes only when you change it, whereas a hosted model changes when the provider retrains or retires it. The behaviour you tested in March is then not the behaviour running in September, and a regression suite that is actually run is what tells you when it has moved.
The third is a bill with no fixed driver and no natural stop, which a rules engine never presents because its cost model fits on one line: so many transactions, so much compute each, and the second run costs the same as the first. An agent has no such line, because retries happen or do not, retrieval goes deeper or shallower depending on what the first results looked like, the model reasons for longer on some inputs than on others, and the loop takes as many turns as the model decides it needs. In my experience the same task run twice can consume quite different volumes of tokens, and a loop that keeps re-planning because a tool keeps failing will run until a budget or a person stops it. So the honest answer to a finance question is a range with a named reason for the variance and an enforced ceiling on turns and tokens, and cost per token is the wrong denominator, since it can fall while the bill rises. The useful measure is cost per completed unit of work, a return decided, on which a rule wins every time one can be written.
The fourth is that every action must be safe to take twice, because the retries in an agent belong to the model, so nobody knows in advance which calls the loop will repeat. If the tool that emails the customer times out on the response, the model will reasonably call it again and the customer gets two replies, and if the tool issues the refund, the customer is refunded twice. Rule-based automation has the same hazard in principle, but its retries are written in advance, so the designer knows which steps repeat and protects each one. With an agent, every tool that has a side effect needs an idempotency key or a check that the work is already done, built into the tool itself, because a run with a model in the loop cannot be replayed to find out what happened.
The fifth is that the data leaves the building, since every model call sends the order, the customer’s message and whatever personal detail is in them to a provider, under that provider’s terms and jurisdiction, which is a question a lookup against a table never raises. Running your own model removes the question, at a cost in money and skills that in my view is rarely justified outside a specific regulatory constraint, and in my experience it produces a weaker model and the same governance work.
Where the model belongs
Models are remarkably good at the work that rules have always failed at, which is reading the messy thing a person sent and coping with the case nobody wrote a branch for. The model sits behind the rules and handles the exceptions, and when it handles one it recommends, with a deterministic guardrail turning the recommendation into a decision and a person above whatever threshold the stakes justify. An agent that recommends carries a different kind of risk from an agent that decides.
Put the returns process together that way and it looks different, because the system checks each request against the policy and the order, and for the great majority of returns that is the whole decision, at negligible cost and with an audit trail that consists of the rule that fired. A template replies and a timer chases the parcel, and the model is called only for the message the rules cannot settle and the photograph of the damage, where its job is to summarise the case and propose an answer for the returns desk to confirm, so that if the same kind of case keeps arriving the policy gains a line and the next one is a rule. The model is discovering the rules, and the rules then do the work, so the loop, if there is one at all, has a small and known ceiling.
That is the same process the team proposed, doing the same work, with the model used for the two things it is actually good at and the rules doing everything they were always able to do. The question to ask of any agent proposal is what remains once the rules have been written, because that remainder is where the model belongs, and it is nearly always smaller than the proposal.