When Should a Business Use an AI Agent?

A lot of the AI agents people ask us to build are really workflows in disguise.

The pitch usually sounds great. An agent reads every customer request, decides what to do, updates the CRM, pings the right person and moves on. Then somebody asks a boring question, do most of these requests follow the same few rules? and the whole idea deflates. If every request from one region goes to one team, you don't need something that thinks. You need an if-then rule. An agent would add cost, testing time and a brand new set of ways to fail, and the customer would never notice the difference.

That's not an argument against agents. Anthropic, one of the companies building them, says the same thing in its own guidance: find the simplest solution possible, and add complexity only when you need it, which, sometimes, means not building an agent at all. The reason is simple. An agent trades predictability, speed and cost for flexibility, and flexibility is only worth paying for when the problem actually demands it. Here's how we help businesses work out which side of that line they're on.

Most "agent" requests need one smart step, not a smart system

Take a contact form where a customer rambles for four sentences about what's broken. Rules can't read that, so people jump to agents. What they usually need is one intelligent step: a language model reads the message and pulls out the product, how urgent it sounds and a short summary. Then ordinary rules take over, route it, update the CRM, notify whoever's on point. The AI does the one job rules can't do. Everything else stays cheap, fast and easy to test, and when something breaks you know where to look.

That's the difference Anthropic draws between workflows, where your own code decides the steps, and agents, where the model decides. Most business problems sit comfortably in the first category. A useful way to check is to work down a ladder: plain code if the rules are known, a tool like n8n if data just needs to move between systems when something happens, one AI step if only one stage needs to understand language, and a document-search assistant if the job is answering questions from your own files. A lot of agent projects end somewhere on the way down. The ones that reach the bottom are the ones worth building.

What an agent actually changes

The real difference is who chooses the next step. In a workflow, you decided it in advance. In an agent, the model does. OpenAI's practical guide to building agents suggests saving them for cases with complicated decisions, rules that are hard to maintain, or lots of unstructured information, which matches what we see.

Here's how it works in practice. The agent is given a set of tools, say, a lookup for payment history and a way to draft a refund request, each with a plain description. Imagine it's investigating a possible duplicate charge. It decides it needs the transaction history, calls the lookup, and sees two identical charges seconds apart. So it drafts a refund request for the duplicate, and then it stops and hands the draft to a person for approval. Reason, act, read the result, decide what's next, repeated until the job's done or a limit is reached. The model never touches your systems directly; your software runs each tool and passes back the result.

That flexibility isn't free. Agents add delay, cost more per task, give different answers from one run to the next, and fail in new ways, like getting stuck in loops or choosing the wrong tool at the wrong moment. A chatbot that answers questions isn't automatically an agent, and neither is a workflow with one AI step in the middle.

When the extra cost is worth it

The clearest sign is that the right next step depends on context, not just a field value. A rule can say billing goes to Finance. It falls over when one message mixes a billing complaint, a failed delivery and a refund request, and someone has to decide which comes first. Another sign is a process whose rules have turned into a monster, an exception every month until changing one branch breaks two others. An agent can take over the parts that need judgment, but please don't use one to hide a process nobody understands.

Messy inputs are the third sign: emails, contracts, call transcripts, long customer complaints. A procurement assistant might read a supplier's enquiry, notice what's missing, find the purchasing policy and draft a reply while leaving the actual approval to a person. The fourth is a path that changes from case to case. Think of an IT support agent that works out the problem, checks approved troubleshooting guides, looks up permitted system details and then suggests a fix or hands off to a human. Or a sales research agent that gathers information from approved sources and writes a summary. Several steps alone don't make the case, because a fixed sequence is just a workflow. Agents pay off when step three depends on what step two found and when they can read an error, adjust and try again instead of giving up.

The last sign matters most to us: you can tell whether it worked, and you can put a fence around it. Can you define a correct outcome? Limit what the agent can touch? Review what it did? If not, wait and the same goes if the data is stale, a mistake would cause real harm, or nobody owns the system's behavior.

Giving an agent authority without losing sleep

Once a use case qualifies, the most useful design idea is to separate analysis from authority. A supplier-recommendation agent might pull vendor data, compare prices and draft a recommendation, yet be unable to place an order without sign-off. Three simple rules do most of the work. Start with the least access possible, read-only by default, with looking things up kept separate from changing things. Put a person in front of anything that changes something real, like an external email, a payment or a database record. And set hard limits on how many steps, how much money and how much time one task can use, with a handoff to a human when the limit's reached. Those limits should live in the system's settings, where the model can't argue with them, not in the instructions it reads.

This isn't just our opinion. Security groups like OWASP list "excessive agency" among the main risks for AI applications, and the NIST AI Risk Management Framework offers a structured way to govern and measure it. Two small habits help as well: use a cheaper, smaller model for routine steps like routing, and save the larger one for real reasoning. And make sure the person approving can actually see enough to check what they're approving, an Approve button protects nobody if the reviewer is clicking blind.

Judge it by the work it finishes

The best agent isn't the one with the most tools or the smoothest demo. It's the one that finishes tasks correctly, needs a person only when it should, handles exceptions sensibly, and costs less per completed task than the old process. Test it before launch on ugly cases: unclear requests, missing data, tools that fail, things it should refuse. Start narrow, study how it fails, and widen only when the evidence says you can.

So before you build anything, check whether a simple workflow or a document-search assistant could already do the job. If it can't, write down exactly what the agent may and may not do, put a human in front of every payment or change, and set your limits before the first live run, not after the first surprise bill. Don't ask whether your business can use an agent. Ask whether this particular problem needs one. When it does, build small and fence it in. When it doesn't, you've just saved yourself a very expensive demo.

Murphy Repos helps businesses work out whether a problem needs an agent, a simple workflow or a mix of both, then builds it with the controls it needs. If you're weighing it up, book a consultation and we'll walk through what's actually worth building.

Frequently asked questions