TL;DR
- An automation follows a predefined path.
- An AI agent uses a model to decide what to do next at runtime, including which tools to use, how to respond to results, and when to stop or ask for help.
- Both can use AI, memory, retrieval, and tools, so those capabilities alone do not make a system an agent.
- The key difference is who controls the execution path: the workflow or the model.
Have you ever had a client ask for an "AI agent", only to describe a process that is really just a form submission, a CRM update, and a notification?
The terminology can make a straightforward workflow sound more complicated than it is, and if you are building or buying the system, that can make the architecture harder to reason about.
The useful distinction is not whether the system contains AI, memory, retrieval, or tools. It is who controls what happens next at runtime.
What is the difference between an AI agent and an automation?
An automation follows an execution path that was chosen in advance. An AI agent uses a model to control some part of execution at runtime, deciding what to do next, which allowed tools to use, or whether it needs another step before it can complete the goal.
Say you want a new form submission to create a CRM record and send a Slack notification. Your workflow can have those steps wired in advance, including every field and connection, so the same path runs whenever the trigger fires. That is an automation, even if an LLM classifies the submission somewhere in the middle.
Now say you can type, "Reschedule my 3 p.m. meeting and tell the other attendees." The system needs to interpret the request, inspect the calendar, work out which available action applies, and decide what to do next. If the model controls that part of the path, you have an agent-controlled system.
In short, the boundary is model control over execution, not whether the system accepts natural language or calls an API.
Can an automation use AI without becoming an agent?
Yes. An automation can use an LLM for a bounded task while keeping the overall execution path fixed.
Let's take an example, and see how this works. Your intake workflow receives a form, sends the message to a model to classify the request, and then routes the result through predefined validation, CRM, and notification steps. The model makes a judgment about the content, but it does not decide what the workflow does after that judgment.
The same distinction applies if your scheduled process asks a model to summarize a known document and then saves that summary to a fixed location. The model is doing useful work, but the surrounding software still determines the path.
This matters because "AI-powered" and "agent-controlled" describe different things. An LLM can classify, extract, draft, or evaluate inside a predictable workflow. You only have a stronger signal of agency when the model is deciding the next action or tool at runtime.
What capabilities can an automation or an AI agent have?
Memory, retrieval, tool use, and model judgment can all appear in either architecture. None of them, on its own, proves that a system is an agent.
| Capability | What it means | Automation | Agent | Does it prove agency? |
|---|---|---|---|---|
| Memory | Prior state persists across runs or sessions | Yes | Yes | No |
| Retrieval | The system searches private or external information | Yes | Yes | No |
| Tool use | The system calls an API, function, browser, or database | Yes | Yes | No |
| Model judgment | An LLM classifies, extracts, drafts, or evaluates | Yes | Yes | No |
| Model-controlled routing | The model chooses the next step or tool | Sometimes | Usually | Strong signal |
| Iterative autonomy | The model observes results and revises its plan | Rare | Usually | Strong signal |
| Human approval | A person authorizes selected actions | Yes | Yes | No |
RAG, or retrieval-augmented generation, belongs in this same capability view. RAG lets a system retrieve relevant information before a model generates an answer, which can be useful for private documents, databases, or other business knowledge. It is the core of most LLM and RAG development work. It does not create a universal "higher" type of agent.
The same is true of function calling. Giving a model access to Gmail, a calendar, or a database means it can use those tools, but a predefined workflow can call tools too. What matters is whether the model controls part of the execution path.
How does an AI agent control a task?
An agent-controlled task usually involves a loop in which the model interprets a goal, acts through allowed tools, observes the result, and adjusts what it does next.
Say you ask your system to "reschedule my 3 p.m. meeting and tell the other attendees." It might first interpret the request and its constraints, then inspect your calendar, then choose a valid alternative. Depending on your permissions, it could ask for approval before changing the event and sending a message, then observe whether those actions succeeded and recover if something failed.
That does not mean the agent has unlimited freedom. Your application still defines which tools exist, what permissions they have, which actions require approval, and when the system must stop or ask for help. That surrounding software is what we call the harness, and it matters as much as the model.
This detail, in my opinion, is what makes agent architecture easier to explain to a client: the model is not replacing the application's rules. It is being given controlled responsibility for deciding what happens within those rules.
Can a system be both an automation and an AI agent?
Yes. A production system can contain a model-controlled component inside a larger deterministic workflow.
Let's take the same kind of intake process. Your fixed workflow can receive a form, validate it, create the CRM record, and notify the internal team. For unusual requests, an agent-controlled step can inspect the submission, gather missing information with allowed tools, and draft a personalized follow-up. The fixed workflow can then resume for approval, sending, and logging.
That architecture gives you a useful separation between predictable operations and tasks where the route genuinely depends on what the model finds at runtime. Calling an LLM inside one step does not automatically make the entire workflow an agent.
This hybrid shape also means you do not have to choose one architecture for every part of a system. The question is which parts need predefined execution and which parts need runtime decision-making. We argue for starting with the predictable path in use AI to build the system, not necessarily to run it.
What tradeoffs distinguish agents from predefined workflows?
The architectural difference changes how you build, test, and operate the system, but neither pattern is universally applicable.
| Dimension | Predefined workflow | Agent-controlled execution |
|---|---|---|
| Path | Chosen in code before the run | Chosen partly by the model during the run |
| Flexibility | Best for anticipated cases | Better for variable paths and goals |
| Testing | Step and branch coverage | Scenario, tool, policy, and outcome evaluation |
| Cost and latency | Easier to bound | Can vary with iterations and tool use |
| Failure analysis | Trace known steps | Inspect decisions, tool calls, and state |
| Human control | Added at known checkpoints | Designed around action risk and approvals |
A predefined workflow gives you a path that is easier to inspect before execution. An agent gives the system more room to respond to variable requests, but that flexibility means you need to evaluate not only whether individual steps work, but whether the model chooses appropriate actions and stops under the right conditions.
The practical distinction is therefore architectural rather than promotional: you are choosing how much runtime control to give the model, and that choice affects testing, cost, latency, failure analysis, and human oversight.
What else do people ask about AI agents and automations?
Is an AI agent just an automation that uses AI?
Not necessarily. An automation can use an LLM for classification, extraction, drafting, or evaluation while following a path defined in advance. An agent is distinguished by giving the model some control over what happens next at runtime.
Does function calling make a chatbot an agent?
No. Function calling gives a model access to tools, but a predefined workflow can also call functions or APIs. Function calling becomes relevant to agency when the model can choose which available tool or action to use as part of pursuing a goal.
Is RAG the same as an AI agent?
No. RAG is a retrieval capability that supplies relevant information to a model before it generates an answer. It can be used inside an automation, assistant, or agent, so retrieval by itself does not establish agency.
Can an automation make decisions?
Yes. A workflow can contain rules, conditions, branches, and even model-based judgments. The key question is whether those decisions were defined in advance or whether the model is controlling part of the execution path at runtime.
Can an AI agent follow a fixed workflow?
Yes. An agent can operate within a constrained application that defines its tools, permissions, approval points, and stopping conditions. It can also be placed inside a larger fixed workflow, with deterministic steps before and after the model-controlled component.
Can you build an agent in Make or n8n?
Yes. A workflow platform can provide models, tools, memory, retrieval, and predefined steps, while an agent component can use those tools to make runtime decisions. The platform itself does not determine whether a build is an agent, because the relevant question is how execution is controlled.