What are AI agents? A definition that survives contact with production

Ask five vendors what an AI agent is and you will get five answers. Four of them describe whatever that vendor sells.

Gartner has a name for this: agent washing. Chatbots, RPA bots and assistants get rebranded as agents, and of the thousands of vendors claiming agentic products, Gartner estimates only about 130 offer real agentic capabilities. The word now covers almost anything with an LLM call inside it.

The naming matters because the definition you adopt decides what you budget, how you govern, and what you are accountable for when the thing acts.

Call a chatbot an agent and you buy governance you don’t need. Call an agent a chatbot and you ship something that can issue refunds without anyone having signed off on that power. I see both mistakes regularly. The second one is worse.

The definition I use when scoping a project

Start with an uncomfortable fact: AI agents have no standard definition. The academic version is broad. Anything that perceives its environment and acts on it to reach a goal counts. The marketing version is broader still.

So this is the one I use:

An AI agent is a goal-directed software system that perceives context, reasons over it with a model, and takes actions through tools, at a level of autonomy you choose.

Every clause is there for a reason.

Goal-directed means you hand it an outcome, “resolve this ticket”, and it works out the steps. Perceives context means it reads the current state of the world (the conversation, the CRM record, the API response) rather than a prompt alone.

Reasons with a model means an LLM decides what to do next at runtime. If a developer made every decision in advance, you have automation. Automation is fine, but it is not an agent.

Acts through tools means it can change something: update a record, call an API, send a message. A system that only produces text for a human to act on is an assistant.

The last clause is the one most definitions skip. Autonomy is a dial, not a property. The same agent can run in suggest-only mode or with real authority, and treating autonomy as configuration rather than identity is what makes an agent governable at all.

Where the textbook types fit

If you have searched “types of AI agents” you have met the taxonomy from Russell and Norvig’s Artificial Intelligence: A Modern Approach: simple reflex agents, model-based reflex agents, goal-based agents, utility-based agents, and learning agents.

It predates LLMs by decades and it is still a useful ladder. Most enterprise agents today are goal-based agents with learned parts: a language model plans, tools act. Plenty of products sold as agents are simple reflex agents with a chat window. When a demo feels shallower than the pitch, the ladder tells you what is missing: state, goals, or any reasoning about trade-offs.

The loop is the point

Strip the vendor language away and every real agent runs the same cycle. AWS describes it as perceive, reason, act, learn. Salesforce’s Atlas Reasoning Engine, the planner behind Agentforce, describes the same shape as reason, act, observe, repeated until the goal is met.

The important word is loop. A script runs its steps. An agent looks at the result of each step before choosing the next one.

Anthropic’s engineering guidance puts it precisely: agents gain “ground truth from the environment at each step (such as tool call results or code execution)” and re-plan from it. That feedback is what lets an agent recover from a failed lookup, notice the customer changed the subject, or drop a plan that is not working.

Watch it once in a real case. A customer asks where their order is. The agent reads the message and the customer record, decides it needs shipment data, calls the order-status API, and sees the package is three weeks late.

It re-plans: policy allows a goodwill credit, so it drafts one. Depending on where you set the dial, it applies the credit or routes it for approval. Nobody scripted that path. It came out of the loop.

The trade is simple. You get adaptability and you give up the predictability of code. Which is why the next distinction matters more than any other.

Agent, workflow, or wrapper: three things sold under one name

Anthropic draws the cleanest line I know. Workflows are “systems where LLMs and tools are orchestrated through predefined code paths”. Agents are systems where LLMs dynamically direct their own processes and tool usage. Below both sits the wrapper: input, prompt template, API call, output. No tools, no state, no loop.

	LLM wrapper	Workflow	Agent
Control flow	Fixed: prompt in, text out	Predefined code paths	Decided by the model at runtime
Tool use	None	Orchestrated by code	Selected by the model
Feedback loop	None	Only where coded	Observes each result, re-plans
Novel situations	Fails without telling you	Handles anticipated branches	Adapts, within guardrails
Typical failure	Wrong text	Stuck at an unplanned branch	Wrong action
Best for	Single transformations	Repeatable, well-defined processes	Open-ended goals with verifiable feedback

Two things follow. The loop can matter more than the model. Andrew Ng’s team reported that GPT-3.5 scored 48.1% on HumanEval zero-shot, GPT-4 scored 67.0%, and GPT-3.5 inside an agent loop reached 95.1%. The architecture bought more than the model upgrade did.

And none of this makes an agent the default choice. Anthropic’s own advice is to find “the simplest solution possible, and only increasing complexity when needed”. If your process has five known steps and no judgment calls, a workflow is cheaper, faster and easier to audit. Most of the automation candidates I see in Salesforce orgs are workflows wearing an agent costume, and they are better off as workflows.

The autonomy dial

The useful question about any agent is not how smart it is. The question is what it may do without a human. There are three positions.

Suggest. The agent perceives and reasons, drafts the action, and a human executes it. Full loop, zero authority. Start here.

Act with approval. The agent does the low-stakes steps itself and pauses at the consequential ones. It looks up the order, drafts the refund, and waits. A human approves in one click, and the approval rate over time tells you when to loosen the dial.

