Gartner went looking for AI agents in 2025 and found something worth remembering. Of the thousands of vendors claiming agentic capability, roughly 130 were building anything that deserved the word. Not 130 good ones out of a field of 200. One hundred and thirty out of thousands.
That ratio is the reason this question is hard to answer by reading marketing pages. The term is applied to chatbots, to scheduled scripts, to autocomplete, and occasionally to something that genuinely is an agent. So it is worth starting from the technical definition rather than the sales one, because the technical definition is short and it draws a line you can actually check.
One Sentence, and Then the Consequences#
An AI agent is a system in which the model decides what happens next, rather than the code.
That is the whole distinction. Anthropic, whose engineering team wrote the reference description of this, splits the field into two: workflows are "systems where LLMs and tools are orchestrated through predefined code paths", while agents are "systems where LLMs dynamically direct their own processes and tool usage".
Sit with that for a second, because the consequences are larger than the sentence.
In a workflow, a developer decided in advance that step three follows step two. The model might write the text in step two, brilliantly, but it does not get a say in whether step three happens. The path is fixed. You can draw it on a whiteboard and the drawing stays accurate.
In an agent, the model is handed a goal and a set of capabilities, and it picks. It might use one tool, or six, or the same tool four times with different inputs, or none at all. Run the same task twice and you can get two different paths to the same result. You cannot draw it on a whiteboard, because the drawing changes every run.
That is why agents are powerful and it is exactly why they are hard to operate. Everything else you read about agents, the reliability engineering, the guardrails, the monitoring, follows from that one property.
What Such a System Is Made Of#
Strip away the vendor diagrams and there are five parts. All five have to be there, and the ones people forget are the last two.
The model. The part that reasons. It reads the situation and decides on the next action. It is worth understanding that the model starts fresh every single time it is called. It has no memory of the previous step except what you hand it. Everything that feels like continuity is something the surrounding system reconstructed and passed back in.
The tools. What the agent can actually do. Read a database, send an email, create a ticket, query an API, fetch a page. Without tools you have a chat window. With tools you have something that changes state in the world, which is a different category of object entirely. The number of tools is not a virtue. Every additional tool is another thing the model can pick wrongly.
The memory. Short-term, meaning the running record of this task, and long-term, meaning what carries across sessions. The customer's previous three complaints. The decision made last Tuesday and why. Without long-term memory an agent greets a ten-year customer exactly like a stranger, every time, which people notice immediately and dislike intensely.
The loop. The cycle that keeps the whole thing moving: give the model context, receive a decision, execute it, add the result to the context, ask again. This continues until the model signals it is finished, or until a limit stops it. The limit is not optional. An unbounded loop is a system that can spend your money forever on a task it is quietly failing.
The guardrails. What sits between a decision and an action with consequences. Permission checks, approval gates, policy rules, spending caps, an audit trail. This is the part that separates a demo from a system somebody is willing to be responsible for, and it is the part that almost never appears in the video.
There is a hard arithmetic reason the last two matter. Reliability across a chain of model decisions multiplies rather than averages. A step that is right 95 percent of the time is fine on its own and unrecognisable after twenty of them in a row. That is not a flaw to be fixed with a better model. It is a property of chaining probabilistic decisions, and the engineering answer is to shorten the chain, verify along the way, and put a gate before anything you cannot undo.
Where You Have Already Met One#
The abstraction gets easier with concrete cases, so here are four that are unambiguously agents rather than dressed-up workflows.
A coding assistant that reads your repository, decides which files are relevant, opens them, makes a change, runs the tests, sees a failure, and goes back to fix it. Nobody scripted that sequence. The model chose to run the tests, read the output and decided the failure was worth another pass.
A research assistant given a company name that decides on its own which searches to run, notices that two sources disagree, goes looking for a third to break the tie, and reports the disagreement rather than picking one at random.
A support system that reads an incoming message, checks the order status in one system, checks the shipping status in another, sees the parcel is stuck at customs, and writes an answer that explains customs rather than quoting the standard delivery window. The path through those two systems was not predetermined. It depended on what the first check returned.
An operations watcher that monitors a set of services, notices a pattern that is not on any alert list, correlates it with a deployment from two hours earlier, and tells a human where to look.
What these have in common is the branching. At some point the system encountered a situation and picked a response that nobody wrote down in advance.
And Where the Word Gets Stretched#
By the same standard, several very useful things are not agents.
A chatbot that answers from a document collection is not an agent, however good it is. It retrieves and it generates. It does not choose actions.
A scheduled script that pulls data every night and emails a summary is not an agent, even if a model writes the summary. The path is fixed. A model doing one job inside a fixed path is a workflow with a smart step.
An assistant that drafts something and waits for you to press send is not an agent in the strict sense either. It proposes. You decide. That is a copilot, and for a great many jobs it is the correct design.
None of this is a criticism. Anthropic's own guidance is to find the simplest solution that works and to add agentic complexity only when it demonstrably improves the outcome, because agentic systems trade latency and cost for task performance. In practice that means a substantial share of business problems are better served by a well-built workflow than by a real agent, and a supplier who tells you that is being straight with you.
The reason the labels matter anyway is money. If you are quoted agent pricing for workflow capability, you are paying for autonomy you are not receiving. One question usually settles it: given the same input twice, can the system take two different paths? If the honest answer is no, it is a workflow, and it should be priced like one.
What They Still Cannot Do#
Four limits, all of which show up within weeks of a real deployment.
They cannot reliably tell you what they do not know. A model that lacks a fact will often produce a plausible one instead of stopping, and an agent will then act on it. This is why grounding in your own data and marking unverified claims as unverified matter more in agent systems than in chat.
They cannot carry responsibility. When an agent issues a wrong refund, the accountability sits with whoever deployed it. That is not a technical statement, it is a legal and organisational one, and it is why the approval gate exists.
They do not handle unbounded scope. An agent with one clear job and four tools works. The same model with a vague brief and forty tools produces something that cannot be debugged, because the failure is never in one place.
They do not survive unattended forever. Systems change, APIs move, the business changes its rules, and an agent that was correct in March is quietly wrong by September if nobody is watching it.
Where This Actually Stands in Germany#
The gap between the discourse and the deployment numbers is worth knowing.
The AI index for the German Mittelstand, produced by Salesforce with the Deutscher Mittelstands-Bund and published in March 2026, found 16.6 percent of mid-sized German companies using AI agents, up from 8.7 percent a year before. A near doubling in twelve months, and still fewer than one in five. A further 37 percent said they planned to introduce or expand AI in 2026.
Bitkom's survey of 604 German companies with 20 or more employees, conducted in the first weeks of 2026, found 41 percent using AI actively at all, against 17 percent the year before. But only 21 percent had an AI strategy, and 41 percent named uncertainty about data protection as their largest obstacle.
Put those together and you get an accurate picture: adoption is climbing fast, understanding is lagging behind it, and the thing holding most German companies back is not scepticism about capability. It is a legitimate uncertainty about what happens to their data and who answers for the outcome. Both of which are answerable, but only by a supplier willing to answer them rather than route around them.
The Useful Version of the Question#
"What are AI agents" is worth answering precisely, but it is rarely the question that matters in a business. The question that matters is narrower: is there a task here where the deciding is the expensive part?
If the expensive part is typing, you want automation and you do not need an agent. If the expensive part is that someone has to look at each case, weigh two or three things and pick a path, that is where an agent earns its keep. Incoming enquiries that arrive in five formats. Documents that mostly follow a pattern and sometimes do not. Research that has to be checked against several sources before anyone can act on it.
That is also how we scope them. One task where the judgement is the bottleneck, a small set of tools, real cases from the customer's own history for testing, a human gate in front of anything irreversible, and someone named as responsible for it after handover. Our own agents run on that pattern daily, researching, monitoring and preparing work for us, which is the standard I would apply to any supplier: ask whether they run what they sell.
The word "agent" will keep drifting, because words attached to budgets always do. The property underneath it will not. Somewhere in the system, either the code decides or the model decides. Knowing which one you are buying is most of the decision, and it is where any serious conversation about an agent should start.
