One Word, Three Jobs: What "Agent" Means at Lunch and in Production

A junior data scientist posted online last week, asking a question that anyone who has tried to learn agentic AI from scratch eventually asks. He had spent a lunch with people in non-technical jobs who threw around "just make an AI agent that does this" the way an earlier generation threw around "just spin up a server." He had then started a course and felt overwhelmed: LLMs, APIs, structured outputs, agent memory, multi-agent systems, MCP. His own work in data science used deterministic pipelines, which he suspected covered most cases. The question he posted was honest: am I making it too complicated?

The thread that followed split, predictably, into two camps. One camp said the gap between "I'll build an agent for X" and "my agent reliably does X in production" is massive, and that non-tech folks tossing the word around have no idea what they are buying into. The other camp said he was overthinking it, that low-code tools cover most personal automation, and that he should pick one annoying task and ship it. Both camps argued past each other with equal conviction. Both camps were right.

The reason both camps were right is that the word agent is doing three different jobs in this conversation, and the disagreement only resolves once the jobs are named. This article names them, attaches numbers to each, and proposes that the choice of which job a system is doing should precede every other architectural decision. The framework collapses to one sentence: pick the category before you pick the architecture.

The three jobs

flowchart LR
    subgraph C1[Category 1: bounded LLM-in-a-workflow]
        I1([Input]) --> S1[LLM step] --> O1([Output])
    end
    subgraph C2[Category 2: autonomous loop, low stakes]
        I2([Input]) --> L2{LLM decides} -->|tool| T2[Read tool] --> L2
        L2 -->|done| O2([Output])
    end
    subgraph C3[Category 3: autonomous loop, production side effects]
        I3([Input]) --> L3{LLM decides} -->|write| T3[Write tool] --> L3
        L3 -->|done| O3([Effect on real system])
    end

Each category looks superficially similar. The model is the same. The SDK is often the same. The marketing slide is identical. The operational realities are not.

Category 1: bounded LLM-in-a-workflow

The first kind of agent is a workflow with a single LLM call (or a small fixed number of them) wrapped inside an automation tool. n8n's "AI Agent node," Zapier's GPT actions, custom GPTs, Claude Cowork, a Make.com scenario with an OpenAI step. The LLM is a component, not a controller; the surrounding workflow decides what runs when. n8n's own documentation draws this distinction explicitly, calling out that "n8n agents operate within a defined workflow, with clear inputs, outputs, and boundaries you set" (n8n, 2025).

This is what most non-technical enthusiasts mean when they say "AI agent." It is genuinely accessible. It works. It maps to Anthropic's own recommendation that "the simplest solution possible" should be the default and that complexity should only be added when needed (Anthropic, 2024). The lunch-table claim that this is easy is correct. The cost is bounded by the number of LLM calls in the pipeline. The reliability is bounded by the model's reliability on a single well-scoped prompt, which is high.

If the OP's goal is "automate things from my daily life tasks," this is the category that does the work for him. It is not the category any of the engineering responses in the thread were warning him about.

Category 2: autonomous loop on a low-stakes task

The second kind of agent is the one the academic literature has been calling an agent for several years: a model in a tool-calling loop, where the model decides at each turn whether to call a tool, respond, or stop. ReAct, plan-and-execute, the OpenAI Agents SDK's default loop, LangGraph's create_react_agent prebuilt. The control returns to the model after every observation. The shape of the computation is emergent rather than authored.

The "low-stakes" qualifier matters. Here the agent is reading, summarizing, classifying, drafting, researching, exploring; its tool calls are mostly read-only or sandboxed. A research assistant that searches the web and summarizes findings. A code-review bot that reads a diff and posts comments. A summarization agent over a PDF.

The reliability ceiling for this category is now measurable. METR's task-completion time horizon benchmark tracks the duration of a task at which a frontier agent succeeds with 50% reliability. As of December 2025, Claude Opus 4.5 leads the benchmark at roughly 4 hours 49 minutes; the doubling time across the last six years is approximately seven months (METR, 2025). Translated: on tasks that take a human expert a couple of hours, the best autonomous agent in the world fails roughly half the time. On 4-hour tasks it fails half the time. The gap between agent and human is closing fast, but the current state of category 2 is "useful when spot-checked, dangerous when trusted."

This is the category the engineering responses in the Reddit thread were correctly skeptical about. It is also the category that improves the fastest with each model release.

Category 3: autonomous loop with production side effects

The third kind of agent is category 2 with the safeties off. Same loop. Same model. But the tool calls now include actions that touch real systems: deploying to production, writing to a database, sending customer messages, executing payments, modifying schemas. The reliability requirement does not just rise; it changes shape, because the cost of an error is no longer "wrong answer" but "wrong action."

This is where the hard numbers live. Anthropic's own engineering retrospective on their multi-agent research system reports that single-agent loops use roughly 4x the tokens of plain chat interactions and multi-agent systems use roughly 15x. Token consumption alone explains 80% of the variance in agent performance (Anthropic, 2025). The Google/DeepMind/MIT scaling study from late 2025 found that on sequential reasoning tasks, every multi-agent variant they tested degraded performance by 39 to 70 percent compared to a single-agent baseline (Han et al., 2025). Multi-agent helps on parallelizable, decomposable work and hurts on sequential planning, by a margin large enough that the choice is no longer aesthetic.

