What is agentic AI?

Suppose you give an AI system this task:

A normal LLM might read the code and suggest changes. With repository access and test tools, an agentic system might follow this path when it discovers a bug:

1. Inspect the repository.
2. Understand the PR.
3. Run the tests.
4. Identify the failing code.
5. Modify the implementation.
6. Run the tests again.
7. Inspect the new failures.
8. Make another change.
9. Ask for human approval if necessary.
10. Finish only when the evidence shows the task is complete.

This is an illustrative path, not a fixed script: the next step depends on what the system finds. That closed loop is one of the defining characteristics.

The numbered actions below map that example onto the loop. Several actions revisit the same stage.

Agentic doesn’t necessarily mean multi-agent. A single agent using tools and a feedback loop is agentic. A system such as Planner → Implementer → Reviewer is one way to organize the work, not the definition itself.

A useful way to distinguish an agent from a chatbot or workflow is to ask: who decides the next step?

• Chatbot: the user drives the sequence.
• Workflow: the developer predefines the sequence and decision rules.
• Agent: the AI can decide the sequence dynamically based on what happens.

These distinctions describe how the work is controlled, not how the interface looks. A chat interface can also be the front end to an agent.

Imagine the goal is: “Resolve this failed customer payment.”

A chatbot explains

A workflow follows predefined logic

Check payment status → Check account → Send retry email → Create support ticket

That sequence is fixed in advance. A workflow can include conditional branches, but the developer still defines the available paths.

An agent adapts to the evidence

The path changes depending on the evidence. The agent can decide what to investigate next, but that does not give it permission to act outside its authorization.

In practice, look for these capabilities working together:

The capabilities form a loop: understand the current state, choose an action, use a tool, observe and evaluate the result, update state, and replan. Continue if the goal is not yet achieved; finish when the evidence supports completion, or escalate when it is not safe or possible to continue.

The application supplies instructions, context, tools, permissions, and memory. The agent uses those resources to choose its next action within the task’s constraints.

Many products call themselves agents when they are closer to this:

Prompt → LLM → API call → Response

Calling an API does not automatically make an application agentic. Similarly, a sequence like this is often just an LLM-powered workflow if the steps are predetermined:

LLM → Step 1 → Step 2 → Step 3 → Step 4

The important distinction isn’t whether an LLM is present. It is whether the system can choose and adapt its next actions based on intermediate results, rather than only follow predefined steps.

A workflow can still be the right design. A predictable process does not need open-ended decision-making simply to qualify for the “agent” label.

“Agent” is not a completely binary category. It helps to distinguish several system patterns—but not treat them as a ladder where more agents automatically mean more intelligence or autonomy.

LLM application

Tool-using assistant

Tool use alone does not establish whether the assistant controls an adaptive sequence.

AI workflow

Extract → Classify → Summarize → Create ticket

Agent

Decide what needs to be investigated, select tools, act, evaluate, and retry when appropriate.

Multi-agent system

A planner coordinates a researcher, implementer, reviewer, or other specialized agents. This describes how responsibilities are distributed. The overall process may be tightly scripted or dynamically coordinated.

Long-running autonomous agent

Pursues a larger objective over many steps, maintains state, handles failures and changing conditions, and involves humans when appropriate. It may use a single agent or multiple agents.

Duration, number of agents, and degree of autonomy are different design choices. A single agent can have substantial autonomy; a multi-agent system can operate within a tightly constrained workflow.

Production-grade agentic AI needs bounded autonomy: permissions, evidence checks, observability, evaluations, retry limits, human approval points, and safe escalation.

A practical architecture makes those responsibilities explicit:

Evidence, not assumptions

The evidence gate is especially important. Without it, many so-called agents are simply models repeatedly generating actions and assuming they worked.

In the pull-request example, changing the code is not proof that the bug is fixed. The agent needs to inspect test results and other relevant checks. In the payment example, sending an authorization request is not permission to charge another payment method.

The gate should ask whether an action succeeded, what remains unresolved, and whether the next step is allowed. A model’s own assertion of success is not enough.

Autonomy within explicit limits

Permissions define what the agent may access and change. Observability makes its actions inspectable. Evaluations test its behavior. Retry limits prevent endless loops, while approval points and escalation paths preserve human control over consequential decisions.

These controls turn a loop of model-generated actions into a system whose progress can be checked and whose authority remains bounded.