Workflow Automation or an AI Agent? Start With the Decision
Choose automation around the decisions a process requires. Map the predictable steps, identify the exceptions, and evaluate the result before giving a system more freedom to act.
- Separate fixed steps from judgment
- Map a small process from start to finish
- Add flexibility where it has a purpose
- Define what the system may change
- Check the outcome, including the exceptions
- Give the pilot a concrete decision
Separate fixed steps from judgment
A workflow follows steps defined in advance. An AI agent can decide how to proceed, including which tools to use and how to respond to intermediate results. Both can use language models. The useful distinction is how much control the model has over the process.
Begin by writing down the decisions involved in the task. If each decision has a clear rule, a conventional workflow may be sufficient. If the next step depends on information the system must investigate, some agent behaviour may be useful.
Map a small process from start to finish
Consider a fictional support team receiving delivery enquiries. A simple process might identify an order number, retrieve its status, select an approved message, and send the case to a colleague if information is missing.
Describe the trigger, inputs, systems involved, expected result, and owner. Include the awkward cases: an invalid order number, two matching records, a delayed system response, or a customer asking several things at once. These details reveal the actual scope more clearly than a broad request to "automate support."
Add flexibility where it has a purpose
An agent may help when resolving the enquiry requires examining several records and choosing the next check. That flexibility also creates more possible paths to evaluate. Additional model calls and tool use can increase elapsed time and operating cost.
Compare the simplest workable design with the more flexible option on the same examples. Ask which extra cases the agent handles, how often it needs assistance, and whether that improvement matters enough to justify the added complexity.
Define what the system may change
Reading an order and changing an order have different consequences. List permitted actions explicitly. For the fictional pilot, the assistant could retrieve tracking information and prepare a response, while an employee approves a refund or delivery address change.
Specify what should happen when a tool fails or information conflicts. A useful handoff includes the request, relevant evidence, attempted checks, and unresolved issue. Assign someone to receive it. An escalation button without an owner leaves the work unfinished.
Check the outcome, including the exceptions
Evaluate what happened in the business system, as well as what the assistant said. A message claiming that a ticket was updated is insufficient if the record remained unchanged. Define success before testing, with clear criteria for completion and acceptable escalation.
Use representative tasks and repeat selected cases because model behaviour can vary. Track correct outcomes, unwanted changes, review effort, time, and cost per completed task. Include requests that should be declined or handed over, as well as cases the automation should complete.
Give the pilot a concrete decision
Agree on the evidence needed to expand the pilot. A team might require reliable handling of ordinary enquiries, consistent handoffs, and no unauthorised changes in its test set. That is an illustrative acceptance rule, not a universal standard.
Keep the examples and results when changing prompts, tools, or models. They provide a way to check whether the revised system still does the work that made the pilot worthwhile.
Further reading
Primary references behind the technical guidance in this article.
Put the thinking into practice.
Explore our ai agents & automation services, or talk to us about the task you want to improve.
Explore the service