Add a second compounding factor: the model under the agent is not stable across time. OpenAI's own documentation states plainly that "model prompting behavior between snapshots is subject to change, and model outputs are by their nature variable, so expect changes in prompting and model behavior between snapshots" (OpenAI, 2025). The Stanford and Berkeley study of GPT-4 behavior over time documented this empirically: GPT-4's accuracy on prime-vs-composite identification dropped from 84% in March 2023 to 51% in June 2023 on the same prompts (Chen, Zaharia, Zou, 2023). An agent verified against a benchmark in March can fail the same benchmark in June without any code change.

Add a third factor: subscription limits are tightening as compute supply lags demand. By early 2026 The Register was reporting widespread complaints from Claude Pro and Max subscribers about restrictive rolling usage windows (The Register, 2026), with Anthropic's CEO publicly describing the company as compute-constrained and the supply gap not closing for 12-24 months. Building on rented intelligence means the per-task cost trajectory is not yours to control.

Category 3 is the category that the production engineers in the thread were warning about. It is also the category that is most often confused with categories 1 and 2 because the marketing layer flattens them all.

What gets confused, and what it costs

The expensive failure mode is not building any one of the three categories. It is building one category while expecting another. The four observable patterns:

Built	Expected	What happens
Category 1	Category 1	Works as advertised. The non-tech enthusiast was right.
Category 1	Category 2 or 3	The system underperforms the buyer's mental model. They blame the technology.
Category 2	Category 1	The team pays 4x in tokens for variability they did not need. They blame the budget.
Category 2 or 3	Category 3	The team trusts an autonomous loop with side effects it cannot reliably handle. They get an incident.

The Reddit OP's instinct that "a deterministic pipeline does the work in most cases" is the category-1 instinct, applied to a personal-automation use case. The instinct is correct. The non-tech folks at lunch saying "just make an AI agent" are also describing category-1 work, and they are also correct. The engineering pushback in the thread was, accurately, warning against category-3 risk that was implied but never named. Everyone was right about a different category, and the conversation did not resolve because nobody named which.

The category-first test

A small set of questions resolves the category before any code is written.

Does the system take any action that cannot be undone within a minute? If yes, you are in category 3 territory and you need approval gates, audit trails, and human-in-the-loop on the irreversible actions. If no, you are in category 1 or 2 and you can ship more freely.

Does the system need to choose its next step at runtime, or does the path through it decompose into a fixed pipeline? If the path is fixed, you are in category 1; build the workflow and use the LLM as a component. If the next step depends on what the previous step found, you are in category 2 or 3 and you need a tool-calling loop.

Are you willing to spot-check every output before acting on it? If yes, you can run category 2 productively today. If no, you need either category 1's predictability or category 3's full HITL machinery; running category 2 unsupervised on a task you cannot afford to spot-check is the configuration that produces the incidents the engineering thread warned about.

These three questions cover most architectural decisions the Reddit OP would face for the next year. They also collapse the apparent disagreement at the lunch table into a definitional one. The OP's coworkers were right that category 1 is easy. The engineers in the thread were right that category 3 is hard. Both were right that the OP should start with one annoying task and automate it. The remaining question is not whether to use an agent. It is which kind to build first.

Where the categories blur

The three categories are useful, not crisp. Two honest blurs deserve naming.

The first blur is between categories 2 and 3. A research agent that "only" writes to a notes file is technically read-only, but the notes file may feed a published report; the side effect is real, just laundered. The right test is the downstream irreversibility, not the immediate tool call. A bias toward treating fuzzy cases as category 3 errs in the safe direction.

The second blur is between categories 1 and 2 on tools like n8n with an LLM-augmented agent node. The node can be configured to operate within bounded reasoning (workflow-shaped) or to chain multiple tool calls dynamically (autonomous-shaped). The same product surface hosts both modes; the operational implications are different. The category is set by how the node is configured, not by the product's name.

These blurs are not flaws in the framework. They are the reason the framework helps: the act of asking which category you are in, and recognizing that you cannot answer cleanly, is the signal that the architecture choice is not yet settled.

Neighbors in the series

The Agentic Patterns series, which closed two weeks ago with a decision-framework capstone, takes a position on each of the three categories without naming them. "Workflows Versus Agents in LLM Systems" (the first article) is the case for category 1 as the default. "The Tool-Calling Agent Loop" and "ReAct" are the canonical category-2 patterns. "Human-in-the-Loop Patterns for LLM Agents" and "Guardrails for LLM Agentic Systems" are the disciplines that make category 3 survivable. "Scaling and Cost Optimization" provides the empirical numbers that distinguish category 3's bill from category 1's. The category framework in this article is not new technology; it is a different language for the same architectural choices the series already covered.

References

1. Anthropic. Building Effective Agents. December 2024.
2. Anthropic. How we built our multi-agent research system. June 2025.
3. n8n. Agents vs chains documentation. 2025.
4. METR. Task-Completion Time Horizons of Frontier AI Models. Updated through December 2025.
5. Han, Joshua, et al. Towards a Science of Scaling Agent Systems. Google, DeepMind, MIT, December 2025.
6. Chen, Lingjiao, Matei Zaharia, and James Zou. How is ChatGPT's behavior changing over time? arXiv:2307.09009, 2023.
7. OpenAI. Model Release Notes. 2025.
8. The Register. Claude devs complain about surprise usage limits. January 2026.