AI Agents for Business: Where They Pay Off and Where They Do Not

“Do we need an AI agent” is almost always the wrong question. The right one is “which process are we trying to make cheaper, and why with this tool”. Otherwise the project serves the technology rather than the result.

Processes where an agent wins

The markers of a process where an agent genuinely pays off:

• The input is unstructured text. Emails, tickets, documents, free-form requests. This is exactly where a model does what ordinary code cannot.
• Volume is high and steady. A one-off task does not repay the build.
• The cost of a single error is low. A wrong ticket category is fixable; a wrong payment is not.
• Errors are detectable. This is critical: a process where nobody notices the mistake cannot be automated at all, by agent or by code.
• The rules are hard to write down. If the process is easily expressed as conditions, writing them is cheaper.

Typical candidates: first-pass ticket handling, classification and routing, turning documents into structure, drafting replies, gathering and reconciling data from several sources.

Where ordinary automation is cheaper

The most common deployment mistake is putting an agent where a workflow was enough.

If the data is already structured and the rules are known, the task is solved by wiring services together with no model at all: cheaper to run, more predictable, debuggable in minutes. That class of tool is covered in the n8n guide.

A cost anchor: a workflow step costs a fraction of a cent, an agent step costs hundreds of times more. At ten runs a day the difference is invisible; at ten thousand it decides the economics.

Scraping and data collection is its own case. There the model is usually needed only for the unstructured part, while collection itself is code.

Calculating payback honestly

Count four numbers, not two.

What the process costs now. Hours times cost per hour, plus the cost of delay if there is one.

What it will cost with an agent. Tokens per run times volume, plus infrastructure. Use the real step count, not the ideal path: the gap is usually three to four times.

What the error rate costs. Take the measured failure percentage and multiply by the cost of investigating each. This is the line item people skip, and it is the one that most often eats the saving.

What maintenance costs. Input formats change, models change, integrations break. A system without an owner degrades within months.

The practical rule: before a pilot on real data, payback numbers are a hypothesis. Two weeks in observation mode, where the agent proposes and a human decides, gives you the true error rate. After that the sums mean something.

Risks that rarely get modelled

• Data leaves your perimeter. Anything that entered context went to the model provider. For personal data and trade secrets, that question is settled before deployment, not after.
• Provider dependence. Price, availability and model behaviour are outside your control. Design for swapping the model from the start.
• Quiet degradation. An agent does not break visibly; it starts getting things wrong more often. Without monitoring you learn about it from customers.
• False confidence. The agent’s report of success is not the fact of success. You need verification in code.

Where to start

An order that lowers both risk and entry cost:

1. Pick one process with real volume and detectable errors.
2. Measure what it costs today.
3. Build a narrow version and run it in observation mode.
4. Compute payback from measured numbers.
5. Expand only then.

If the process to automate has not been chosen yet, there is a breakdown on the blog: which processes to automate first.

To discuss a specific problem and get a scope and cost estimate, see the services page. What agent development looks like from the delivery side has its own article. The overview is in the AI agents guide.