Act. The agent finishes the task on its own, with logging and sampled review afterwards. Reserve this for actions that are reversible, bounded, and cheap to get wrong.

The dial is set per action, not per agent. One service agent can answer product questions on its own, process refunds under a threshold with approval, and be forbidden from touching contracts. Red Hat frames agentic systems as a spectrum from assisted to independent, which is right, as long as you apply the spectrum to each capability rather than the whole agent.

Two axes decide where the dial sits: reversibility and blast radius. A $20 goodwill credit is reversible and small, so automate it. A contract cancellation is neither, so a human owns it.

Anthropic’s guidance points the same way: checkpoints where the agent pauses for feedback, and defined stopping conditions so a bad plan cannot run forever. In my experience the dial moves outward over months of measured operation. It almost never starts at full autonomy, and teams that try usually turn it back down after an incident.

The five parts of a production agent

Whatever platform you build on, a production agent has the same five parts. Missing one is how demos die on contact with real data.

A model. The reasoning engine that picks the next step. It does not have to be the largest model available. As the HumanEval numbers show, a mid-tier model in a good loop beats a frontier model without one.
Tools and actions. Typed, well-described operations the model can call. In Agentforce these are built from Flows, Apex, or prompt templates, each with a description the reasoning engine reads to decide when to use it. Copy the division of labour: the agent decides whether to act, deterministic code decides how, the same way every time.
Memory and grounding. State within the session, plus retrieval from systems of record. Atlas leans heavily on retrieval-augmented generation to ground answers in CRM data rather than the model’s training. An ungrounded agent answers from memory: fluently, confidently, and sometimes fictionally.
Orchestration. The machinery that runs the loop: classifying the request into a topic, planning, sequencing tool calls, handling errors, and knowing when to stop or hand off. In Agentforce that is the Atlas engine’s job. Every serious framework has an equivalent.
Guardrails. Scope instructions, per-action permissions, escalation paths, audit logs. Salesforce treats guardrails as a first-class part of agent design alongside role, data, actions and channel, which is the right instinct. Guardrails written after launch are guardrails written after the incident.

Only one of the five is AI. The other four are data architecture, integration and governance. That is why agent projects look like systems integration far more than prompt writing, and why the teams that succeed treat them as a data and AI strategy problem rather than a line on a procurement form.

A five-question test

When a vendor, a colleague or a roadmap slide says “agent”, ask:

Does a model choose the next step at runtime, or did a developer choose every step in advance?
Can it use tools to change state in another system, and can it decline to use them when they do not fit?
Does it observe results and re-plan, or does it run once, front to back?
Does it carry state across steps, so step four knows what happened in step two?
Can you turn its autonomy down to suggest-only without switching it off?

Workflows usually fail questions one and three. Wrappers fail nearly all five. Failing is fine. A workflow that fails this test is often exactly what you should build. The problem is the label, because the label drives the governance.

The test works in reverse too: if something passes all five, govern it as an agent, with permissions, an audit trail and human checkpoints, even if the vendor politely calls it an assistant.

Why the pedantry pays

Gartner predicts over 40% of agentic AI projects will be cancelled by the end of 2027, citing rising costs, unclear value and weak risk controls. Those are the failure patterns behind most cancelled agent projects. The same release predicts that by 2028 at least 15% of day-to-day work decisions will be made autonomously by agents, up from close to zero in 2024, and that a third of enterprise software will include agentic capability. Both can be true at once. The technology is real, and most projects chasing it are mislabelled, misgoverned or misapplied.

The window is now. McKinsey’s late-2025 survey found 88% of organisations use AI in at least one function, 23% are scaling an agentic system somewhere, and another 39% are experimenting. Deloitte had predicted 25% of enterprises using gen AI would deploy agents in 2025, doubling by 2027. Agents are being bought either way. What is scarce is discipline.

A working definition buys you that discipline. You can audit a vendor claim in one meeting. You can size governance to real autonomy instead of marketing copy.

And you can pick a first project with the odds on your side: a narrow goal, grounded data, reversible actions, and the dial at act-with-approval. Get that one loop into production and measured, and you have earned the right to turn the dial. Which is more than most of the cancelled 40% ever managed.

Understanding the basics

What is the difference between agentic AI and an AI agent?

An AI agent is a single system: a model that perceives context, reasons, and takes actions through tools toward a goal. Agentic AI is the broader property, the class of systems that behave this way, including setups where several specialised agents coordinate on one process. In practice the terms overlap. “Agentic” describes the behaviour, “agent” describes the software doing it.

Is ChatGPT an AI agent?

A plain chat session is not an agent. It is a conversational interface to a model, producing text with no tools, persistent goals, or actions. It becomes agentic when it is given tools and authority (browsing, code execution, API access) plus a loop that observes results and re-plans. The test is not the brand. The test is whether a model directs its own tool use toward a goal and can change state outside the conversation.

What separates an AI agent from a workflow?

Control flow. In a workflow, developers define the paths in advance and the LLM fills in steps within them. In an agent, the model decides the sequence at runtime, choosing tools and re-planning after each result. Workflows are more predictable and cheaper. Agents handle open-ended tasks that cannot be enumerated in advance. Most business processes need the workflow, not the agent.

If you are deciding whether your first agent should be an agent at all, talk to us. Scoping that question is most of what we do.