AI Agent vs n8n vs Custom Code: What Should You Actually Build?

Picture a common one. Every Monday someone on the marketing team opens a dozen tabs, reads what the audience has been asking about, checks which topics were already covered, writes a short brief for each promising idea and posts the list in Slack. It takes most of a day, and it's the first thing to slip in a busy week.

Three people look at it. The AI enthusiast wants an agent that "does the research". The ops lead says n8n could wire it up in an afternoon. The engineer offers to write a script. Each of them is right about part of the job, and each will build something painful if they get all of it.

• An agent doing the whole job takes a different path on every run, which makes both the bill and the bugs hard to predict.
• n8n doing the whole job becomes a canvas of sixty nodes, with business logic hidden in expression fields that nobody dares to edit.
• Code doing the whole job turns the one fuzzy step, "is this idea any good", into a pile of keyword rules that still misses.

The fix is to stop choosing per workflow and start choosing per step.

Split the workflow before you pick a tool

Write the workflow down as a list of steps, one line each. Then tag every line.

• Rule. The same input always gives the same output, and you could write it as an if-statement. Deduplication, pricing, eligibility, permissions.
• Plumbing. Data moves from one system to another on a schedule or a trigger. Fetch, post, sync, notify.
• Judgment. Someone reads unstructured text and decides or writes something. Classify this email, summarize this call, pick the best of these twenty, draft this brief.

Rules go in code. Plumbing goes in a workflow tool. Judgment goes to a model, as a narrow step with a defined output. Most business workflows turn out to be mostly rules and plumbing, with one or two judgment steps in the middle. That's good news, because it means most of the system can be boring.

Code owns the rules and the state

Code gets anything that holds state or money, or that has to be true every single time. If a step decides who gets charged or who can see a record, it belongs in code with tests. Code is also where the source of truth lives: which ideas were already used, and which run failed at which step.

Where n8n fits

n8n and tools like it are good at plumbing. Triggers, schedules, calls to other SaaS APIs, retries on a failed request and a run history that a non-engineer can read. For moving data between systems they're usually faster to build than custom code, and easier for the ops team to watch.

They get painful when the canvas becomes the product. Branching business logic in a visual editor is hard to test and hard to review in a pull request, and one edited node can quietly change what the whole flow does. When a workflow grows past a screen of nodes, we move the logic into code and let the workflow call it.

We built API Nation, an integration marketplace that connects SaaS tools, so we've spent a lot of time in this layer. Most of the work in integrations is unglamorous: tokens that expire, rate limits, pagination, APIs that change without notice. A workflow tool handles some of that for you. Nothing handles all of it.

The model gets the ambiguous part

That means reading a messy input and producing a decision or a draft: is this support email a refund request, or which of these twenty ideas fits our audience. No rule engine gets those right, and that's where a model earns its cost.

Give it a narrow job. One input and one task, with a structured output your code can check. Don't hand it the workflow.

When you actually need an agent

An agent is a model in a loop that decides which tool to call next. That's worth it when you can't know the sequence of steps in advance, like an open-ended investigation where each finding changes what to look at next.

Most business workflows aren't like that. The steps are known, and only the content varies. For those, a fixed pipeline with one or two model calls is cheaper to run, and it does the same thing this Monday as it did last Monday. We start with the pipeline almost every time, and add a loop only when a step truly needs one.

A worked example: content-idea research

We fully automated content-idea research for Xperiencify and Coaching Genie, replacing a workflow people used to do by hand. Pipelines of that kind split cleanly. Here's the general shape:

Notice how little of it is AI. One step out of six. That step is also the only reason the workflow couldn't be automated before, so it gets the care: a fixed output format, and a person picking from what comes out.

The same split shows up in Irresistible Bot, the AI copywriting agent we built for Vrinda Normand. Writing the copy is the model's job. The structured onboarding that collects each user's brand context before the first generation is ordinary product work: questions, and the fields that store the answers.

The shape we like

For anything past a toy, the product owns the state. A run is a record in your database with a status. A workflow tool or a job queue executes the steps. The model gets called for the judgment step and returns JSON, and code checks that JSON before anything is saved. Retries are capped, and a run that stalls gets flagged so a person can look.

When something breaks at 3 a.m., you can see which step failed and rerun only that step. That's the difference between an automation your team trusts and one they quietly stop using.

The split, as a checklist

Run it before you pick a tool, not after.

1. Is the workflow written down as a list of steps, one line each?
2. Is every step tagged as a rule, plumbing or judgment?
3. Does everything that touches money or permissions live in code with tests?
4. Is the workflow canvas small enough that one person can explain every node?
5. Does each model step have one job and a structured output that code validates?
6. Does a person review the output of judgment steps before it reaches a customer?
7. Can you see which step failed in last week's runs, and rerun only that one?
8. If you're planning an agent, can you name the step whose sequence you can't know in advance?

If you can't answer the last question, you don't need an agent yet. You need a pipeline.

Related reading

• The AI coaching stack: what to automate and what must stay human: the same split, applied to a coaching platform
• Brand-grounded AI copy: why more prompting does not fix missing context: what the judgment step needs to know before it writes
• Your AI prototype works. Here is why it will fail in production: what to check before an automation runs for every customer

The service: AI Product Development. Integration work: API Nation.