What Are AI Agents

The Definition

Given an outcome,
not a procedure.

Ordinary software is written as a procedure. Do this, then that, and if this other thing is true, do the third thing. Every branch that will ever be taken was imagined in advance by a person, and anything they failed to imagine is a bug or a crash.

An AI agent inverts that. You hand it an outcome — "find out what our three closest competitors charge and put it in a table" — and no procedure at all. The procedure is produced turn by turn, at runtime, by a language model that can see everything that has happened so far.

That single change is where all of the value and all of the danger comes from. The agent can handle a page that moved, a site that blocks scrapers, a competitor with four pricing tiers instead of three, a source that turns out to be a year out of date — none of which anyone wrote a branch for. It can also confidently head in an entirely wrong direction for twenty minutes, because nothing in the design says it can't.

Automation fails loudly when reality doesn't match the script. An agent fails quietly, by adapting to reality in a way nobody asked for.

Everything else in this article — the loop, the tools, the memory, the supervision — is machinery for keeping the first behaviour while containing the second.

The Mechanism

There is only
one loop.

Strip away the marketing and every real agent is the same four-step cycle, repeated until the job is finished or a limit is hit. It is worth knowing precisely, because most of the things sold as agents are missing one of the four.

Watch turn four in that trace. The scrape came back 403 blocked — and the next move was not written by anyone. The model saw a real failure and chose a different route. That is the entire difference between an agent and a script with a retry policy: the script retries the same thing, the agent picks something else.

Two properties of this loop matter more than they sound:

• The result is real, not imagined. A weak imitation of this loop asks the model to describe what the tool would return, and keeps going on the description. Everything after that point is fiction. In a real loop the model is paused, the actual HTTP call happens, and the actual bytes come back before it is allowed to think again.
• The model proposes, trusted code disposes. The model emits a tool name and arguments — a structured request, not executable code. Something you wrote decides whether to honour it. That boundary is the only reason an agent can be given real credentials at all.

Anatomy

Five parts.
Miss one and it isn't an agent.

Use this as a checklist against anything described to you as an agent. Each missing part turns it back into something simpler.

The Confusion

Three things
wearing one word.

The clean way to tell them apart is not capability, it is authorship of the next step. Pick a category and see who decides — and, more usefully, what happens when step three fails.

	Chatbot	Automation	AI agent
Given	A question	A procedure	A goal
Next step chosen by	You, each turn	The author, in advance	The model, at runtime
Handles the unforeseen	Only if you notice	No — it breaks	Yes — that's the point
Runs unattended	No	Yes	Yes
Repeatable to the letter	No	Yes	No
Main failure mode	You stop asking	Reality changed	Confidently wrong

Note the two rows that are not flattering. Agents lose "repeatable to the letter" — run the same mission twice and you get two different routes to the answer, which is genuinely worse for anything that must be auditable step-for-step. And "confidently wrong" is not a bug to be patched out; it is the standing cost of letting something choose its own next move. The rest of this article is about paying that cost deliberately.

Degrees

Autonomy is
a dial, not a switch.

"Agentic" is not binary. What changes across the range is how much rope the system has and how much a human still holds — and most production systems sit lower on this dial than their marketing does.

The jump that actually matters is L2 to L3 — the point where the system stops only reading and starts writing: sending the message, opening the pull request, updating the record. Everything before that is contained by the fact that a mistake costs a wrong answer. After it, a mistake costs an action in someone else's inbox, repository, or CRM.

Honestly

Four ways this
goes wrong.

These are not edge cases. If you run agents on real work, you will meet all four, and knowing their shapes is most of what separates a system that survives contact with production from a demo.

• Plausible fabrication. Six of eight lookups succeeded, two were blocked, and the final report presents eight findings in the same confident voice. Nothing errored. The output is simply part fiction, and it reads exactly like the part that isn't.
• Context decay. Every tool result stays in the agent's context. Twenty scraped pages later, the original instruction is a thin voice in a crowd of noise, and quality slides long before any hard limit is reached.
• Goal drift. Asked to check competitor pricing, an agent finds an interesting page about a competitor's funding round, follows it, and produces a genuinely good report about the wrong subject. Every individual step was reasonable.
• Indirect prompt injection. An agent that reads the open web reads text written by people who know it is an agent. A page can contain instructions addressed to it. Once the same agent can also write — post, message, commit — the content it reads and the actions it takes are one attack surface.

What none of these have in common with ordinary bugs: they do not raise an exception. Every one of them produces a finished, fluent, plausible result. That is why the answer to all four is structural rather than a matter of better prompting.

