AI automation, integration or an agent: which a job needs

An AI automation runs a sequence of steps that someone wrote down before it ran. A model does the steps a rule can’t, such as reading a scanned invoice. An AI integration puts a model inside a product your customers already use. An AI agent chooses its own next step, so nobody can list its actions in advance.

So two questions sort almost any job. Can you write the steps down before the first run? And who uses the result, your staff or your customers?

We asked AI engines this question on 24 September 2026, worded as “What is the difference between AI automation, AI integration and agentic AI?”. Four engines answered three times each, and none of the 12 answers cited our site. On 1 October three engines answered it again, and none of the 9 answers did. This is our answer, with our own systems as the examples.

What does each one build?

An AI automation is a fixed workflow inside your company. Intake and routing, pulling fields out of invoices, reconciling two systems that should agree, a first draft that a person edits. Its users are your own staff, and we measure it in hours removed per month.

An AI integration is a feature inside a product people pay for, such as a summary button. Its users are your customers.

An AI agent plans and acts over several steps in your tools, and picks its route as it goes. A refund that needs a shipping lookup first, or doesn’t. A ticket that turns out to be a billing problem, a bug, or neither. We measure it by how many actions it takes without an incident.

Anthropic’s engineers draw the same line between workflows and agents. Workflows are “systems where LLMs and tools are orchestrated through predefined code paths”. Agents “dynamically direct their own processes and tool usage”.

That piece dates from December 2024, and the tools it lists have changed since. The line has held.

The test: does it decide, or does it follow steps?

Draw the job as a flowchart. If you can draw every box and every arrow before the first run, it is an automation. That holds even when a model fills one of the boxes. If the next step depends on what the system finds, and you can’t draw the arrows in advance, it is an agent.

Integration answers a different question: who presses the button. If a customer does, it is an integration, whatever shape sits behind the button.

	AI automation	AI integration	AI agent
Who uses it	your staff	your customers	it acts for your staff
Steps known before it runs	yes	yes, per request	no
What we measure	hours removed per month	whether customers use it	actions taken without an incident
What it can do	the actions written at build time	what the feature allows, after a confirmation	what its credentials allow

What we run ourselves

Our answer-engine-benchmark is an automation. It asks each engine the same questions, three times each, and counts which answers cite which sites. The model writes the answer. A script does everything else, in the same order every run. On 1 October 2026 it collected 270 answers for $1.38 in API fees.

The other example runs the other way round. For Live Tennis API we built an MCP server, so a developer’s own assistant can query the API. npx livetennisapi-mcp gives Claude, Cursor or any other MCP client 24 tools. The assistant is the agent, and it belongs to the developer. Our part was deciding what it is allowed to do. Every tool only reads, and the API behind them never touches orders or wallets.

You can’t control how someone else’s agent plans. You can control what it is able to reach.

Where does a person stay in the loop?

In an automation the list of actions is closed. The workflow can take four or six or nine actions and no others, so each one can be sorted by cost to reverse. Reclassifying a ticket is cheap to undo and runs on its own. A refund, an external email or a write to a system of record waits in an approval queue. The person sees the output and the evidence behind it.

In an integration the person in the loop is often your customer. Anything that writes, sends or pays gets a confirmation step. The model’s output is checked against a schema before anyone sees it.

An agent’s actions can’t be listed, so the controls have to bound them instead. It gets its own credentials, scoped to an agreed set of actions. Every irreversible action waits for the person who owns that system. It runs in dry-run first, emitting the exact call it would have made, and it has a kill switch a non-engineer can reach. OWASP calls the failure Excessive Agency: an agent with more permissions or autonomy than its task needs.

What does each one cost to run, and to break?

An automation costs the model calls in the steps that need one. Several steps in a typical workflow have no model at all, and every run is logged with its cost. When it breaks, it breaks at a known step, and you can rerun that step.

An integration costs per request, and retries and long conversations are where the bill grows. It breaks in front of a customer, so it ships with a plan for the hours the model provider is down.

An agent costs the most to make safe. The permissions, the dry-run and the audit trail are most of the build. Anthropic’s piece says the same about running one: agentic systems “often trade latency and cost for better task performance”. It breaks in ways that are hard to see. An instruction hidden in an email it reads can steer it, and only its permissions limit what that instruction can do.

Which one should you build first?

Write the job down as steps. If you can, build the automation, and put a model only in the steps a rule can’t do. If a lookup or a query solves a step, use that instead. Code like that is cheap to run and easy to test.

If your customers need it inside your product, it is an integration. Build the test set of real inputs before you write the prompt, so you can tell whether a change helped.

Build an agent when the route really does depend on what the system finds, and you can still list everything it is allowed to touch.

For a software company, our B2B SaaS playbook names four internal workflows to cost first, starting with security questionnaires.

We build all three, as separate services. Our page on internal workflows says how we measure the hours. The one on model features inside a product covers the test set and the outage plan. And the one on agents that act in your systems lists the controls an agent gets before it acts.