It is 11:40 pm and a deploy is blocked by one failing test. You paste the stack trace into a chatbot. It suggests a fix. You copy the fix into your editor, rerun the suite, get a new error, and paste that back. Nine round trips later, the test finally passes. The model did the thinking, but you did everything else: running commands, reading output, deciding whether to keep going.
Now picture the same night with a coding agent. You type one sentence: fix the failing checkout test. The agent reads the file, runs the suite, sees the failure, edits the code, reruns the tests, and reports back when they pass. Roughly the same model underneath. A completely different experience.
That difference is what people mean by agentic AI. The term is doing a lot of unsupervised work in marketing copy right now, so it is worth pinning down precisely what it is and what it is not.
Not a standard, not a product: a pattern
Let's answer the obvious question first. Agentic AI is not a standard. There is no RFC, no spec, no certification body that decides whether your system qualifies. It is also not a specific product or a new kind of model.
Agentic AI is an architectural pattern: a large language model placed inside a loop, given tools it can invoke, and allowed to decide its own next step until a goal is met. It belongs in the same category as "microservices" or "event-driven architecture". Those terms name a design approach with recognizable ingredients, not a formal specification.
Best practices exist, and they are converging fast. One genuine standard has emerged for a piece of the puzzle, which we will get to later. But when a vendor says their product is agentic, they are making an architectural claim, not a compliance claim. Sometimes the claim is accurate. Sometimes it is a chatbot wearing a trench coat.
The problem agents solve
An LLM, on its own, is a text function. Tokens in, tokens out. It has no hands, no memory between calls, and no way to check whether its answer actually worked. Chat interfaces wrapped that function in a conversation, which was a huge leap, but it left one job firmly with you: orchestration.
In a chat session, you are the one who executes suggestions, observes what happens, and feeds the results back. You are the loop.
The human loop works, but it is slow, tedious, and it caps the model's usefulness at advice. Many valuable tasks are not one-shot questions. They are iterative: try something, see what happens, adjust. Debugging, research, data migration, filling out a multi-step form. The problem agents solve is exactly this: letting the model act on the world and react to what comes back, without a human relay in the middle of every step.
How it works: the agent loop
Strip away the branding and every agent runs the same cycle, usually called the agent loop: reason, act, observe, repeat.
The mechanism that makes the "act" step possible is tool calling, sometimes called function calling. Each tool the agent can use is described to the model as a schema: a name, a purpose, and the parameters it accepts. A tool can be anything with a programmatic interface: a web search, a file read, a shell command, a database query, an internal API.
When the model decides it needs a tool, it does not answer in prose. It emits a structured request, something like run_tests(path="checkout/"). The model never executes anything itself. The surrounding runtime intercepts that request, actually runs the command, and appends the output to the conversation. Then the model is called again, now with the result in front of it, and it decides the next step.
That accumulating conversation is the agent's working memory. Everything it has tried, seen, and concluded lives in the model's context window, which is why long-running agents spend so much engineering effort on summarizing and pruning what they keep.
The loop ends when a stopping condition fires: the model declares the goal met, a step limit is reached, a budget runs out, or an error proves unrecoverable. Getting these conditions right is half the craft. An agent with no stopping rules is an infinite loop with a credit card.
Zoom out and an agent looks less like a model and more like a system:
This is the most useful mental model in the whole topic. The same LLM behaves like a chatbot or like an agent depending entirely on the harness around it. "Agentic" describes the system, not the model. It is engineering, not model magic.
Workflows, agents, and the spectrum between
Here is where the terminology gets muddy, and where your instinct that this might just be "a process" has some truth to it. Agency is not binary. It is a spectrum of how much control the model has over what happens next.
At one end sits the traditional workflow: code controls the flow, and the LLM fills in individual steps. Think of a support pipeline that always runs classify, then summarize, then draft a reply, with a model call at each stage. The steps are fixed. The model never decides what comes next.
At the other end sits the agent: the model itself chooses which tool to call, in what order, and when to stop. The path through the task is not written down anywhere. It emerges at runtime from the model's decisions.
Two things follow from this. First, a lot of products marketed as agentic are really LLM workflows, because their steps are predetermined. That is not an insult; workflows are more predictable, cheaper, and easier to debug, and they are often the right choice. Second, the spectrum keeps extending. Multi-agent systems put an orchestrating agent in charge of spawning specialized sub-agents, each running its own loop, for tasks too large for a single context window.
Where it gets hard
The loop that makes agents powerful is also what makes them fragile. Errors compound. If each step succeeds 95% of the time, a twenty-step task lands around a 36% end-to-end success rate. Reliable agents need self-checking behavior, verifiable feedback like test results or compiler errors, and tasks scoped so failures are cheap to detect and retry.
Cost and latency compound too. A chat answer is one model call; an agent run might be fifty, each carrying an ever-growing context. This is why serious agent products expose budgets, step limits, and progress you can interrupt.
Then there is security. An agent that reads external content and holds real permissions creates a new attack surface: prompt injection, where instructions hidden in a web page, email, or document trick the agent into misusing its tools. The standard mitigations are least-privilege tool access and human-in-the-loop checkpoints, where irreversible actions like sending money, deleting data, or emailing a customer require explicit approval. That red guardrails box in the anatomy diagram is not decorative.
Where you'll encounter it
Coding is the beachhead, because software gives agents exactly what they need: fast, verifiable feedback. Tools like Claude Code, Cursor, and the agent modes in GitHub Copilot run the full loop against your repository, editing files and running tests until things pass.
You have probably also met agents wearing other names. The deep research features in major AI assistants are agents whose main tool is search: they plan, query, read, refine, and repeat for minutes before writing a report. Browser and computer-use agents drive a screen with clicks and keystrokes to handle tasks like form filling. Customer support platforms increasingly run agents that can look up an order, apply a policy, and issue a refund end-to-end.
And that one real standard mentioned earlier: the Model Context Protocol (MCP), introduced by Anthropic in late 2024 and since adopted broadly across the industry. It standardizes how tools and data sources are described and connected, so a tool integration can be written once and used by any agent that speaks the protocol. Note what it standardizes, though: the plumbing between agents and tools, not agent behavior itself. The pattern remains a pattern.
Summary
The fuss about agentic AI is not about smarter models. It is about relocating a loop. For the first years of LLMs, the feedback cycle of act, observe, and adjust ran through a human doing the copying and pasting. Agentic architecture moves that loop into software: a model that can call tools, see the results, and decide its own next step until the job is done.
So the answer to "what is it really" is: an architectural pattern, with an emerging set of best practices around tool design, stopping conditions, and guardrails, plus exactly one real standard (MCP) for connecting the pieces. Once you see the loop, the buzzword decodes itself. The question to ask of any "agentic" product is simply: who decides the next step, the code or the model, and what happens when the model gets it wrong?
Part of the Explained series — concepts in tech, clearly.