Agentic AI in 2026: what has actually changed

From answers to loops

A chat model is a function. Text goes in, text comes out, and the surrounding program does nothing except display the result. Everything the model can affect is inside its own reply. That is a useful shape for drafting, explaining and summarizing, and it is why the first wave of products were writing tools.

An agent is a loop around that function. The program gives the model a goal and a set of things it may do. The model proposes an action; the program performs it; the result is appended to the conversation; the model is called again. Nothing about the model itself is different. What is different is that its output is now interpreted as an instruction to the world rather than as prose for a person.

goal, tools, budget -> loop:
    state   = history + observations
    action  = model(state, tools)          # a tool call, or "done"
    if action is "done": return answer
    result  = execute(action)              # the only step that touches the world
    history = history + [action, result]
    budget  = budget - cost(action)

Everything interesting follows from that one structural change. Errors compound instead of being visible in a single reply. Latency is the sum of many calls rather than one. Cost is unbounded unless someone bounds it. And a mistake can now be a deleted file rather than a wrong sentence.

Tool use is the load-bearing part

The single largest practical change is that models became reliable at emitting structured calls against a declared schema, and that the surrounding runtimes became good at validating and executing them. A tool is a name, a description, a typed parameter schema and a function. The model never runs code; it writes a request, and the program decides whether to honor it.

{
  "name": "search_orders",
  "description": "Find orders for one customer. Read-only.",
  "parameters": {
    "type": "object",
    "properties": {
      "customer_id": { "type": "string" },
      "since": { "type": "string", "format": "date" }
    },
    "required": ["customer_id"]
  }
}

Tool descriptions are prompt text, and they are read far more often than they are written. Most failures that look like reasoning failures are description failures: two tools whose descriptions overlap, a parameter whose meaning is obvious to the author and ambiguous to everyone else, an error message that says “invalid request” and gives the model nothing to correct. Treat the tool surface as an API designed for a careful but literal reader who cannot ask you a question.

• Give each tool one job, and make the boundary between two tools describable in a sentence.
• Name parameters the way the domain names them, not the way the database column is spelled.
• Return errors that state what was wrong and what a valid value looks like; a model recovers from that and cannot recover from a stack trace.
• Separate read tools from write tools explicitly, so the loop can be run in a read-only mode for testing.
• Keep the tool count small enough that a person can hold it in mind. Large tool sets are usually a sign that a job should be split across several agents with narrower scopes.

A second change is standardization: tool interfaces are increasingly described in a common protocol, so a connector becomes a thing you install rather than a thing you write.

Planning, and how little of it is explicit

Early agent frameworks made planning a separate, visible stage: produce a numbered plan, then execute it step by step. In practice that is brittle. A plan written before the first observation is a guess, and executing a stale guess is worse than reacting to what is actually on the screen.

What works better is interleaving: the model reasons briefly, acts, observes, and revises. The plan exists, but it lives in the conversation rather than in a data structure. Explicit plans still earn their place when a human must approve the work first, and when a task is long enough that the model needs a written record of intent.

Memory is three different problems

“Memory” gets used for three distinct mechanisms with different failure modes. Keeping them apart makes design arguments much shorter.

Longer context windows have made working context less of a daily constraint, but not a free one: attention over a very long context is not uniform, and a model given fifty pages of history will sometimes answer from page two. The discipline is unchanged — put the goal and the constraints where they cannot be crowded out, keep observations terse, and summarize deliberately rather than by truncation.

Evaluation: the part teams skip

The most consistent difference between teams whose agents improve and teams whose agents do not is whether they built an evaluation set before they started tuning prompts. Without one, every change is judged by whether the last demo felt better, which is a measurement with enormous variance and a strong bias toward whoever is talking.

1. Collect real tasks. Twenty to fifty is enough to start, drawn from what users actually asked for, including the requests that went badly.
2. Write a checkable success condition for each one. “The order status was reported and matches the record” is checkable. “The answer was good” is not.
3. Run the whole set on every meaningful change and record pass rate, steps taken, wall-clock time and cost per task.
4. Keep the failures. A regression suite made of past failures is the only thing that stops the same bug returning after a prompt edit.
5. Read transcripts by hand every week. Aggregates say something changed; transcripts say what.

Model-graded evaluation is useful for the parts that resist programmatic checks and dangerous when it is the only signal: judges have preferences, for longer answers and for confident tone. Anchor them with rubrics and human-labeled examples, and never tune against a judge you have not audited.

Guardrails and blast radius

A loop that can act needs limits enforced by the program, not requested in the prompt: instructions are a preference, permissions are a guarantee. The question is not “how do we stop the model doing the wrong thing” but “what is the worst this credential can do, and is that acceptable unattended?”

• Budget every loop: maximum steps, maximum tokens, maximum wall-clock time. An agent that cannot finish should stop, not spin.
• Scope credentials to the task. Read-only by default; write access granted per tool, not per session.
• Require confirmation for actions that are irreversible, cost money, or are visible to other people.
• Treat content the agent reads as untrusted input. Text fetched from a page or a document can contain instructions; the loop must not obey them just because they arrived in the context.

Where agents actually fail

Reading a few hundred failed transcripts is more educational than any benchmark. The same shapes recur.

• Compounding error. Each step is individually plausible and the trajectory drifts. Long tasks fail far more often than the per-step accuracy would suggest.
• Silent success. The agent reports that it did the thing, and it did not. This is the most damaging failure because it is the hardest to notice.
• Loops. The same action is retried with cosmetic variation because the observation never changes.
• Environment drift. The page moved, the record changed, the token expired — and the agent reasons over a snapshot that is no longer true.
• Underspecified goals. Much of what looks like model failure is a request that a careful human would have asked a clarifying question about.

Two have cheap fixes. Silent success is answered by verification: after a write, read it back and compare against the intent. Loops are answered by detection: if the last two observations are identical, stop and escalate.

What to measure

Task success rate is the headline, and it hides the numbers that decide whether a system is usable. Track these together, per task type, and look at the distribution rather than the mean.

Summary

What changed is not that models started to think. It is that they became dependable enough at emitting structured actions to be worth putting inside a loop with real permissions — and that the surrounding engineering caught up enough to make that loop survivable.

So when you next meet a system described as agentic, ask the four questions. What can it do — the action space. How does it decide — the loop and its budget. What does it remember — and which of the three memories is that. How do you know it works — the evaluation set and the transcripts. A system whose owners can answer all four is engineering. A system whose owners can answer none of them is a demonstration.

Further reading

Named rather than linked, on purpose: specifications move and URLs rot, while a title and an author survive a search.

• ReAct: Synergizing Reasoning and Acting in Language Models — Yao et al., the paper that popularized the interleaved reason-act-observe loop.
• Model Context Protocol specification — the open description of how a client exposes tools and resources to a model.
• OpenAI and Anthropic tool-use documentation — the current schema and validation rules for function calling, which change more often than papers do.
• WebArena and Mind2Web — two of the standard environments for measuring agents that act over long horizons.
• OWASP Top 10 for Large Language Model Applications — the working catalogue of injection and privilege risks in this shape of system.