AI agent vs Zapier or n8n: where the model belongs

The question I get is "should we use an AI agent or just Zapier?" It's usually the wrong split. Most of a business workflow is rules, and Zapier, Make and n8n run rules well. A model earns its place at the one step where the input has no fixed shape. Then something that is not a model has to check what it produced.

What the platforms are built for

Zapier counts a task for every successful action step. Triggers, filters, paths, Formatter steps and failed steps don't count, and an AI by Zapier step is charged by the model tier you pick (Zapier Help: how task usage is measured). The pricing tells you what it's for: moving data between apps when a rule says so.

n8n has an AI Agent node. You connect a chat model and at least one tool, and the agent decides which tools to call (n8n docs: AI Agent node). That is the full agent pattern: the model picks the path at run time.

Both are good tools. Neither one decides for you which steps should be rules and which should be a model, or what a correct output looks like.

Four questions that place the model

The free Workflow Test on /ai runs seven checks on a described process. Four of them decide where a model goes:

1. Can someone write the decision rules down? If yes, those steps are rules. Put them in Zapier, n8n or code. If a person decides case by case, a model should draft and the person should decide.
2. Does the input have a fixed shape? Form fields and spreadsheet rows don't need a model. A free-text email, a scanned PDF or a drawing does, for one step: pulling the facts out.
3. Does a mistake reach a customer or money? Then a person approves before it goes out, whatever runs the steps.
4. Can you say what a correct result looks like? If not, nobody can tell you it works, including whoever builds it.

A worked example: our own intake

The Workflow Test is a live AI workflow on byitl.com. Someone describes a process in a form, and three stages run:

• One model call. Claude, no tools, output constrained to a schema (a second model is tried only if the first declines). For every fact it extracts, it has to copy a quote from the submission word for word.
• An evidence check, in plain code. A fact survives only if its quote is really in the submission, at least 8 characters, ignoring case and whitespace. A system name survives only if the visitor typed it. Anything unbacked becomes unknown.
• A review engine, in plain code. Seven fixed checks over the surviving facts. Each returns PASS, FAIL, ADVICE or UNKNOWN with the measured value and the smallest fix.

Then I read the report and approve it before anything is emailed.

The model is the only part that can be wrong in an interesting way, so it's the only part fenced in. It doesn't pick a path. There is no agent loop.

To show the fence working, I wrote a short example submission and handed the code a profile with three planted errors, the kind a model makes: a sign-off quote that isn't in the text, a "yes, they have past examples" with no quote at all, and a system (NetSuite) the visitor never named.

The submission:

Supplier invoices come into ap@ as PDF attachments, about 120 a month. Maria keys each one into QuickBooks and matches it to the PO in our ERP. If the total is more than 2% off the PO she holds it and emails the buyer. Payment runs go out every Friday.

What the evidence check returned:

unverified:      humanSignoff, examplesAvailable
droppedSystems:  NetSuite

The review over what survived:

Ready after changes · score 75
FAIL     Definition of done      No description of a correct result
PASS     Decisions follow rules  Decisions follow stated rules
UNKNOWN  Oversight matches risk  Not stated in your description
UNKNOWN  Test material           Not stated in your description
PASS     Volume pays back        About 120 a month
PASS     Inputs                  Inputs with a fixed shape (emails, invoices)
ADVICE   Scope                   4 steps across 2 systems

All three planted errors were stopped before scoring. The invented sign-off didn't turn oversight into a PASS. It became UNKNOWN, which asks the visitor instead of assuming.

Here is what the check does not catch: a real quote attached to the wrong conclusion. The same profile cited "Payment runs go out every Friday" as its evidence that mistakes cost money. The quote is real, so it passed. Whether it supports the claim is a judgment call, and that's why a person approves every report. The gate narrows what I have to read. It doesn't replace reading it.

So which one?

For that invoice process the answer is mostly rules: match the total to the PO, hold anything more than 2% off, email the buyer. Any of the platforms can run that. The one step that needs a model is reading the PDF. The step everyone skips is writing down what a correctly keyed invoice is, so the read can be checked on every run.

That's the split I'd use anywhere:

• Rules for every decision you can write down, in the tool you already pay for.
• A model only where the input has no fixed shape, and it has to back its output with evidence.
• Plain code that checks the model's output against that evidence, on every run.
• A person before anything reaches a customer or money.

An agent that picks its own tools is worth it when the path really can't be written down. Each choice it makes is one more place to be wrong, and one more thing to test.

The two posts behind this approach are Make the agent cite a source and The third reviewer has to be blind.

Not sure where the model belongs in your process? Describe it in the Workflow Test and you'll get the same report back, or see how a verified build works.