What Makes an AI System 'Agentic'? A Plain-English Guide for Decision-Makers

"Agentic AI" is 2026's most-used and least-defined phrase. Vendors staple it onto everything from a chatbot with a new coat of paint to a cron job that calls GPT. So before your next vendor meeting, here's the working definition we use as engineers, and the questions it should make you ask.

The one-sentence definition

An agentic AI system is software in which a language model doesn't just produce an answer. It pursues a goal: it plans, takes actions using tools, checks its own progress, and keeps working until the job is done or a human needs to decide.

The difference is easiest to feel as a user:

• You ask a chatbot: "What's your refund policy for damaged items?" It answers.
• You tell an agent: "Process this refund." It looks up the order, checks the damage claim against policy, issues the refund in your payment system, emails the customer, and logs the case. When something doesn't add up, it stops and asks a human.

One is a better search box. The other is a coworker.

The five capabilities that make a system genuinely agentic

When we audit a system that claims to be an agent, we look for five things.

1. Planning. Given a goal, the system decomposes it into steps, and can revise the plan when reality disagrees with it. A hardcoded sequence of API calls with an LLM sprinkled in is a workflow, not an agent. (Workflows are great. They're also cheaper. More on that below.)

2. Tool use. The agent can act on the world through tools: query a database, call an API, file a ticket, run code. Crucially, each tool defines what the agent can do, which makes the tool layer your security boundary, not the prompt.

3. State. Real tasks take many steps. An agent needs memory of what it has done, what it learned, and what remains, kept outside the prompt, so long tasks don't degrade as the context fills with noise.

4. Recovery. APIs time out. Searches come back empty. Models produce malformed output. An agentic system treats failure as a normal path: retry differently, back off, try another approach, or escalate, rather than confidently improvising.

5. Knowing when to stop. The most underrated capability. Good agents recognize done, recognize stuck, and recognize "this is above my pay grade." An agent without stop conditions is an incident report waiting to happen.

Why agents are genuinely hard to build

Here's the math that explains most agent failures. Suppose each step your agent takes succeeds 95% of the time, a rate that sounds excellent. A 20-step task then succeeds at 0.95^20, which is about 36%. Two-thirds of runs fail somewhere.

That's the engineering gap between a demo and a production agent. Demos are five steps long and run by the person who built them. Production tasks are twenty steps long and run by reality. Closing the gap isn't about a smarter model. It's about the machinery around the model:

• Evals: a suite of real tasks with verifiable outcomes, run on every prompt or model change, so quality is measured rather than vibed.
• Guardrails: input screening (prompt injection is real, and agents with tools raise the stakes), output checks, and permission-scoped tools.
• Observability: full traces of every decision and tool call, so when something goes wrong you can see why, and prove what happened.
• Budgets: token, time and cost ceilings per run, so a confused agent fails cheap instead of failing expensive.

This machinery, sometimes called the harness, is most of the work and most of the value. It's the same pattern behind tools like Claude Code and the deep-research modes of major assistants: the model matters, but the harness is what makes it dependable. Building that harness is exactly what our AI agent development practice does.

Do you actually need an agent?

Honest answer: often, no. Here's the decision ladder we walk clients through, cheapest first:

1. A prompt and a human. If the task is occasional, a well-designed prompt in ChatGPT or Claude plus human judgment wins on cost.
2. A workflow. If the steps are predictable (extract, validate, route), build a deterministic pipeline with LLM calls at specific points. Reliable, debuggable, cheap. This is the sweet spot for most AI workflow automation.
3. A chatbot with retrieval. If the job is answering questions from your content, you need a grounded chatbot, not an agent.
4. An agent. If the task requires judgment across many steps with real actions, and its volume justifies engineering: support resolution, back-office operations, research, code tasks.

A vendor who recommends an agent before understanding which rung you're on is selling you their product, not solving your problem. (We wrote about that dynamic in why AI pilots fail.)

Questions that separate real agent vendors from rebranded chatbots

Take these to your next demo:

• "Show me your eval suite. How do you measure task success, and on how many test cases?"
• "What happens when a tool call fails three times?"
• "How do you defend against prompt injection arriving through the data the agent reads?"
• "What's the cost per completed task at my volume, and the cost per failed task?"
• "When the agent is unsure, how does it escalate, and what context does the human receive?"

Confident, specific answers mean you're talking to engineers. Hand-waving means you're talking to a deck.

---

Mindela designs and builds agentic AI systems: the agents and the harnesses around them, for companies that need them to work on Monday morning, not just in the demo. If you're weighing whether an agent is the right call for a workflow, tell us about it; you'll get an engineering answer either way.