When it comes to automating work, the choice of what to use hinges on a single question: can a human map out the flow in advance? If you can draw the whole path and every fork ahead of time, a rule-based system or a fixed workflow is enough. Only when the LLM has to decide its execution path as it goes do you actually need an agent.
People often treat "using an LLM" and "using an AI agent" as the same thing, but they are not. An LLM (large language model) is an AI that has learned from enormous amounts of text, so it can understand human language and produce new sentences. Summarizing an inquiry or drafting a reply calls this LLM once, or in a set order — a "fixed workflow." An agent, on the other hand, plans on its own, picks its own tools, and works through several steps. That is why it is only needed for work whose path you cannot draw in advance. Unstructured work does not automatically require an agent (Workflows vs. agents, Anthropic).
Let's start with the big picture.
Picture a conveyor belt and you can see the essence of rule-based automation. Each part on the belt receives a fixed operation at a fixed station. The screw-tightening station always tightens screws, and yesterday and today it produces the same result in the same order. If a part suddenly comes in a different shape, the belt can't handle it and the line stops.
Picture a capable assistant and you can see an agent. Just say "find us a venue for next week's workshop," and the assistant weighs the headcount, the budget, even how well the last place went, and comes back with a shortlist — all on its own, without being told every detail. The catch: give the same instruction on a different day and the shortlist may come back slightly different, so it's natural to add one step to whatever the assistant brings back — a check to confirm "is this okay to book as is?"
In between sits the fixed LLM workflow. The running order is locked in place like a conveyor belt, but the work done at each station (summarizing, classifying) borrows a bit of the assistant's judgment. Now let's take the three apart one by one.
No-code tools like Zapier, Make, and n8n (tools you build by connecting blocks on a screen rather than writing code yourself) answer the question: "when this happens, how do I automatically handle that?"
They work through a combination of a trigger (the signal that something happened) and an action (the operation to run in response to that signal). For example, the flow goes like "a new response comes into a Google Form → add a row to a spreadsheet → send a Slack notification." Conditions and outcomes play out deterministically, exactly as a human defined them in advance — that is, the same input always leads to the same result.
The upsides are clear. It's predictable, and a log shows at a glance what ran at which step. If something goes wrong, you can pinpoint and fix just that step (finding and fixing the trouble spot this way is called debugging), and the running cost is generally low.
The limits come from the very same source. It can't handle situations outside the path you defined in advance. When a new case comes up, you have to add another branch (a fork that splits the path based on a condition), and if you leave it out, that case quietly goes unhandled. As branches pile up, the flow gets tangled, and eventually you reach a "branch explosion" where even the person who built it can no longer follow the whole thing.
These days no-code platforms are also layering on agent features — Zapier Agents, Make AI Agents. So the real dividing line isn't "no-code vs. code" but "do you lock the path with rules ahead of time, or does the system decide it on the fly?"
There's a middle tier: work that requires understanding text but always follows the same processing flow.
Summarizing a document into three lines, sorting an inquiry into a predefined category, or drafting an email all belong here. You can chain more together, too. For example, "analyze the inquiry and score its sentiment → if the score is low, write the draft in an apologetic tone; if high, in a grateful tone → hand it to the person in charge" calls the LLM several times, but the order is always the same. It takes understanding text, so rules alone won't do — but the steps it goes through and the forks it takes are all decided in advance. In that case, calling the LLM at fixed stations is enough. You don't need an agent that plans for itself.
An agent takes a natural-language goal, plans on its own, calls tools like search or document lookup when needed, and decides its next move based on intermediate results. The key point is that there is no predetermined flowchart — the LLM, not a human, controls the execution path and tool use. That, not nondeterminism, is what sets an agent apart.
This flexibility lets it handle vague requests where a human couldn't have defined every case in advance. A request like "flag anything odd in this quarter's sales report" is hard to write out as rules, but an agent can comb through the data, set its own criteria for judgment, and produce a result.
There's a price. Like any LLM call, an agent is nondeterministic — even with the same input, the result can come out different each time, and the variation isn't confined to wording: it can reach the classification it makes, the branch it takes, even the conclusion it reaches. This isn't unique to agents (a fixed LLM workflow is nondeterministic in the same way); what's distinctive about an agent is that it also decides its own path and tools (Anthropic API reference). So its output needs human verification, there's a risk of hallucination (making up false content that sounds plausible — for example, referring to a nonexistent feature or policy as if it were real), and every run incurs compute cost.
| Category | Rule-based (no-code) | Fixed LLM workflow | LLM agent |
|---|---|---|---|
| Input | Trigger + predefined conditions | Natural language, but the processing flow is fixed | Natural-language goal and context |
| Execution path | Fixed path drawn in advance by a human | LLM calls along a human-set flow (branches included) | Agent plans on the fly |
| Reproducibility | Deterministic — same input, same result | Nondeterministic — not just wording; the classification and the branch taken can vary too | Nondeterministic — widest variance, since the path itself may differ |
| Strength | Predictable, transparent, low-cost | Fixed-flow tasks that require understanding text | Vague requests, work whose path can't be mapped |
| Limit | Can't handle undefined situations; branch explosion | Fixed flow, so it can't break out for exceptions | Needs verification, hallucination, running cost |
| Human involvement | At design time (when you build it) | Verification after running | Verification after running |
Run each task through the three questions below in order. If it gets caught at an earlier level, stop there; if it passes, move to the next question. Let's follow one task all the way through: handling incoming customer inquiries.
Level 1 — Can it be handled with rules alone? "If the subject contains 'refund,' route it to the refunds channel." Where the condition and outcome fall neatly into place, lock it down as a rule. This is where no-code belongs. If the job ends here, there's no reason to reach for a more complex tool.
Level 2 — Is a fixed-flow LLM call enough? "For each inquiry, summarize the gist in three lines, sort it into a predefined category, and hand it to the person in charge." Summarizing and classifying require understanding text, so rules alone won't do. But the flow — receive → summarize and classify → hand off — is the same every time. Even if the destination forks based on the classification — a payment-record lookup for refund inquiries, a help-doc lookup for how-to inquiries — as long as a human can map out every one of those forks in advance, this is still a fixed workflow (routing). Here, calling the LLM at set stations is enough. You still don't need an agent.
Level 3 — Does the LLM have to decide the flow and tool use itself, mid-run? The dividing line isn't "does the path fork?" Even if it forks, as long as a human can write out every fork in advance, the Level 2 fixed workflow suffices. True Level 3 is when you can't write out the flow itself in advance. For a vague inquiry like "the product isn't what I thought," what to check first, how many steps to take, and which tools to use aren't set in advance. Depending on what turns up when you dig through past inquiries, you have to decide on the spot whether to look at the payment record, the shipping history, or the help docs next — and a human can't enumerate all those combinations ahead of time. This point, where the LLM has to organize its own execution path and tool selection, is where an agent belongs.
Asking the three questions in order helps you avoid the overreach of "it's unstructured, so it must be an agent." In practice, a lot of work ends at Level 1 or Level 2.
In practice, the answer isn't picking just one of the three — it's mixing them. Let's go back to the customer inquiry. The path-finding part — reading a vague inquiry, deciding what to check, and producing a draft reply — goes to an agent, while the structured part — recording that reply in the CRM (a system that gathers and manages customer information) and notifying the person in charge — is handed to rules. Instead of forcing everything into one tool, you give each one the area it's good at.
The piece you must not leave out of this structure is a human confirmation gate. If you send out an agent's draft as is, the occasional dubious result that nondeterminism produces goes out without any check. So you make the default: "the agent makes a draft → a human reviews it → only what's confirmed moves to the next step."
ONTLE is a case that builds this principle of "the mix" and "the human confirmation gate" right into the service.
You write to ONTLE like this: "Pull out the gist of this week's backlog of customer inquiries and draft replies too."
The AI agent you've dispatched doesn't work by picking from preset buttons. It reads each inquiry one by one, and for vague ones like "the product isn't what I thought," it starts by searching for similar past inquiries. If many of those led to refunds, it goes on to check the order and payment records; if it was a simple how-to issue, it pulls in the help docs and matches the tone. Since you can't lay out in advance what to check or over how many steps, the agent organizes its execution path on the fly — this part is where the agent belongs.
Then you open the drafts it produced. You soften one that came out too sharp in tone, and correct one line that got a fact wrong. Only the replies a human has confirmed move to the next step — the "confirmation gate" mentioned above is built into the structure. You get the flexibility that fixed rules alone can't capture, while avoiding the biggest risk of using an agent alone: "execution without verification."
Of course, ONTLE doesn't replace all automation. For fully structured, high-frequency repetitive work, no-code automation still wins on cost and predictability. Where ONTLE shines is the unstructured work that was hard to define as rules — where what needs checking changes every time — and that a person used to have to sit down and handle by hand each time.
No. If your current workflow reliably produces predictable results, there's no reason to switch. An agent is a tool that adds "work whose flow can't be mapped in advance" — the kind no-code struggled with — not a tool that rips out your existing automation.
There is one. What the human does shifts from "writing it all from scratch" to "reviewing a ready-made draft." Reviewing takes far less time than building from zero. It isn't fully unattended, but the amount of human work itself drops sharply.
Work that absolutely requires deterministic results. For jobs like accounting entries or inventory moves, where the same input must always produce the same result, even a slight deviation is dangerous. Such work belongs at Level 1 — rule-based automation.
If you want to hand repetitive work to rules and work whose flow can't be mapped in advance to a conversation, start with ONTLE. It's designed so a conversational AI agent interprets your request and produces the output, with a human doing the confirming.
https://ontle.kr
Author: Park Do-hyun