Before giving a workflow an AI agent, write down where it needs judgment. If the answer is “it checks a status, applies an agreed rule and sends the next message,” ordinary application logic may already do the job well.
Anthropic’s December 2024 discussion of effective agents draws a useful distinction.2 Workflows follow predefined paths; agents let the model direct more of the process and choose how to proceed. More freedom can help with an open-ended task. It also creates more ways for the system to spend time, money and confidence on the wrong thing.
The sensible question is how much freedom this particular job needs. “Agent” is a description of a design, not a promotion that every automation is hoping to receive.
Map the task before choosing the machinery
Let’s work through a fictional returns process. A customer writes an email explaining that an item arrived damaged. Staff need to identify the order, understand the request, check the policy and decide the next permitted action.
Some steps involve interpreting untidy language. Others involve rules that should produce the same result every time.
Put known decisions into explicit rules
The application can verify whether an order exists, whether the user may access it and whether a required field is present. Agreed eligibility rules can be evaluated in code using authoritative data.
That gives the business a predictable place to review and change the policy. If a rule is ambiguous, a meeting may be necessary. Asking a language model to settle the ambiguity merely gives the meeting a subscription fee.
Also define what happens when the data is incomplete. A missing delivery date should create a named exception rather than quietly becoming whatever assumption lets the workflow continue.
Curious what an AI agent could do for your team? See our AI agent services.
Use the model where interpretation earns its cost
An AI model may help turn the customer’s email into a structured summary or suggest the category of request. It can distinguish a complaint about damage from an unrelated question more flexibly than a handful of keyword matches.
The output still needs validation. The model’s extracted order number should be checked against a real record. Its summary should remain available for human review alongside the original message.
Keep that distinction visible: the model proposes an interpretation; the application verifies facts and enforces the permitted path. A fluent explanation should not be able to rewrite the return window.
Reserve agent behavior for genuinely variable work
An agent may make sense when the sequence cannot be laid out reliably in advance. For example, a support investigation might require choosing which approved information source to consult next, based on what the previous source revealed.
Even then, define the available tools, stopping conditions and escalation route. An investigation can be useful without granting authority to issue money or modify an account.
MCP may provide a common interface to connected capabilities, but the presence of a tool does not justify allowing the agent to use it. The question remains what the task requires and what the business can safely verify.
| Use it for | Example in a returns process | Keep it in check with | |
|---|---|---|---|
| Explicit rules | Known decisions that should come out the same every time | Does the order exist? Is the return within the window? | One predictable place to review and change the policy |
| A model-assisted step | Interpreting untidy language | Summarising the customer’s email and suggesting a category | Checking extracted facts against real records |
| An agent | Work whose sequence can’t be laid out in advance | Choosing which approved source to consult next in an investigation | Limited tools, stopping conditions and an escalation route |
Compare alternatives on the same awkward cases
Build the smallest credible versions before deciding that autonomy is necessary. A rules-based workflow with one model-assisted interpretation step may outperform a more elaborate agent for this returns task.
Check out this blog: Where should an AI agent pick up after the conversation ends?
Use the same evaluation cases for each design:
- A clear request with a valid order and complete information.
- A message containing several unrelated issues.
- A request that appears eligible until the authoritative record is checked.
- A missing or conflicting fact that requires a handoff.
- An interrupted tool call and an attempted duplicate action.
Judge the final business result, not just whether the text sounds reassuring. Did the right case reach staff? Were facts preserved? Did the system stop when it lacked the information or authority to continue?
Hamel Husain’s writing on evaluations makes the broader case for inspecting real failures and building checks around them.3 A test set should grow as the business discovers the mistakes that matter.
Record cost and delay too. A design that makes several model calls to arrive at an obvious route may be doing unnecessary work. There is no prize for making “please send your order number” require a small committee.
For the fictional returns team, I would begin with explicit rules, one constrained interpretation step and a clear human exception path. Add autonomy only where the simpler version repeatedly fails for a reason that greater flexibility could address.
That leaves room for useful AI without asking it to become the policy department. The staff can spend more time resolving the difficult cases, which is usually why we wanted the automation in the first place.