AI agent or workflow automation? Stop hiring a robot for a checklist

Use ordinary automation when the rules and next steps are known. Add AI when a defined part of the job involves interpreting messy language or other ambiguous input. Consider an agent when the system genuinely needs to choose a sequence of actions as circumstances change. None of those choices removes the need for a person to own the outcome.

That is the short version. The longer version starts with an uncomfortable possibility: your company may have an ownership problem wearing an AI-agent costume. Before buying autonomy, check whether anybody can explain the current process without saying “and then someone sorts it out.”

One support request, three possible designs

Take a fictional business that receives customer emails. Some ask for opening hours, some contain incomplete order details, and some need investigation across several systems. The same inbox can contain three different kinds of work. It does not follow that every email needs the most elaborate solution.

Anthropic distinguishes predefined workflows from agents that direct their own tool use, and recommends starting with the simplest approach that meets the need. That is an architectural distinction, not a requirement to replace every useful script with a conversational colleague.

Ask where the uncertainty actually lives

If uncertainty is only in reading an email, the model may just need to extract a few fields or propose a category. The rest can remain a predictable process. If uncertainty is in choosing which evidence to collect next, a more flexible system might help. If uncertainty is about who is allowed to make the decision, software cannot settle it for management.

In the fictional inbox, the model might suggest that a message concerns a late delivery. A normal workflow can then check whether an order number is present and send the item to the correct queue. That is already useful. It does not need authority to negotiate compensation, alter a customer record and announce a new returns policy.

Autonomy is a permission decision

Before allowing a system to act, separate reading, drafting, proposing and changing. Reading an approved help article is different from editing an invoice. Drafting a customer response is different from sending it. A process can use the same underlying model in all four situations while requiring very different controls.

My practical starting point is a permissions sheet: the available tools, the records each can access, the changes it can make, the actions requiring approval and the route back to a person. Put a name beside the owner. “The AI team” is not always a person who will notice a failed handover on a Tuesday afternoon.

Test the boring failures

A useful pilot should handle ordinary inconvenience: a missing field, a duplicate request, a changed document, an unavailable destination and a customer who asks two things at once. Include an instruction embedded in a document that should be treated as content rather than authority. Ask the builder to show what happens when the system cannot complete its plan.

• Can it stop without inventing success?
• Can someone see which action happened and which did not?
• Can it avoid performing the same change twice?
• Can the team restore manual handling when needed?
• Does an unresolved case reach a person with enough context to help?

These are my proposed acceptance questions for a workflow discussion, not a certification test. The NIST AI Risk Management Framework offers a broader voluntary approach to managing AI risks across a system’s life. A small pilot still needs ordinary operational judgement.

A simple measure beats an impressive transcript

For the inbox example, track accepted cases, review effort, incorrect routing and time until a customer receives a useful answer. A long chain of tool calls may look sophisticated while creating more review work. Compare the proposed design with a simpler alternative using the same examples.

Also count waiting. A model can finish in seconds while the item waits two days for a manager who never knew approval was required. That is a workflow-design problem, and it will not disappear when the interface learns to say “I’m on it.”

Give the process a clear first job

A reasonable first brief is: help the team classify these requests, prepare a draft and show the supporting information. The team remains responsible for sending. A later stage may allow a carefully bounded action when the evidence and rules justify it. Expansion should follow observed usefulness and a deliberate authority decision.

I work on this boundary between product choices and implementation. My workflow automation approach starts with the repeated work, its exceptions and the person responsible. If an ordinary integration solves the problem, that is a good result. You are buying a better working day, not an employee costume for your software.

Questions people ask

What is the difference between an AI agent and workflow automation?

A workflow follows an established path. An agent can decide which steps or tools to use as it works towards an outcome. Many practical systems combine a predictable workflow with one AI-assisted step rather than giving the whole process autonomy.

When should a business use an AI agent?

Consider one when the next action cannot sensibly be fixed in advance, tools can be restricted and success can be evaluated. Start with a bounded pilot, clear ownership and a review path for consequential actions.

Can ordinary automation be better than AI?

Yes. Stable rules, structured inputs and known next steps can often be handled with simpler integrations. Compare options on accepted outcomes, maintenance, review effort and failure handling rather than on how sophisticated the demo looks.