What is an AI agent?

An AI agent is a system that, given a goal, decides for itself which step to take and when. It uses the tools it has been given — an inbox, a CRM, a calendar, a database — in whatever order the situation calls for, checks intermediate results and changes course. What separates it from a chatbot is not fluency, it is authority over the decision.

Where agents, chatbots and classic automation diverge

The three appear in the same sentence often enough to blur together, yet the difference is architectural rather than technological: who makes the decision.

That last row matters. An agent is the most expensive option to build and to run, which makes the useful question not "could we build an agent" but "does this process actually require a decision".

What an agent is made of

Three layers, each of which is a separate design decision.

• The model. The component that decides. This is where the trade-off between task difficulty and cost gets settled; calling the largest available model at every step is needless expense for most work.
• The tool set. The functions the agent may call: a CRM lookup, an email send, a file read, a calculation. The narrower the tool set, the more predictable the agent — broad authority means a broad failure surface.
• Memory. What carries state through the task. Without it the agent restarts from nothing at each step; with unbounded memory both cost and confusion grow.

n8n is one of the workflow engines that can bind those three together, and it ships a native AI agent node — see what is n8n.

Where it pays off in B2B

The cases where agents earn their keep share a trait: the input is unstructured and the right step depends on what arrived.

• Support triage. Working out what an incoming message is about, routing it to the right team, and answering from the knowledge base where it can.
• Sales qualification. Reading a free-text enquiry, asking for what is missing, and routing it onward or to the archive. Our own multilingual WhatsApp sales agent sits in this pattern.
• Internal document search. Deciding which source to consult before answering — a case where the agent alone is not enough and needs RAG behind it.

When you do not need an agent

This section reads against our own interest, and it is still the question that saves the most time.

If your process can be written as "when X happens, do Y", do not build an agent: rule-based automation is cheaper, more predictable, and when it breaks you find out why in five minutes. If your input is already structured — form fields, a fixed-schema integration, a tidy CSV — there is nothing for a decision layer to decide. And where the process touches irreversible actions, putting a human approval step in front of the model is almost always the right call.

These three are not mutually exclusive. In most real systems the agent handles only the step where the ambiguity lives, and the rest stays classic automation.

The constraints that show up in production

Three things stay invisible in a demo and surface under real traffic.

Cost is hard to predict. Because the agent decides how many steps to take, the same task can consume three model calls one time and eleven the next. A ceiling on step count is the first rule to write.

Observability is not optional. When an agent does the wrong thing, you cannot fix what you cannot see. Logging the input and output of every tool call is a requirement to design in, not a feature to add later.

Authority is easy to grant and hard to bound. Starting with a narrow tool set and widening it as needs appear costs far less than starting broad and pulling privileges back.

How to start

Pick one process and write down its decision point: what input arrives, what decision has to be made, and what happens when that decision is wrong. If those three have clear answers, the scope of the agent is settled too.

Scope, timelines and price bands are on the AI agent development page.