Agents, automation or an API: how to choose

Three mechanisms take work off people, and they are frequently confused because vendors describe all of them in similar language. They have different costs, different failure modes and different maintenance profiles.

Integration: systems exchanging data

Two systems need the same information and someone is currently moving it. An integration does this reliably, on a schedule or on an event, with error handling when the other end is unavailable.

Use it when: the data is structured, the mapping is fixed, and nothing has to be judged. Cost profile: real build cost, low run cost, breaks when an interface changes on either side. Failure mode: silent. A load that fails without telling anyone is the classic problem, which is why monitoring is not optional.

Rules-based automation: a defined process, executed

A sequence of steps with conditions, running against systems through APIs or through the screen. Robotic process automation is the version that works where no API exists.

Use it when: the process is stable, the rules can be written down, and the inputs are consistent. Cost profile: moderate build, low run, maintenance whenever the target application changes. Failure mode: brittleness. Screen-based automation breaks on cosmetic changes, which is manageable if it is engineered as software rather than recorded.

An agent: judgment within limits

Reads something unstructured, works out what it means, decides within defined boundaries, and hands out what it cannot resolve.

Use it when: the input varies in format or wording, there is genuine interpretation involved, and a person can review the exceptions. Cost profile: moderate build, higher run cost because usage is billed by consumption, plus ongoing evaluation and content maintenance. Failure mode: confident wrong answers. This is why the supervision design matters more than the model choice.

How to tell them apart quickly

Ask one question: can you write down the rule?

If yes, write the rule. A deterministic mechanism that always does the same thing is cheaper to build, cheaper to run, easier to test and easier to explain to an auditor. Using an agent where a rule would work is the most common and most expensive mistake in this category.

If you cannot write the rule because the input varies too much — dozens of invoice layouts, free-text descriptions, questions phrased differently every time — that variation is what an agent is for.

The combination most real processes need

Most useful work is a mix. An agent reads the document and works out what it is. Rules apply the business logic once the data is structured. An integration puts the result where it belongs. A person handles what the agent flagged.

Designing it as one thing — “an agent that does the whole process” — produces something expensive and hard to test. Designing it as four components lets each part be the cheapest mechanism that fits.

The question to ask a vendor

When a product is described as agentic, ask which part is the agent. Often the judgment is a small step in a workflow that is otherwise ordinary automation — which is fine, and it should be reflected in what it costs.