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

Ask five vendors what an AI agent is and you’ll get five answers, four of which describe whatever they happen to sell. Gartner calls this “agent washing” — rebranding chatbots, RPA bots, and assistants as agents — and estimates that of the thousands of vendors claiming agentic products, only about 130 offer real agentic capabilities. The word has been stretched until it covers almost anything with an LLM call inside.

This is more than a naming quarrel. The definition you adopt decides what you budget, how you govern, and what you’re actually accountable for when the thing acts. Call a chatbot an agent and you’ll buy governance you don’t need. Call an agent a chatbot and you’ll ship something that can issue refunds without anyone signing off on that capability. We see both mistakes regularly, and the second one is worse.

This post lays out a working definition that holds up in production: the perceive → reason → act loop behind it, what separates an agent from a workflow or an LLM wrapper, the autonomy dial, the five components every production agent needs, and a quick test for whether something is actually an agent at all.

A working definition of AI agents

Start with an uncomfortable fact: AI agents have no standard definition. The academic tradition is broad — an intelligent agent is anything that perceives its environment and acts on it to achieve goals. The marketing tradition is broader still. So here is the definition we use when scoping real projects:

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.

Each clause earns its place:

• Goal-directed means you give it an outcome (“resolve this ticket”), not a sequence of steps. The system works out the steps.
• Perceives context means it takes in the current state of the world — the conversation, the CRM record, the API response — not just a prompt.
• Reasons with a model means an LLM (or similar) decides what to do next at runtime. If every decision was made by a developer in advance, it’s automation, not an agent.
• Acts through tools means it can change things: update a record, call an API, send a message. A system that only produces text for a human to act on is an assistant.
• At a level of autonomy you choose is the clause most definitions miss. Autonomy is a dial, not a binary property. The same agent can be run in suggest-only mode or given real authority. Treating autonomy as configuration, not identity, is what makes agents governable.

Where the textbook types of AI agents fit

If you’ve searched “types of AI agents,” you’ve met the classic taxonomy from Russell and Norvig’s Artificial Intelligence: A Modern Approach: simple reflex agents (fixed if-then rules, no memory), model-based reflex agents (an internal model of the world), goal-based agents (plan toward objectives), utility-based agents (weigh trade-offs between outcomes), and learning agents (improve from feedback).

The taxonomy predates LLMs by decades, but it’s still a useful maturity ladder. Most enterprise “agents” today are goal-based agents with learned components: a language model does the planning, tools do the acting. And plenty of products sold as agents are, honestly, simple reflex agents with a chat interface. The ladder tells you what’s missing — state, goals, trade-off reasoning — when a demo feels shallower than the pitch.

The perceive → reason → act loop, and why the loop is the point

Strip away vendor language and every real agent runs the same cycle. AWS describes it as four stages: perceive (collect data from the environment), reason (an LLM interprets the goal and plans), act (execute through integrations), and learn (refine from results). Salesforce’s Atlas Reasoning Engine, the planner behind Agentforce, describes the same shape as a reason-act-observe loop: it cycles through reasoning, acting, and checking outcomes until the goal is reached.

The load-bearing word is loop. A script executes steps; an agent evaluates the result of each step before deciding 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 accordingly. That feedback is what lets an agent recover from a failed lookup, notice that a customer changed the subject, or abandon a plan that isn’t working.

Watch the loop in a concrete case. A customer asks where their order is. The agent perceives the message and the customer record, reasons that it needs shipment data, acts by calling an order-status API, observes that the package is three weeks late, and re-plans: policy allows a goodwill credit, so it drafts one and — depending on where you’ve set the dial — either applies it or routes it for approval. No developer scripted that path. The path emerged from the loop.

That runtime flexibility is the whole trade. You get adaptability; you give up the predictability of code. Which is why the next distinction matters so much.

Agent vs. workflow vs. LLM wrapper: three architectures sold under one name

Anthropic draws the cleanest line in the industry. 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, maintaining control over how they accomplish tasks.” Below both sits the LLM wrapper: input, prompt template, API call, output. No tools, no state, no loop.

The differences are architectural, not cosmetic:

	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 quietly	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 practical notes. First, the loop can matter more than the model. Andrew Ng’s team reported that GPT-3.5 scored 48.1% on the HumanEval coding benchmark zero-shot, GPT-4 scored 67.0% — and GPT-3.5 wrapped in an agent loop reached 95.1%. The architecture bought more than the model upgrade did.

Second, none of this makes agents the default choice. Anthropic’s own advice is to find “the simplest solution possible, and only increasing complexity when needed”. Workflows are underrated. If your process has five known steps and no judgment calls, a workflow is cheaper, faster, and easier to audit. In practice, most of the automation candidates we see in Salesforce orgs are workflows wearing an agent costume — and they’re better for it.

The autonomy dial: suggest, act with approval, act alone

The most useful question about any agent is not “how smart is it?” but “what is it allowed to do without a human?” There are three broad positions on the dial:

