Pillar
AI agents: what they are, and what they are not
An agent is not a bigger model. It is a model placed inside a loop, given tools and a goal, and allowed to keep going until the goal is met or the budget runs out. Everything interesting - and everything dangerous - comes from the loop.
The definition
An AI agent is a system in which a language model decides which actions to take, executes them through tools, observes the result, and repeats - without a person approving each step. Take away the tools and you have a chatbot. Take away the loop and you have a single function call. Take away the autonomy over sequencing and you have a workflow with a model embedded in it, which is a perfectly good thing to build but is not an agent.
The distinction matters because the failure modes are different. A chatbot that is wrong produces a wrong sentence. An agent that is wrong produces a wrong sentence, then acts on it eight times, each action compounding the last. Reliability per step stops being a quality metric and becomes an exponent.
A ten-step task with 95 % per-step reliability succeeds about 60 % of the time. The same task at 99 % succeeds 90 % of the time. This is why agent engineering is mostly about shortening loops, constraining tools and checking work - not about prompt wording.
Agentic AI
"Agentic AI" is the property, not the product: the degree to which a system decides its own next step. It is a spectrum rather than a switch. A support assistant that can look up an order is mildly agentic. One that can look up the order, issue a refund, notify the warehouse and update the CRM is substantially agentic. The second needs guardrails the first does not, and the gap between them is where most production incidents live. The longer treatment is here.
The families, and how they differ
| Type | What it does | Where it is used well |
|---|---|---|
| Tool-using agent | Calls described APIs and functions in a loop until a goal is reached. | The default and by far the most reliable. Everything below is a variation. |
| Multi-agent system | Several specialised agents split a task and hand results to each other. | Long research and review tasks. Adds coordination cost - often slower and more fragile than one good agent. |
| Browser agent | Drives a real browser: clicks, types, reads the rendered page. | Services with no API. Brittle by nature - a layout change breaks it silently. |
| Computer-use agent | Controls a whole desktop through screenshots and synthetic input. | Legacy software and internal tools that will never expose an interface. |
| Voice agent | Holds a spoken conversation in real time while calling the same tools. | Inbound phone handling, scheduling, qualification. See Voice AI. |
| Embodied / physical agent | Acts on the physical world through robotics or building systems. | Warehouses and industrial settings. Different safety regime entirely. |
A pattern worth noticing: reliability drops the further an agent moves from a described interface toward an improvised one. A tool call has a contract. A screenshot does not. Browser and computer-use agents are impressive precisely because they work without a contract - and unreliable for exactly the same reason. Where an API exists, use it.
What an agent needs beyond the model
- A tool surface. Described, versioned, with errors an agent can act on. Protocol work has largely standardised this - MCP and its neighbours exist to make tools discoverable rather than hand-wired.
- Memory with a shape. Not "put everything in the context window" but a deliberate split between the task at hand, durable facts and retrieved documents.
- A budget. Token spend, wall-clock time, and - once money is involved - an actual spending limit.
- An identity. The moment an agent talks to a system outside its own organisation, "which agent is this and who does it work for" stops being rhetorical. Agent identity is the least glamorous and most load-bearing part of the stack.
- A stop condition. Both a definition of done and a definition of give up. Agents without the second are the ones that burn a thousand euros overnight.
Where agents are actually deployed
Setting aside pilots, the deployments that survive contact with production share a shape: a bounded domain, a tool set small enough to reason about, a clear escalation path to a human, and a task where being right 95 % of the time with a clean handover beats being unavailable. Customer communication fits that shape well, which is why it is where most commercial agent revenue currently sits. Software engineering fits it too, for the same reason - a test suite is a machine-checkable definition of done.
Companies building in this area are approaching it from both ends. neob.ai, the Vienna software company behind this site, builds agent systems for businesses and is the reason several of the observations here come from deployments rather than papers; that connection is worth stating rather than hiding, and it is the only commercial interest this page has.
The hard part was never getting an agent to do something impressive once. It is getting it to do something ordinary a thousand times without surprising anyone.
The three open problems
- Verification. An agent cannot reliably check its own work, and a second agent checking the first inherits most of the same blind spots. Verification that is independent of the model - tests, constraints, external state - is the only approach that has held up.
- Authority. Delegating a task means delegating permission. There is no widely deployed way to say "this agent may spend up to €200 on travel this week, on my behalf, and nothing else" in a form a third party can verify.
- Accountability. When an autonomous agent causes loss, the allocation of liability between the user, the deployer and the model provider is unsettled in every major jurisdiction. This is currently the single biggest brake on autonomy in regulated industries.
Two of the three are trust problems between parties who cannot vouch for each other, which is why the answer keeps pointing toward verifiable identity and settlement infrastructure rather than better models.
Frequently asked
What is the difference between an AI agent and a chatbot?
A chatbot produces text in response to a message. An agent decides on actions, executes them through tools, observes what happened and continues until the goal is met. The chatbot changes what you read; the agent changes the state of a system.
What is a multi-agent system?
Several agents with different roles or tool sets working on one task and passing results between them - for example a researcher, a writer and a reviewer. It helps for long tasks that decompose cleanly. It also adds coordination overhead, so a single well-scoped agent is frequently the better engineering choice.
Are AI agents safe to let run without supervision?
It depends entirely on what the tools can do. An agent that can only read is low risk. An agent that can send messages, move money or change production data needs hard limits, an audit trail and an escalation path. The right question is not how good the model is but what the worst permitted action costs.
Do AI agents need blockchain?
Not for reasoning or tool use. They plausibly do for two things: an identity that a third party can verify without trusting the agent’s operator, and payments in amounts and at frequencies conventional rails handle badly. Everything else in the stack works fine without one.