AI agent or conventional automation: which should you choose?

A customer emails to ask where their order is. To answer, you need to understand the request, find the order, check its status and write a reply. Should you hand the entire process to an AI agent?

Not necessarily. Some steps follow explicit rules; others require language comprehension. The right approach is often to handle them differently, rather than assign the whole journey to a model.

Use rules for what you can describe precisely. Introduce AI where interpretation is useful. Grant autonomy only when the benefit justifies the additional controls.

Three approaches worth distinguishing

Conventional automation

A workflow follows predefined steps. For example: when a form arrives, check the fields, look up a customer in the CRM, create a case if no duplicate exists, then notify a team.

The process can include conditions and loops. It is still defined by written rules. This approach suits calculations, transfers of structured data, format checks and decisions with explicit criteria.

It can be built in a tool such as n8n or written directly in code. The choice of tool does not change the underlying approach.

An AI-assisted workflow

The overall journey remains predefined, but one step uses a model to extract information from text, classify a request, summarise a document or draft a response.

A system that asks a model to classify an email and then follows a predefined branch does not need to be described as an autonomous agent. This solution is often sufficient. Its inputs, expected outputs and control points are easier to define.

An AI agent

The term covers a range of products. Here, it means a system in which the model can choose its next steps and which tools to call to achieve an objective, within defined limits.

An agent might decide to search for information, consult another source and then ask for clarification. That flexibility can be useful when there are many possible paths that are difficult to enumerate. It also introduces new questions: how many steps should be allowed, which actions should be available, and how will you detect a bad decision?

Break down a concrete case: order tracking

Return to the customer’s email. A reasonable architecture could divide the work into five steps.

Understand the reason for the request. If the customer selected “order tracking” in a form, a rule is enough. For a free-form email covering several topics, a model can suggest a category and extract a reference.

Verify the information. The reference must match the expected format. More importantly, the person making the request must be authorised to view that order. This check belongs in the application, not in the model’s judgement.

Read the status. The status comes from the order management system or carrier. The model should not infer it from an old message or invent a missing delivery date.

Prepare the response. A message template may be enough for a standard status. AI becomes useful when the wording needs to take account of a longer conversation, using only verified information.

Review exceptional cases. A dispute, a refund request or inconsistent data may require a person to take over. The workflow needs that exit, with enough context to avoid making the adviser repeat the entire investigation.

In this example, AI adds value through interpretation and possibly drafting. An agent that can freely modify orders would add autonomy for which a need has not yet been demonstrated.

Recognise where an agent may be useful

An agent-based approach is worth exploring when three conditions are met:

• the next action depends on information discovered during the process;
• several tools or sources may be needed, in a variable order;
• the result can be evaluated and the actions adequately constrained.

An internal research assistant, for example, might need to identify relevant documents, compare their versions and ask which business unit is involved before answering. The order of those searches is not always predictable.

By contrast, calculating a discount from a price schedule, synchronising a field between two tools or sending a reminder at a set time does not, on its own, justify that architecture.

Before choosing a technology, make sure the process is worth automating. Our guide to choosing a first business process helps you establish the volume, exceptions and expected benefit.

Evaluate quality using cases you understand

A successful demonstration is not enough to assess a system. Build a representative set of cases with expected answers or actions: straightforward requests, ambiguous wording, missing information, contradictions and attempts to take the system outside its role.

Keep some cases separate from prompt tuning. They will help you check that an apparent improvement is not simply an adaptation to examples the system has already been tested against.

Measure the quality of each step. A well-written answer may refer to the wrong order. A correct category may still lead to an inappropriate action. In particular, distinguish:

• extraction or retrieval errors;
• answers unsupported by the available sources;
• incorrect actions;
• requests unnecessarily escalated to a person;
• the time needed to check and correct the result.

Do not treat a model’s self-reported “95% confidence” as a reliable probability. A score is useful for decision-making only if its behaviour has been evaluated on your task.

Control actions independently of the model

A prompt is not a replacement for application permissions. The server must restrict the available tools, validate their parameters and check the user’s rights before each action.

The contents of an email or document remain external data, even if they include a sentence such as “ignore previous instructions”. The system must not give that content the authority to change its permissions or select a recipient for a data export.

For an initial release, read-only tools and drafts awaiting approval provide a scope you can observe. If write actions are necessary, add approval appropriate to their consequences, protection against duplicates and a record of changes.

Set concrete limits too: maximum steps, execution time, cost per case and a stop condition for repeated behaviour. Human intervention must remain possible when the sources do not support a conclusion.

Compare the cost of a correctly completed case

The price of a model call is only one part of the cost. Retrieval, tool calls, retries, human review and integration maintenance also need to be included.

Compare the cost of a correctly completed case, not that of a generated response. A cheaper model call can produce a more expensive process if its answers need more checking.

Latency matters as well. An autonomous search involving several steps may be acceptable when preparing a report, but disruptive when a customer is waiting for an answer during a conversation.

A straightforward progression for making the decision

Start with the most constrained workflow that can deliver the service. Test rules alone first, then a targeted AI step. Add autonomous tool selection only when the limitations of the predefined process have been clearly identified.

This progression provides a useful comparison: what AI improves, what it complicates and where it should step aside. To organise the first version, define a hypothesis, a complete user journey and a test protocol before development begins.

Unsure whether you need a workflow, an assistant or an agent? Bring us a few representative requests. We can start with the work to be done and the actions that are allowed, before selecting the architecture.