What an AI Agent Actually Is, and What It Is Not

The loop is the whole idea

Strip away the vocabulary and an agent is a program with a model inside a while-loop. The model receives a goal and the current state of the world. It emits either a final answer or a request to use a tool: read this file, run this query, send a request to this endpoint, execute this test. Something outside the model actually performs that action — the model does not touch anything itself — and the result comes back as new input. Then it decides again. It stops when it judges the goal met, or when a limit is hit.

Everything people call agentic behaviour follows from that structure. Planning is the model writing down an intended sequence before it spends real steps on it. Tool use is the escape hatch from a system that would otherwise only produce prose. Execution is the harness doing what the model asked. Verification is running something that can disagree with the model — a test suite, a type checker, a re-read of the record from the database, a second model holding the original requirements with no attachment to the work.

The critical property is not that the model is clever. It is that the loop is closed. A model asked to write a script in one shot has no idea whether the script runs. The same model in a loop can run it, read the traceback, and edit the line that caused the error. That is a capability of a different kind, and it comes from the environment handing back what actually happened, not from any improvement in the weights.

Why the word stopped meaning anything

The word is applied loosely because it sells and nobody owns the definition. A chatbot with a system prompt telling it to be proactive is not an agent. A single call that returns structured JSON your code then acts on is not an agent — that is your program with a model as a subroutine. A fixed pipeline where step one always feeds step two is a workflow; useful, often the correct design, but the sequence was decided by a developer, not at runtime.

The test that matters is whether the number and order of the remaining steps can change at runtime. If they cannot, an agent buys you nothing and costs you determinism. If the model can decide, after seeing an error, that it needs three more steps nobody anticipated, that is an agent. The difference is practical rather than semantic. Workflows are cheaper, faster, easier to test, and they fail predictably. Agents earn their keep only when the path genuinely cannot be enumerated ahead of time.

How agents actually fail

The dominant failure is compounding error over long horizons. Independent steps that each succeed with probability p succeed together with probability p to the power of n. Even at a generous 95% per step, twenty steps land near a third. The arithmetic is crude — real steps are neither independent nor equally risky — but the direction is right, and it explains the pattern everyone reports: agents look excellent on five-step tasks and unreliable on fifty-step ones. Extending the horizon requires higher per-step reliability, or checkpoints that stop an error propagating.

Worse than a step that fails is a step that fails silently. An agent that writes to the wrong path, searches the wrong directory and reads zero matches as "no problems found", runs a command whose stderr the harness never showed it, or receives a 200 response whose body carries an error message, carries that false belief forward and builds on it. Everything after is confidently wrong. Long runs are also where context management starts to hurt: earlier decisions get summarised or evicted, and the agent redoes work it already completed, or contradicts a constraint it agreed to twenty steps ago.

Then there is the model's own optimism. Asked whether it finished, a model will usually say yes. Self-assessment without external evidence is close to worthless — it is the same system that produced the work, grading the work, with no independent view of it. This is why an agent will announce that it fixed the bug and that the tests pass, when it never ran them. Add the adversarial case: an agent that reads web pages, tickets, or emails is reading text that may contain instructions aimed at it. Content pulled from the world is data, not orders, and a system that cannot hold that distinction is a system whose behaviour an attacker can steer.

Why verification matters more than the plan

The bet worth making is that verification buys more than planning does, and the reason is structural. A plan is a prediction about a world the agent has not observed yet; it is wrong the moment the first tool call returns something unexpected. Verification operates on what actually happened. It is the thing that lets an agent notice it is off course at step four instead of step forty. This is a position rather than a settled result — decomposition and plan-then-act scaffolds do help on some tasks and not others — but it is where the engineering leverage sits.

It also explains why agents fare so unevenly across domains today. Software engineering is the best-served field not because code is easy but because it is checkable: the compiler answers one narrow question honestly, thousands of times, for almost nothing. It will not tell you the code is correct, only that it is well-formed and type-consistent, and code that compiles and is wrong is the normal case. Even that much is more feedback than most domains offer. Test suites, type systems, linters, and scripts you can safely run twice all give the loop something honest to react to. Data work with reconciliations that must balance, and browser tasks that end in an observable state change, share the quality.

The domains where agents disappoint share the opposite one. Draft me a strategy, research this market, write a policy brief — there is no oracle. The failure mode is not a crash; it is plausible output nobody can cheaply confirm, which is the most expensive kind of wrong. Before deploying an agent on anything, ask what would tell you it failed and how much that check costs. If the answer is that a person must read everything carefully, you have not automated the work — you have moved it from doing to reviewing, and review may well be the more expensive half.

What the human keeps

Three controls are not negotiable. First, approval before anything irreversible. Reads, drafts, and sandboxed runs can proceed freely; sending mail, deleting data, moving money, deploying, or writing to production should stop and ask. The imbalance between the two sides is the whole point: a wasted read costs a fraction of a cent, a wrong send cannot be recalled. Second, a visible plan and a visible trace — which tools were called, with what arguments, and what came back. A run you cannot inspect is a run you cannot debug, and the summary an agent writes of its own work is not a substitute for the log. Third, the ability to stop mid-run and have stopping mean something: no half-applied migration, no orphaned branch, no partially sent batch.

Cost and latency are not footnotes either. An agent that works a problem for five minutes may consume tens of model calls, each carrying a context that grows as the run does. A single answer might cost a fraction of a cent; a long agentic run can cost dollars, and the elapsed time on the clock has its own price. The trade is worth it when the task would genuinely take a person an hour. It is a bad trade when a direct answer would have done, and "give me the answer, I'll act on it myself" remains the sounder design in far more cases than the current enthusiasm suggests.

MentronX works on both ends of this problem — Firas AI answers, Firas Agent runs the loop — and the honest thing to say is that the second is the harder engineering problem by a wide margin, mostly because of verification and control, which are engineering problems on top of an unsolved reasoning problem rather than instead of it.