AI Agents vs Agentic AI: A Builder's Definition

An AI agent is a program: a model, a set of instructions and a set of tools, run in a loop where the model decides what to do next until the task is done. Agentic AI is not a second product. It is a property of a whole system, the degree to which model decisions rather than predefined code control what happens, when it happens and across how many parts. A system can contain an "agent" and be barely agentic, and a plain pipeline with one model decision in it can be more agentic than its vendor admits.

This is a builder's definition rather than an analyst's. It should let you read a vendor page and work out, in a few minutes, which decisions the model actually makes.

The one question that separates them

Every definition reduces to a single question: who chooses the next step?

• If code chooses, you have a workflow. The model may sit inside a step, classifying, extracting or drafting, but the route through the steps is fixed.
• If the model chooses, within bounds you set, you have an agent.
• If the model also chooses which other agents to involve, when to start and when to stop, you have what vendors call an agentic system.

The three vendors most people quote agree on this. Anthropic's "Building effective agents" post draws exactly this line: workflows are "systems where LLMs and tools are orchestrated through predefined code paths", and agents are "systems where LLMs dynamically direct their own processes and tool usage" (Anthropic, December 2024). It groups both under one umbrella, "agentic systems": agentic is the category and agent is one shape inside it.

Microsoft's architecture guidance describes a sequential pipeline of agents and then states the quiet part: "The choice of which agent gets invoked next is deterministically defined as part of the workflow and isn't a choice given to agents in the process" (Microsoft Learn, AI agent orchestration patterns). That is a workflow built from agents, and it is less agentic than one agent choosing its own tools.

Google's Agent Development Kit defines an agent as "a self-contained execution unit designed to act autonomously to achieve specific goals", built from "an artificial intelligence (AI) model, task instructions, and optionally, a set of tools", and describes the job of its workflow layer as letting you "interweave the non-deterministic functionality of AI models with deterministic code" (Google ADK documentation). The same line, drawn by a third vendor.

So the honest short version: an AI agent is the unit. Agentic describes how much of the system's control flow you have handed to models. The second is a dial, not a product.

What the vendors actually write

Vendor	Term	Definition on the vendor's page	Where the model decides
Anthropic	Agent	"an application that completes a task by planning its own steps and calling tools" (Agent SDK overview)	The plan and the tool calls
Anthropic	Agentic system	The umbrella for both workflows and agents; workflows run on "predefined code paths" (Building effective agents)	Depends on which shape you built
Microsoft	Prompt agent	"instructions, a model, and tools", run by the platform (Foundry Agent Service overview)	Tool choice within one conversation
Microsoft	Custom engine agent	Adds "autonomy and proactive agentic support to programmatically initiate workflows and actions" (Microsoft 365 Copilot agents overview)	Tool choice, plus when to start
Google	Agent	"a self-contained execution unit designed to act autonomously to achieve specific goals" (ADK agents)	The steps toward a goal
Google	Workflow	"any agent application that has more than one agent or executable Node" (ADK agents)	Inside each agent; graph and template workflows are code, collaborative workflows use a coordinator agent (ADK workflows)

Source: the vendor pages linked in each row, read in October 2026.

Microsoft's own comparison table marks declarative agents as "Not supported; rely on user-initiated interactions" for proactive behaviour, while custom engine agents can "trigger actions automatically, even without direct user input" (Microsoft 365 Copilot agents overview). Within one vendor, the same word covers a thing that waits to be asked and a thing that can act without a user. That gap is the practical difference between an agent and agentic AI, and it is an architecture choice (whose orchestrator runs the agent, and whether it may start without a user), not a different kind of AI.

The agency dial: five positions

Place a system on this dial before reading anything else about it.

