Somebody on your leadership team just asked you to "build an agent." Before you open Lindy, Agentforce, or a fresh n8n canvas, you owe yourself ninety seconds of taxonomy — because half the time, what they actually want is a Zap with better copy.

The Vocabulary Problem

It is May 2026, and the word agent has been stretched so thin that vendors now use it to describe a hardcoded if-then macro with a chat avatar. Salesforce calls a triggered Flow with an LLM prompt step an "Agentforce agent." HubSpot launched "Breeze Agents" that, on inspection, are pre-baked workflows with two GPT-4o calls bolted on. Even Microsoft's Copilot Studio markets "autonomous agents" that are, in the most common configuration, retrieval-augmented chatbots with a single tool binding. Meanwhile, the engineering teams at Anthropic, OpenAI, and the LangChain community use agent in a much narrower and much more dangerous sense — a program where a language model decides, at runtime, what to do next.

This vocabulary collapse matters because the wrong category produces the wrong build. If your CRO asks for "an agent that follows up on stalled deals" and you interpret that as agent-meaning-autonomous-loop, you will ship a system that occasionally invents email addresses, drafts apology notes to customers who never complained, and racks up a five-figure token bill. If you interpret the same request as workflow, you ship in a week, your finance team approves the budget on the first pass, and nothing wakes you up at 3 a.m. The Kiteworks enterprise survey published in March 2026 found that 41 to 44 percent of organizations are running what they call "agents" with no human-in-the-loop checkpoint. Most of those are misclassified workflows that have been allowed to drift into agent territory by mistake.

The category you choose at design time is the single biggest predictor of whether your project ships, survives audit, and stays within budget. Tools matter less than taxonomy.

Three Categories, Defined Properly

Strip away the marketing and there are exactly three patterns an operator-builder ships in 2026. Memorize them.

1. Workflow — predefined steps, model is one node among many

A workflow is a directed graph that you, the builder, have drawn. Every box is known in advance. The language model may appear inside one or two of those boxes — to classify a ticket, summarize an email, or extract fields from a PDF — but it never chooses the next step. The path is fixed at design time. Zapier Zaps are workflows. n8n flows are workflows. HubSpot Workflows, Salesforce Flow, Make scenarios, Airtable Automations — all workflows. The reason workflows dominate production is that they are predictable: you can map every branch, every error path, every cost.

Inside a workflow, a "GPT step" is a function call. You hand it inputs, you receive structured outputs, you continue. If the model hallucinates, the damage is contained to one cell of the spreadsheet. The model never reaches for a tool you didn't explicitly hand it.

2. Chatbot — turn-taking conversation, no tool autonomy

A chatbot is a UI for talking to a language model. It may be retrieval-augmented (it pulls from your Confluence, your Notion, your product docs), it may have memory of the current conversation, and it may even call one or two tools that you have whitelisted. But it does not act on the world without a human in the loop on every turn. The defining property is turn-taking: user speaks, bot speaks, user speaks. The user is the agent. The bot is the tool.

Intercom Fin, Drift, Glean's enterprise search, ChatGPT on a sales rep's laptop — all chatbots in the strict sense. When Fin "resolves" a ticket, it does so by composing a reply for the customer; it doesn't reach into Stripe to issue a refund unsupervised. The moment it does, it stops being a chatbot.

3. Agent — the model picks the next step

An agent is a loop. There is a goal. There is a set of tools the model can call. There is a model that, on each iteration, looks at the current state, decides which tool to invoke (or whether to stop), executes it, observes the result, and loops again. The path is not drawn in advance. The model draws it at runtime. This is the pattern that the February 2026 paper out of Stanford and DeepMind (arXiv:2602.00994) studies under the banner of tool-use restraint, and it is the pattern that produces both the magic and the catastrophes.

