Most "AI agents" aren't agents

Last month our adverse media parser pulled a news article with a stray character in the ad markup. The JSON broke. The downstream LLM enrichment never ran. n8n marked the workflow failed and stopped. I found out the next morning when a compliance report came back thinner than it should have been.

That was when I decided to rip n8n out of CekapAI.

But the post isn’t about n8n. It’s about why I reached for n8n in the first place, and why most teams shipping “AI agents” right now have made the same mistake.

An agent decides what to do next based on the current state. A pipeline runs what was decided in advance. Most things called “AI agents” today are pipelines.

That sounds like a semantic argument. It isn’t. The label changes which tools you reach for, which constraints you apply, and which failure modes you plan for. Get the label wrong and every downstream decision drifts.

Three shapes of LLM systems show up in production:

• Deterministic pipeline. Fixed steps, LLM as a function inside a script. OCR, extract, store.
• Constrained agent. The system decides what to do next, but inside real boundaries — guarded steps, partial ordering, fallback paths, human checkpoints.
• Fully autonomous agent. Minimal predefined structure, tool discovery, open-ended reasoning. Rare in regulated work.

In CekapAI I run the second and the third. Screening and scoring are constrained with fixed prerequisites, fixed regulatory outcomes, dynamic execution. Adverse media ingestion is autonomous, the system decides what to read, what to extract, what’s worth flagging. So I’m not arguing this from a tutorial.

The mistake I see most often is shape one getting labeled shape two. A team builds a fixed-sequence LLM pipeline, calls it an “agent” because LLMs are involved, then picks a workflow tool to manage it because “agents need orchestration.” That’s how I ended up on n8n. The LLM was doing real work, but the system around it was running the same path every time. It wasn’t deciding anything. It was a pipeline with model calls.

Once you see the pipeline for what it is, the tooling fight ends. Plain code beats a workflow tool for fixed sequences, every time. n8n’s trigger-to-execution overhead in CekapAI was 5–10 seconds per run. The replacement (a custom agent loop with tool calling, multi-model routing, ~1 second per run) was faster, but the real win was that I stopped pretending the system was something it wasn’t.

A few counters I expect.

Constrained agents have predefined structure too — does that make them pipelines? No. A constrained agent decides which tool to call, in what order, given the input. The structure bounds the decisions, but decisions still happen. A pipeline has no decisions. The distinction is whether the system’s behavior depends on what it sees, or whether it runs the same path regardless. Constraints don’t kill agency. Predetermination does.

Regulated workflows require a fixed sequence. They require fixed prerequisites, not a fixed order. eKYC, sanctions screening, and PEP check have no dependency on each other — run them in parallel as separate tool calls. Risk scoring depends on all three, so the agent waits for the data and calls the scoring tool. The sequence emerges from dependencies, not from a graph someone drew in advance. Same regulatory outcome, faster.

Our fixed-sequence LLM pipeline works fine. It probably does. But then it’s a pipeline, and you should call it one. Plain code is better for it than a workflow tool, and the moment you call it an agent, you reach for tooling that makes it worse. The naming creates the bad tooling decision.

The category error isn’t agents versus pipelines. It’s pipelines mislabeled as agents.

If your “AI agent” runs the same path every time, it’s not an agent. It’s a chatbot, or a workflow with LLM calls inside. Both are useful. Neither is what you’re selling when you say “agent.”