Position	Who chooses the next step	Who chooses when it runs	What vendors call it	What to add before production
1. Single call	Nobody; one prompt, one answer	A user or your code	"AI feature", "assistant"	Output validation
2. Workflow with model steps	Code	Your code or a schedule	"Pipeline", "prompt chaining", "sequential orchestration"	Per-step validation, retries
3. Single agent with tools	The model, from a fixed tool list	A user	"Agent", "prompt agent", "LLM agent"	Tool allowlist, iteration limit, audit log
4. Triggered agent	The model	An event or a schedule, not a person	"Autonomous agent", "proactive agent"	Everything in 3, plus approval gates on writes and a kill switch
5. Multi-agent system	A model, choosing among agents	Events, schedules or other agents	"Agentic AI", "orchestration", "handoff", "magentic"	Everything in 4, per agent, plus loop limits between agents

Microsoft's architecture centre collapses this to three levels, direct model call, single agent with tools and multiagent orchestration, and its advice is blunt: "If prompt engineering can solve the problem, you don't need an agent", and the single agent with tools is "Often the right default for enterprise use cases" (Microsoft Learn). Anthropic writes the same from the other direction: find "the simplest solution possible", which "might mean not building agentic systems at all" (Anthropic).

This dial splits Microsoft's middle level into positions 3 and 4 because the trigger changes everything. An agent a person invokes has a human reading its output in real time. An agent that wakes when an invoice becomes overdue, or when a new order arrives, has nobody watching. Same code, same model, same tool list, and a completely different risk. "Agentic" in a vendor deck almost always means position 4 or 5, and few businesses need anything past position 4.

Why the position matters more than the label

Each notch up the dial buys capability and charges for it in three currencies.

Cost. A single call is paid once. An agent that loops is paid once per turn, and a task it fails twice is paid for three times. A multi-agent system multiplies that by the agent count and adds the orchestrator's own turns. Anthropic's phrase is that agentic systems "often trade latency and cost for better task performance" (Anthropic); Microsoft's is that multiagent orchestration "Adds coordination overhead, latency, and failure modes" (Microsoft Learn).

Error behaviour. A deterministic workflow fails at a known step with a known input. An agent fails somewhere inside a path it chose, and Anthropic names the consequence: "the potential for compounding errors". By position 5 a wrong early decision has been handed to other agents as fact.

Debuggability. At position 2 a failed run is a stack trace. At position 3 it is a transcript. At position 5 it is several transcripts that disagree, and "why did it do that" has to be reconstructed from a ledger that must already exist.

None of these costs attach to the word on the pricing page; they attach to the position. An "agentic AI" product that is in fact a position-2 pipeline with a chat front end is overpriced but safe. An "assistant" that quietly runs position-4 triggers against your ERP is cheap and dangerous. Read the position, not the noun.

How to classify a system

Run this checklist on any agent, bought or built, before forming an opinion.

1. List every decision the model makes. Which tool, which record, what to write, whether to stop, whom to notify. No list, no known position, no known risk.
2. Mark each decision as bounded or open. Bounded: chosen from a fixed list your code defined. Open: free text that becomes an action. An open decision that writes to a system of record is the finding.
3. Find the trigger. Does a person start every run, or can an event or a schedule? This alone separates position 3 from position 4.
4. Find the stop. What ends the loop: a result, a turn limit, a budget, or nothing? Microsoft's guidance for the single-agent level is "To guard against infinite tool-call loops, set iteration limits" (Microsoft Learn); a product without one is unfinished.
5. Find the writes. Which actions change data someone else relies on: invoices, stock, payments, emails sent? Each needs a gate whose answer can be "no".
6. Find the approver. For every write, who sees it before it happens, and is that visible in a log afterwards? If the answer is "the autonomy setting", you have a global switch where you needed a per-action one.
7. Count the agents, last. Only now does multi-agent matter, and the question is whether the agents have distinct permissions or merely distinct prompts. Prompts are not a security boundary.

People start with step 7 because it is what the demo shows. Steps 2, 3 and 5 are where the money is.

Where the labels go wrong, and how to spot it