Lindy's autonomous mode is an agent. Devin is an agent. Claude Code is an agent. n8n's AI Agent node (the one whose tool-argument schema changed in February 2026, breaking everyone's flows) is an agent. The "Agentic Actions" beta in Clay is an agent. Crucially: just because a vendor sells you something called "Agentforce Agent" does not mean it is an agent in this strict sense. You have to inspect the runtime behavior.

The Litmus Test: One Question to Sort Any System

Forget the marketing. When you are looking at any AI feature, vendor pitch, or stakeholder request, ask one question:

At runtime, can the language model choose which step happens next?

If no — every step is drawn on a canvas and the model only fills in cells — it's a workflow. If the user is in the loop every turn — the system can only act when a human prompts it — it's a chatbot. If the model picks the next tool call from a menu, then loops, then picks again, then loops — congratulations, you are now responsible for an agent, and you owe your stakeholders honesty about what that means.

The three follow-up questions that tighten the diagnosis

1. What is the loop terminator? Workflows terminate when they hit the last node. Chatbots terminate when the user closes the window. Agents terminate when the model emits a "done" signal, when a max-iteration cap fires, or — disastrously — when they run out of budget.
2. Who is on the hook for the next action? If a human approves every outbound action, you have a workflow with an HITL gate or a chatbot with co-pilot semantics. If the system can fire-and-forget, you have an agent — and you have committed to building observability and kill-switches.
3. How many tool calls per run, and is that number bounded at design time? A workflow has a fixed number of tool calls (you drew them). A chatbot has zero-to-few per turn. An agent has an unknown number per run. If a vendor cannot answer this question, they are selling you an agent and pretending it's a workflow.

Why This Matters for Your Job

The reason your CRO, your VP of CS, or your head of ops keeps asking for "agents" is that agent is the hype word of 2026. Vapi raised at a $500M valuation in March on voice-agent buzz. Sierra is running TV ads. Every board deck has the word four times per slide. So when leadership says "we need agents," what they very often mean is we need a strategic story about AI. Your job, as the operator-builder, is to translate that story into the smallest pattern that solves the actual problem.

The smallest pattern is almost always a workflow. The second-smallest is a chatbot. The agent is the option of last resort, because the agent is the option that loops, and loops are where money and reputation burn.

Default to workflow. Promote to chatbot when the user needs conversational disambiguation. Promote to agent only when the path through the problem genuinely cannot be drawn in advance.

Scenario One: RFP Triage

A mid-market SaaS company receives 30 to 80 RFPs per quarter through a shared inbox. The sales-ops manager asks for "an agent that handles incoming RFPs." Let's run the decision tree.

What is the actual work? Read the inbound email, identify whether it's an RFP versus a generic inquiry, extract company name, industry, deal size hint, and deadline, score against an ICP fit rubric, log the result in HubSpot, and route either to a sales rep or to a "polite decline" template. That's the whole job.

Now ask the litmus question: can the path be drawn in advance? Yes, absolutely. Read email → classify → extract → score → route. Five steps, every time. There is no branch the LLM needs to invent. The LLM does the classification and extraction; everything else is deterministic.

Answer: this is a workflow. Build it in n8n or Zapier. The LLM appears in two nodes (classify, extract). Total cost per run: roughly $0.003. Time to ship: two days. Risk of runaway loop: zero, because there is no loop. The CRO is delighted because you delivered "the RFP agent" in a week. You are quietly delighted because you didn't ship an agent.

What an over-engineered version looks like

The over-engineered version is what a junior builder ships when they want to put "agentic AI" on their résumé. They wire up a Lindy agent, give it tools for Gmail, HubSpot, Slack, Salesforce, and Notion, and tell it to "handle RFPs." On the first real RFP, the agent reads the email, decides it needs more context, searches Notion, decides it should also check Salesforce for prior interactions with this company, decides it should draft three response options, decides it should ask the rep on Slack which one to send, gets no reply because the rep is on PTO, decides to retry, decides to re-search Salesforce, and burns 14,000 tokens before the human notices. Cost per run: $0.40. Time to ship: three weeks. Probability of incident in the first month: high.

Scenario Two: Lead Routing

The VP of RevOps wants to "use AI agents to route inbound leads to the right rep based on territory, segment, and rep capacity." Let's run the tree.

What is the work? When a form fills, look up the company in Clearbit or Apollo, enrich, check the rep territory matrix, check capacity (number of open opps per rep), and assign in Salesforce. There is also a wrinkle: occasionally the rep matrix doesn't have a clean answer (a multi-region account, a segment-edge company), and a human RevOps person needs to decide.

Can the path be drawn in advance? Mostly yes — but with a branch where the system says "I'm not sure, ask a human." That's still a workflow. The "ask a human" step is just another node. The model doesn't need to pick the next tool; you already know which tools it has to call.

Answer: workflow with HITL escalation. Build it in Salesforce Flow or n8n. Use an LLM step only for the "is this an edge case?" classifier, and route edge cases to a #revops-review Slack channel. Time to ship: one week. Cost: trivial. Failure mode: a rep occasionally complains they got a lead that wasn't theirs — handled by your normal RevOps ticket queue, not by a 3 a.m. PagerDuty alert.

When this same scenario becomes an agent

If the VP says "and also, when a lead is interesting but cold, I want the system to research them, draft a personalized outbound, and decide whether to send it on its own" — now you are in agent territory. The model has to choose: do I research more? do I draft? do I send? do I wait? That's a loop with an open action space. That's an agent. And now you must do the agent-grade work: define the tool surface, define the budget cap, define the observability, define the kill switch.

Scenario Three: Support Deflection

The head of CS wants to "deflect 40 percent of tickets with an AI agent before they hit a human." This is the classic case where the request is properly named — this should be a chatbot, and only sometimes an agent.

What is the work? A customer asks a question in chat or email. The system needs to understand the question, retrieve relevant docs, compose a helpful answer, and — for a narrow set of self-service operations like "reset my password" or "extend my trial by 7 days" — actually execute the operation. Otherwise, escalate to a human.

Can the path be drawn? For the answer-from-docs case: yes, that's a retrieval-augmented chatbot. For the "execute self-service operations" case: the bot has to decide which of a small whitelist of tools to call, based on the customer's request. That decision is the agent-y part.

Answer: chatbot for the deflection itself, with a tightly scoped agent capability for self-service. The agent capability is bounded: a whitelist of three to six tools, a max of one tool call per turn, no recursion, and every tool action is logged. This is what Intercom Fin actually does under the hood, and why it works without exploding.

The biggest mistake here is letting "support agent" mean "the bot can do anything CS can do." It can't, and it shouldn't. You whitelist three operations, log everything, and escalate the rest.

The Decision Tree, One Page

Print this. Tape it to your monitor. When the next "we need an agent" request lands, run it top to bottom.

1. Can I draw every step in advance, on a whiteboard, before any code runs?
   • Yes → Workflow. Ship in Zapier, n8n, Make, Salesforce Flow, HubSpot Workflows. Use LLM steps for classify/extract/summarize only.
   • No → continue.
2. Is a human in the loop on every action the system takes?
   • Yes → Chatbot. Ship in Intercom, Glean, a Slack bot, or a Claude-in-the-browser pattern. RAG is fine; tool calls are co-pilot, not autonomous.
   • No → continue.
3. Will the language model, at runtime, choose which tool to call next from a menu, possibly more than once per run?
   • Yes → Agent. You have signed up for the full work: tool-surface scoping, max-iteration caps, token caps, wall-clock caps, observability, kill switches, audit logs, and the EU AI Act Article 26 paperwork if you ship to the EU.
   • No → reread the question, because you are probably still in workflow land.

Translating vendor language

Here is the translation table you keep in your head when a vendor uses the word "agent":

• "Agentic AI for sales" in a SaaS marketing deck → usually means a workflow with an LLM step.
• "Autonomous agent" in a Copilot Studio brochure → usually a workflow with one model-driven branch.
• "Agent" in Agentforce, Breeze, Joule → varies by config; could be any of the three. Inspect the runtime.
• "Agent" in Lindy, Crew, AutoGen, n8n AI Agent node, LangGraph → genuinely a loop. Treat as agent.
• "Agent" in Devin, Claude Code, OpenAI Codex CLI → genuinely an agent with a very wide tool surface. Treat as high-risk.

The Cost of Misclassification

In November 2025, a SaaS company whose name later leaked on Hacker News deployed two LangChain agents that were supposed to "monitor competitor pricing and update internal benchmarks." The product manager who built them assumed they were workflows. They were not — each agent had access to a web-search tool, a writeback-to-Airtable tool, and a "ping the other agent" Slack tool. The two agents began pinging each other for clarifications, each clarification triggered a new web search, each web search produced a new ambiguity, and the loop ran for eleven days before someone noticed. The OpenAI bill was $47,000. The Airtable was a forest of duplicate rows. Nobody got fired, but the postmortem made it clear: the team thought they were shipping a workflow, and the architecture they actually shipped was an agent with no caps.

That is the canonical 2026 misclassification story. Every operator-builder should know it the way a pilot knows the Tenerife runway incident. The category you choose at design time is the safety boundary. Once a system is loose in agent territory, every other safeguard you build is a patch on a leak you could have prevented by not drilling the hole.

When You Should Actually Build an Agent

Agents are not bad. Agents are right for problems where the path genuinely cannot be drawn. The honest list of "you need an agent" use cases in mid-2026 is short:

• Open-ended research: "find me the top 20 companies in vertical X with these properties." The model has to search, read, refine, search again.
• Code generation with verification loops: Claude Code, Devin, Cursor's agent mode. Write code, run tests, read errors, fix, repeat.
• Investigation and triage where the next step depends on what was found: security incident triage, log analysis, "why is this metric off."
• Multi-system data reconciliation where the question is "which system is wrong": compare A, compare B, compare C, decide which one to trust.
• Long-horizon planning with iterative refinement: drafting an annual plan that requires reading prior plans, surveying stakeholders, and revising.

Notice what is not on this list: any task where the steps are knowable. RFP triage is knowable. Lead routing is knowable. Email summarization is knowable. PDF extraction is knowable. None of those are agents in 2026, no matter what the vendor calls them.

Key Takeaways

• Three categories, one litmus test. Workflow: you drew the steps. Chatbot: the user is in the loop every turn. Agent: the model picks the next step at runtime.
• Default to workflow. Promote to chatbot only when conversational disambiguation is required. Promote to agent only when the path genuinely cannot be drawn at design time.
• Translate vendor language. Most things sold as "agents" in 2026 are workflows. Inspect the runtime, not the brochure.
• Misclassification is the root cause. The $47K LangChain incident, the 41-44% no-HITL agents from the Kiteworks survey — these are workflows that drifted into agent territory because nobody named the category at design time.
• Agents are right for unknowable paths. Research, code with verification, investigation, reconciliation, long-horizon planning. Not RFP triage. Not lead routing. Not "summarize and send."
• The decision tree is one page. Tape it up. Run every stakeholder request through it before you open a single builder canvas.