The Answer

Nothing grades
its own homework.

An agent that spent twenty turns building an answer is the worst available judge of that answer. It has every reason to conclude it succeeded, and it has already rationalized the parts it guessed at. Asking it to review its own output produces agreement, not review.

So the useful containment is not a better instruction. It is four structural things:

• Independent verification. A separate model, with no access to how the work was done, judging only the result against the goal. This is the one check a single agent structurally cannot perform on itself, no matter how strong it is.
• Nothing untrusted is executed. The model emits tool requests, not code. If a platform runs model-written code, it needs a sandbox and a threat model; if it never does, that entire class of escape does not exist.
• Scoped, real credentials. An agent gets exactly the integrations its workspace has connected, with tokens scoped to that workspace — not a general key. Capability is the containment, not intent.
• Hard limits and a visible bill. Turn caps, time caps, and per-task metering, so a run that goes wrong is bounded and legible after the fact instead of discovered on an invoice.

The interesting question was never "how capable is the model." It is "what is the worst thing this is allowed to do before something else checks."

In Practice

One sentence in.
A team out.

Xorviex is built on exactly the loop described above, with the containment described above, and one addition: you don't design the agents.

You write a mission goal in plain language. A planner reads it and decides how many agents the work actually needs and what each one is for — there is no fixed cast and no default count. A single-objective job with no slow external work gets one agent. A benchmark spanning three companies across six platforms gets one agent per subject plus an analyst that reads their pooled findings.

Each of those agents then runs the real loop: it picks a tool, the trusted worker makes the actual call, and the actual result comes back before the next decision. It can search the live web, render a real page in a disposable browser container, read and write in your connected Slack, GitHub, Notion, Google Workspace or CRM, keep notes in a shared map its peers can read, and — for repository work — hold a persistent working tree where it runs your project's own tests before opening a pull request.

And nothing it produces reaches the outside world unaudited: every agent's output is judged by an independent Supervisor that did not do the work, and every atomic task is metered so the cost of a mission is a number you can look at rather than a surprise.

Further reading: single agent or multi-agent — how to decide, or what a mission actually costs.

Questions

The short
versions.

What is an AI agent, in one sentence?

An AI agent is a system that pursues a goal by repeatedly choosing a tool, using it, observing the real result, and deciding its next step from that result — rather than following a procedure a person wrote in advance. The defining property is who chooses the next step: in an agent, the model does, at runtime.

What is the difference between an AI agent and a chatbot?

A chatbot answers and stops. Every step of the actual work is initiated by a human typing again, so the initiative stays with you even though the intelligence is real. An agent is given an outcome instead of a question and keeps taking steps on its own until that outcome is reached or a limit stops it. A chatbot with tools attached is still a chatbot if it hands control back to you after every single action.

How is an AI agent different from workflow automation?

Automation executes a procedure that a person imagined in advance, so it is perfectly repeatable and breaks the moment reality stops matching the script. An agent is given only the outcome and produces the procedure turn by turn, so it can handle a moved page, a blocked request, or an unexpected number of results — at the cost of no longer being repeatable step-for-step.

What are AI agents made of?

Five parts: a goal specific enough to be checkable, a model that chooses the next action at runtime rather than up front, tools that touch reality such as search, page fetching, files and APIs, memory that at minimum holds its own transcript and ideally durable notes shared with peers, and a stopping condition with hard limits on turns, time and spend. Remove any one and the system collapses back into something simpler than an agent.

Are AI agents safe to give real access to?

Only with structure around them. The realistic protections are independent verification of every output by a model that did not produce it, never executing model-written code, credentials scoped to a single workspace and limited to integrations that were deliberately connected, and hard caps on turns, time and spend. The specific risk that grows once an agent can write as well as read is indirect prompt injection, since a page it reads can contain instructions addressed to it.

How do AI agents actually fail?

Almost never with an error. The four common failures are plausible fabrication, where partial evidence is reported in the same confident voice as verified findings; context decay, where quality slides as the transcript fills with tool results; goal drift, where every individual step is reasonable but the destination is wrong; and prompt injection from content the agent reads. All four produce fluent, finished, believable output, which is why the answer is structural rather than better prompting.

Do I need more than one AI agent?

Only when you can name the constraint you hit. Use several when the job is dominated by slow external work that can run concurrently, when the evidence is larger than one agent can hold without degrading, or when the output must be judged by something that did not produce it. Otherwise a single agent keeps perfect recall of its own investigation, costs less, and is far easier to debug.

The Difference

A demo, or
something you can run.