• A workflow sold as an agent. The route is fixed, the model fills in text at each step, and the price assumes an autonomy you are not getting. Spot it: ask what happens when the input does not fit the happy path. A workflow errors; an agent tries something.
• An agent sold as a workflow. The reverse, and more dangerous: a "smart assistant" whose configuration lets it call write actions on its own. Spot it: read the tool list and the trigger settings, not the product name.
• Multi-agent before single-agent. The diagram is impressive; the handoffs are the hard part. Microsoft's handoff guidance names the failure directly: "Avoiding an infinite handoff loop or avoiding excessive bouncing between agents is challenging" (Microsoft Learn). Spot it: ask whether one agent with a good tool list was tried first and why it was not enough.
• Agency without a ledger. The system acts, and nobody can say afterwards what it read, proposed and did. Spot it: ask for yesterday's log, per action, with the approver named.
• Prompts as permissions. "The agent is instructed not to issue refunds" is not a control; a tool allowlist that contains no refund tool is. Spot it: ask whether a restriction lives in the prompt or in the code.
• The dial creeping after launch. A position-3 agent gains a schedule to "save time" and becomes position 4 without a review. Spot it: version the trigger and tool configuration like code, and diff it monthly.

Which position to build or buy

Decision criteria, in order:

• If a prompt and a validator solve it, stop at position 1 or 2. Classification, extraction, summaries, drafts. Most "agent" requests in a business are these, and a deterministic pipeline is cheaper to run, test and explain to an auditor.
• Move to position 3 when the number of steps is genuinely unknown. Anthropic's test is "open-ended problems where it's difficult or impossible to predict the required number of steps" (Anthropic). Investigating an order discrepancy qualifies; posting a journal entry does not.
• Move to position 4 only when someone owns the exception queue. A triggered agent produces work that is right most of the time and wrong sometimes, with nobody watching. If no person is assigned to the exceptions, the trigger is a liability.
• Move to position 5 for boundaries, not for elegance. Microsoft names three cases for multi-agent: "cross-functional or cross-domain problems, scenarios that require distinct security boundaries for each agent, and tasks that benefit from parallel specialization" (Microsoft Learn). Of the three, boundaries is the one that justifies the cost, and that is this post's view rather than Microsoft's: different data access, different approvers, different blast radius. If every agent would hold the same permissions, you wanted a better tool list.
• Never let a critical write cross any position automatically. Posting money, registering a payment, approving a purchase, sending to a customer. These get a human at every position on the dial, and the vendor's autonomy slider does not change that.

If you want help placing your own use case on the dial, and designing the tools, gates and ledger it needs at that position, that is the shape of my AI integration engagement: an assessment of where a model should and should not be deciding, the architecture, and a working prototype connected to your systems.

For the related question of which layers of that stack to build yourself and which to buy, Custom AI agents: what to build and what to buy goes layer by layer.

Frequently Asked Questions

Is agentic AI just another name for AI agents?

No, but they are closer than the marketing implies. An AI agent is the unit: a model, instructions and tools running a loop. Agentic describes how much of a system's control flow is decided by models rather than code, including whether it starts on its own and whether it coordinates other agents.

Is a chatbot an AI agent?

Only if it can call tools and decide which to call. A chatbot that answers from a knowledge base with no actions is a single call with memory, position 1 on the dial. The moment it can look up an order, open a ticket or send an email of its own choosing, it is an agent and needs an agent's controls.

Does a workflow with an LLM step count as agentic AI?

By the vendors' own definitions, no. Anthropic calls that a workflow, "orchestrated through predefined code paths", and Microsoft's sequential pattern states the next step "isn't a choice given to agents". It is often the right design: cheaper, testable and explainable. Buy it as what it is, not at an agent's price.

Do I need multi-agent agentic AI to get value from AI?

Rarely at first. Microsoft's guidance calls a single agent with tools "Often the right default for enterprise use cases", and Anthropic recommends "the simplest solution possible". For most businesses the value sits at positions 2 and 3. Move up only when a single agent provably cannot do the job, or when different parts of the task need different permissions.

How do I tell what a vendor's "agentic" product really does?

Ask for three things: the list of decisions the model makes and whether each is bounded; the trigger model, user-initiated or event-driven; and yesterday's action log with approvers. The answers place it on the dial. A vendor who cannot produce them is selling a label.