• Suggest. The agent does the perceiving and reasoning, drafts the action — a reply, a record update, a credit — and a human executes it. Full loop, zero authority. This is where most deployments should start.
• Act with approval. The agent executes low-stakes steps on its own and pauses at consequential ones. It looks up the order, drafts the refund, and waits. A human approves in one click, and the approval rate itself becomes a signal for when to loosen the dial.
• Act. The agent completes the task end-to-end, with logging and sampled review after the fact. Reserve this for actions that are reversible, bounded, and cheap to get wrong.

The dial is set per action, not per agent. The same service agent can answer product questions autonomously, process refunds under a threshold with approval, and be flatly forbidden from touching contracts. Red Hat frames agentic systems as operating on a spectrum from assisted to independent, and that’s the right mental model — but the spectrum applies at the level of individual capabilities.

Where should the dial sit? Two axes decide it: reversibility and blast radius. A $20 goodwill credit is reversible and small; automate it. A contract cancellation is neither; a human owns it, always. Anthropic’s guidance points the same way — agents need checkpoints where they pause for human feedback, plus defined stopping conditions so a bad plan can’t run forever. In our experience the dial moves outward over months of measured operation. It almost never starts at full autonomy, and teams that try to start there usually end up turning it back down after an incident.

Five components every production agent needs

Whatever platform you build on, a production agent decomposes into the same five parts. Missing any one of them is how demos die on contact with reality.

1. A model. The reasoning engine that decides what to do next. It doesn’t have to be the largest model available — as the HumanEval numbers above show, a mid-tier model in a good loop can beat a frontier model without one.
2. Tools and actions. Typed, well-described operations the model can invoke. In Agentforce, actions are built from Flows, Apex, or prompt templates, each with a natural-language description the reasoning engine reads to decide when to use it. The pattern to copy is the division of labour: the agent decides whether to act; deterministic code underneath decides how, the same way every time.
3. Memory and grounding. State within the session, plus retrieval from systems of record. The Atlas engine leans heavily on retrieval-augmented generation to ground responses in actual CRM data rather than the model’s training distribution. An ungrounded agent answers from memory — fluently, confidently, and sometimes fictionally.
4. Orchestration. The machinery that runs the loop: classifying the request into a topic, planning, sequencing tool calls, handling errors, knowing when to stop or hand off to a human. In Agentforce this is the Atlas Reasoning Engine’s job — it evaluates a request against the agent’s topics, picks one, and orchestrates the actions in scope. Every serious framework has an equivalent.
5. Guardrails. Scope instructions, per-action permissions, escalation paths, and audit logs. Salesforce treats guardrails as a first-class attribute of agent design, alongside role, data, actions, and channel — which is the correct instinct. Guardrails defined after launch are guardrails defined after the incident.

Notice that only one of the five is “AI.” The other four are data architecture, integration, and governance — which is why agent projects resemble 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 procurement line item.

A five-question test for “is this actually an agent?”

When a vendor, a colleague, or an internal roadmap slide says “agent,” run it through these:

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

Workflows typically fail questions 1 and 3. Wrappers fail nearly all five. And failing is fine — a workflow that fails this test is often exactly what you should build. The problem is the mislabel, because the label drives the governance. The test also works in reverse: if something passes all five, govern it as an agent — permissions, audit trail, human checkpoints — even if the vendor politely calls it an assistant.

The definition is a planning tool, not a debate

Here’s the market context that makes the pedantry pay off. Gartner predicts over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls — the failure pattern behind most canceled agent projects. The same press release predicts that by 2028, at least 15% of day-to-day work decisions will be made autonomously through agentic AI — up from essentially zero in 2024 — and that a third of enterprise software will include agentic capability. Both predictions can be true at once: the technology is real, and most projects chasing it are mislabeled, misgoverned, or misapplied.

Adoption data says the window is now. McKinsey’s late-2025 survey found 88% of organizations 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’s scarce is discipline.

That’s what a working definition buys you. You can audit a vendor claim in one meeting. You can size governance to actual autonomy instead of marketing language. And you can pick a first project with the odds loaded in your favour: a narrow goal, grounded data, reversible actions, and the dial set to act-with-approval. Get that one loop into production and measured, and you’ve earned the right to turn the dial — which is more than most of that canceled 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 and architectures that behave this way, including setups where multiple specialized agents coordinate on one process. In practice the terms overlap heavily; “agentic” describes the behavior, “agent” describes the software doing it.

Is ChatGPT an AI agent?

A plain chat session is not an agent — it’s a conversational interface to a model, producing text with no tools, persistent goals, or actions. It becomes agentic when it’s given tools and authority: browsing, code execution, or API access, plus a loop that observes results and re-plans. The test isn’t the brand; it’s 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; the sequence is fixed code. In an agent, the model decides the sequence at runtime, choosing tools and re-planning based on each result. Workflows are more predictable and cheaper; agents handle open-ended tasks that can’t be enumerated in advance. Most business processes genuinely need the workflow, not the agent.

---

Trying to work out whether your first agent should actually be an agent? Talk to us — scoping that honestly is what we do.