Not Everything Is an Agent (And That's Fine)

Something funny happens when a technology concept captures the imagination of the business world. It stops being a precise technical term and becomes a vibe. Right now, “AI agent” is in full vibe mode.

I’ve sat in meetings where stakeholders have asked for an AI agent to send a weekly email summary, to look up a postcode, and — my personal favourite — to “do the spreadsheet”. These are not agent problems. These are automation problems. Some of them are barely even automation problems. But the word “agent” is exciting, and “automation” sounds like the boring thing IT already does, so here we are.

Part of my job is helping people understand the difference. So let me write it down.

What actually makes something an AI agent?

The word “agent” gets applied to everything from a simple chatbot with a system prompt to a fully autonomous multi-step AI pipeline. That range is too wide to be useful. When I evaluate whether something is genuinely agentic, I look for five components. I think of them as Data, Tools, Knowledge, Goals, and Autonomy. A true AI agent needs all five. If one is missing, you probably have something simpler — and simpler is usually fine.

Data

An agent needs to be able to see things. Not just the conversation — real information from the world it’s operating in. That might be customer records pulled from a CRM, live stock levels from an ERP, emails from a mailbox, or the current state of a workflow. Without data, an agent is reasoning in a vacuum and making things up to fill the gaps. That is not a good property for something you’re letting make decisions.

Data includes context too — the history of what’s happened in this conversation, in this workflow, or for this customer. An agent with no memory of what it’s already done is working blind, and making decisions on incomplete context is how you get outcomes that are surprising in all the wrong ways.

Tools

Tools are the action layer — the ability to call an API, write to a database, send an email, book a calendar slot, run a query, execute code, or trigger another system. They’re what make an agent actually useful rather than just convincing. Without them, all the intelligence in the world produces a well-reasoned response that a human still has to go and act on themselves, which rather defeats the purpose.

Knowledge

Knowledge is different from data. Data is what the agent can see right now. Knowledge is what the agent already understands — the domain expertise, the business rules, the constraints, the context about how the organisation works. This gets encoded in system prompts, retrieved through RAG, or baked in through fine-tuning.

Knowledge shapes how an agent interprets data and decides between tools. An agent that has no knowledge of your business processes will use its tools in ways that are technically correct but contextually disastrous. “The API accepted the request” and “the right thing happened” are two very different outcomes.

Goals

An agent needs to know what it’s trying to achieve. Not “be helpful” — that’s not a goal, that’s a personality trait. A goal is specific: resolve the customer’s query without escalation, or book the earliest available slot that meets these criteria, or extract and structure this data and flag anything that looks anomalous.

Vague goals produce unpredictable agents. The most common failure mode I see in early agentic deployments is that someone gave the agent a broad remit and is then surprised when it does something technically in scope but entirely unexpected. If you can’t write the goal down precisely, you’re not ready to build the agent.

Autonomy

Autonomy is how much the agent can act without being asked to. This is a spectrum, not a binary, and the right point on that spectrum depends entirely on the stakes involved in each decision.

At one end, you have an agent that does everything but waits for human approval before taking any action — useful for high-stakes or irreversible operations. At the other end, you have an agent that runs unsupervised, takes actions, handles exceptions, and reports back on completion. Most real-world agents live somewhere in the middle: autonomous for routine decisions, but with clear escalation paths when something falls outside expected parameters.

Autonomy is the component that makes the other four matter. Get those wrong, and adding autonomy just means the mistakes happen faster and without anyone watching.

When an agent isn’t the answer

Even when all five components could be present, that doesn’t mean you should build an agent. There are plenty of situations where the right answer is something simpler.

The process is deterministic. If the steps never change — always the same inputs, always the same outputs, always the same order — there’s no judgment required and therefore no need for intelligence. Build a workflow. It’ll be faster, cheaper, more reliable, and far easier to audit.

The inputs and outputs are well-defined. If you can write a complete specification of what goes in and what comes out, you don’t need an LLM involved. A structured data transformation is not an agent problem.

The cost of being wrong is high. AI agents make mistakes. Good ones make fewer mistakes, but they still make them. For processes where errors are costly, irreversible, or carry compliance risk, you want predictability over flexibility. A rule-based system that does exactly what you told it to every single time is often the more responsible choice.

You’re solving a solved problem. Don’t use an agent to look up a postcode. Don’t use an agent to check whether a date is in the past. Don’t use an agent to send a weekly report that never changes. These are not intelligence problems. They are execution problems, and there are better tools for execution problems.

When automation beats AI

The most underrated tool in the modern AI stack is still a simple automation workflow. n8n, Power Automate, or even a well-written cron job will outperform an AI agent on tasks that are:

• Scheduled and repeatable — same task, same time, same inputs, predictable output
• Integration-heavy — moving data between systems that already have APIs
• Audit-sensitive — where you need to explain exactly what happened and why, step by step
• Cost-sensitive at scale — LLM API calls are not free, and at volume they add up quickly compared to a workflow that runs the same logic for pennies

The question I ask is: does this task require judgment? If yes — if there’s ambiguity, variation, or context-dependent decision-making involved — an AI agent might be the right tool. If no, build the automation, get it working reliably, and spend the AI budget on something that actually needs it.

The hype around AI agents is not wrong — they are genuinely powerful when applied to the right problems. The mistake is treating “agent” as the obvious next step up from whatever you’re doing now. It isn’t always. Sometimes the right upgrade from doing something manually is a simple automation. Sometimes it’s a well-written system prompt. The choice should follow the problem, not the other way round.

Figuring that out before you start building is most of the work — and usually the part that gets skipped.