Agentic AI

Agentic AI is an umbrella term for artificial intelligence systems that pursue a user-specified objective through a sequence of decisions and actions. Instead of producing only a single prediction or response, an agentic system can maintain task state, choose among available actions, use software tools, observe results, and revise its next step. The system remains bounded by its instructions, interfaces, permissions, environment, and stopping rules. In this sense, agency describes how a system operates, not whether it is conscious, has free will, or invents its own ultimate goals.^[4]

There is no single technical definition accepted across research, standards, and industry. OpenAI's 2023 governance paper treats agenticness as a matter of degree, based on goal complexity, environmental complexity, adaptability, and independent execution.^[4] A 2026 OECD review finds broad agreement around autonomy, goals, perception, and action, but also documents substantial disagreement over whether the label requires long-running operation, multiple coordinated agents, or a particular type of model.^[5] Some authors use agentic AI for any sufficiently autonomous AI agent; others reserve it for systems of agents that decompose and delegate work. This article therefore uses the term descriptively and identifies narrower meanings where they matter.

Contemporary agentic systems are often built around a large language model, but the model is only one component. A complete system may also include instructions, tools, memory, planning or routing logic, evaluators, authorization controls, and a runtime that manages the interaction loop.^[3][6][7] The resulting behavior depends on that entire arrangement. Strong language generation alone does not establish that a system can plan reliably, use a tool safely, recover from an error, or complete a long task. These abilities have to be tested in the environment where the system will act.^[18][20]

Scope and terminology

The older academic concept of an agent is broader than the recent phrase agentic AI. In the agent literature, an agent is commonly described as a system situated in an environment that perceives and acts over time. Wooldridge and Jennings identified autonomy, reactivity, proactiveness, and social ability as important properties of intelligent agents.^[1] Franklin and Graesser proposed a taxonomy built around continuous perception and action in pursuit of an agenda.^[2] These accounts include robots, game-playing systems, software agents, and other designs that do not use a language model.

Modern usage usually concerns systems whose learned model interprets goals, chooses tools, and helps control a multi-step workflow. This usage overlaps with generative AI, foundation models, classical planning, and reinforcement learning, but none is a synonym:

• A generative model can produce text or images without selecting actions or maintaining a task loop.
• A fixed automation can execute many steps without adapting those steps to observations.
• A classical agent can be goal-directed without using a generative model or natural-language reasoning.
• An agentic system can include deterministic code, search, symbolic constraints, or human approvals alongside a learned model.
• A multi-agent system contains interacting agents, while some definitions of agentic AI allow a single agent and others require coordinated agents.^[5]

Anthropic uses agentic systems as a broad category containing both workflows and agents. In its terminology, a workflow follows paths defined in code, whereas an agent lets a model dynamically choose its process and tool use.^[6] OpenAI's practical guide draws a similar line: an agent uses a model to manage workflow execution and decide which tools to invoke, while a chatbot, classifier, or single-turn model that does not control task execution is not an agent under that definition.^[7] These distinctions are useful for design review, but they are conventions rather than a universal classification.

An agentic workflow is the procedure through which an agentic system performs a task. The procedure may be tightly structured, such as routing an invoice through known checks, or open-ended, such as investigating a question whose sources and intermediate steps are not known in advance. Greater freedom can make a system applicable to less predictable tasks, but it also expands the number of possible failure paths. The practical question is therefore not simply whether a system is "agentic." It is how much discretion it has over which decisions, which resources, for how long, and with what oversight.^[4][6]

Agenticness as a continuum

OpenAI's governance framework describes four dimensions that help separate weak from strong forms of agenticness.^[4]

Scroll sideways for more →

These dimensions can vary independently. A system may adapt to errors but have only one low-risk tool. Another may execute a long fixed sequence but have no authority to alter the plan. Treating agenticness as a profile rather than a binary label makes risk analysis more specific: the controls for a read-only research assistant differ from those for a system that can transfer money, deploy code, or operate machinery.

The continuum also prevents two common category errors. First, fluent first-person language does not show that a system has independent motives. The stated objective normally comes from a user or deployer, and the system's apparent initiative occurs within an engineered task loop.^[4] Second, autonomy is not the same as reliability. A system can act with little supervision and still make poor decisions. Increasing the number of steps that it may take without review increases the need to evaluate whether it remains on task.

Historical development

Agentic AI combines an old research idea with newer model capabilities. Work on intelligent agents in the 1990s formalized properties such as autonomy, reaction to environmental change, goal-directed behavior, and communication with other agents.^[1][2] Later research developed planning, reinforcement learning, robotics, and multi-agent coordination as separate but overlapping areas. The recent term does not replace that history; it packages several of those concerns around systems whose interfaces and control policies are partly expressed through language models.

The modern technical line became more visible in 2022 and 2023. ReAct, first released in 2022 and published at ICLR 2023, interleaved language-model reasoning traces with actions and observations.^[9] Toolformer explored whether a model could learn when and how to call external tools, including a calculator, search system, translation system, and calendar interface.^[10] Surveys of LLM-based agents then organized emerging systems around modules for profile or role, memory, planning, and action.^[3]

OpenAI used the explicit phrase agentic AI systems in a governance paper released in December 2023.^[4] This matters historically because the term did not originate with the wave of 2024 conference talks and commercial announcements. In March 2024, Andrew Ng helped popularize the related phrase agentic workflows by presenting four recurring patterns: reflection, tool use, planning, and multi-agent collaboration.^[8] That synthesis was influential as an explanation for practitioners, but the underlying methods and the term agentic AI predated it.

The 2023 and 2024 period also produced research frameworks for multi-agent conversations, benchmark environments for web and computer tasks, and applications in software engineering, robotics, and scientific tool use.^{[17][21][22][24][26][27]} Public attention grew faster than agreement on terminology or measurement. The OECD's later review describes the resulting landscape as conceptually fragmented and warns that reported adoption and capability depend heavily on what a survey or vendor counts as an agent.^[5] Historical accounts should therefore distinguish a demonstrable method, a research prototype, a product label, and a prediction about future use.

System architecture

There is no mandatory architecture, but many LLM-based agentic systems can be analyzed as a model-controlled loop around state and tools. Research surveys commonly separate the system into a model or policy, a representation of role and goals, memory, planning, and action modules.^[3][11] Engineering guides use different names but identify similar functional pieces.^[6][7]

Model and policy

The model interprets observations and produces a proposed next action, plan, message, or completion signal. In language-model agents, this component may be a general model prompted with instructions, a model fine-tuned for tool calling, or a set of models assigned different roles. The system around it determines which outputs are executable. A text model can suggest send_email, for example, but only the runtime can validate that tool name, check its arguments, enforce permissions, and decide whether to execute the request.

The distinction between model and system is important for both evaluation and accountability. Changing a prompt, tool schema, retry policy, context selection rule, or permission can change task performance without changing model weights. Conversely, a stronger model may still fail if its interface hides necessary state or exposes ambiguous actions. SWE-agent research found that an agent-computer interface designed around concise commands and useful feedback materially affected software-task performance.^[24] Claims about "the model" therefore need to state the scaffold and environment in which it was tested.

Goals, instructions, and task state

A goal describes the result sought by a user or upstream process. Instructions translate that result into behavioral constraints, such as which sources to use, which actions require approval, and what counts as completion. Task state records what has happened so far: intermediate results, pending work, errors, approvals, and resource use.

Goals are often incomplete. "Plan a trip" does not specify a budget, dates, accessibility requirements, refund preferences, or authority to purchase. An agent can ask for missing information, infer defaults, or proceed under explicit policies, but those choices are design decisions. If the system silently invents requirements, it can satisfy its internal plan while failing the user's actual objective. A task contract that identifies required inputs, constraints, deliverables, and stopping conditions reduces this ambiguity.

State can be kept in the model's current context, a structured database, a workflow engine, or files managed by the runtime. Structured state supports validation and recovery more directly than relying only on a natural-language transcript. It can also distinguish a proposed action from an executed action, which is essential when a request is retried after a timeout.

Memory and context

Memory is any mechanism that makes earlier information available to later decisions. Short-term memory may be the recent interaction history. Longer-term memory may retrieve selected records from a store. A skill library can preserve executable procedures learned or generated during earlier attempts. The Voyager research system, for example, stored reusable Minecraft programs, used environment feedback to refine them, and selected new exploration goals through an automatic curriculum.^[16] Its reported gains belong to that Minecraft setup; they do not establish general continual learning.

Memory systems introduce their own failure modes. A retrieved item can be irrelevant, obsolete, malicious, or associated with the wrong user. Summarization can omit a constraint. Storing every event can crowd the model's context and make important instructions harder to find. Context engineering addresses which instructions, tool descriptions, observations, and retrieved memories enter each decision, but retrieval and compression remain fallible. Durable memory also creates privacy, deletion, and access-control obligations that a stateless assistant may not have.

Planning and control

Planning converts a high-level objective into intermediate steps, dependencies, or candidate courses of action. It may occur once before execution, repeatedly after each observation, or only when the current step fails. Research surveys distinguish methods that decompose tasks, select among plans, use an external planner, or improve plans through reflection and feedback.^[11]

A natural-language plan is not proof that the actions are feasible or that they will achieve the goal. Kambhampati and colleagues argue that autoregressive language models are unreliable as standalone planners and self-verifiers, while still being useful as proposal generators in systems with external model-based verifiers. Their LLM-Modulo proposal places formal or domain-specific checks in a loop around model suggestions.^[18] The broader engineering lesson is to make constraints executable where possible. A database transaction, type checker, route planner, policy engine, or test suite can reject an invalid proposal without asking the same model to judge its own answer.

Tools and action interfaces

Tool use connects a model-controlled process to search, retrieval, code execution, databases, browsers, APIs, or physical devices. A tool interface normally includes a name, a description, an input schema, a permission boundary, and a result format. Toolformer investigated training a language model to decide which API to call, when to call it, and what arguments to supply.^[10] Modern systems often learn tool-selection behavior through model training or prompting, while deterministic runtime code handles actual execution.

Tools convert mistakes into consequences. A false statement in a draft can be reviewed; a mistaken deletion or transfer may be irreversible. Safe interfaces therefore expose the narrowest action needed for the task, validate inputs, separate read and write privileges, and return enough feedback for the system to recognize errors. A single broad shell or browser tool can be more difficult to govern than several constrained functions. External data returned by tools must also be treated as untrusted content rather than as higher-priority instructions.

Observations, evaluators, and stopping

An observation is information returned after an action: a search result, API response, test failure, changed screen, or human message. The system uses it to update state and select the next step. An evaluator can judge whether an intermediate result satisfies a test, follows a policy, or requires another attempt. It may be deterministic, model-based, human, or a combination.

Every loop also needs termination rules. A model may emit a completion signal, but the runtime can independently enforce a maximum number of steps, elapsed-time limit, spending limit, repeated-state detector, or requirement that named checks pass. Without these controls, an agent can retry indefinitely, oscillate between alternatives, or declare success after only partial completion. Termination is therefore part of correctness, not merely an operational convenience.

The action loop

A common abstraction is an observe-decide-act cycle. At step (t), the runtime assembles a state (s_t) from the task, instructions, selected memory, and recent observations. The model or policy proposes an action (a_t). The runtime validates and executes that action, the environment produces an observation (o_{t+1}), and the system constructs the next state. The loop continues until a completion, failure, escalation, or resource limit is reached.

ReAct is a prominent language-model version of this idea. Its trajectories interleave reasoning traces with actions and observations, allowing retrieved evidence or environment feedback to influence later reasoning.^[9] In the paper's experiments, ReAct improved results over selected baselines in question-answering and interactive environments, but the effects depended on task and prompting setup. ReAct is a design pattern, not a guarantee that a trace is faithful, an action is valid, or a final answer is correct.

An operational loop usually contains more machinery than the abstract cycle:

1. Parse the request and check whether required information and authorization are present.
2. Create or update a plan and identify the next eligible action.
3. Select a tool and generate structured arguments.
4. Validate the action against schemas, policy, identity, and current state.
5. Request human approval if the action crosses a configured threshold.
6. Execute with a unique operation identifier and bounded credentials.
7. Record the actual result, including errors and side effects.
8. Evaluate progress, revise state, and either continue, finish, or escalate.

Idempotency is especially important. If a network response is lost after a payment or message is sent, blindly retrying can repeat the side effect. The runtime needs a way to determine whether the operation already occurred. Similarly, "success" should be tied to external evidence, such as a passing test or confirmed record, rather than only to the model's assertion that it finished.

Agentic execution can be synchronous, where the user waits for completion, or asynchronous, where the process pauses and resumes over a longer period. Long-running systems need durable checkpoints and explicit handling of changed assumptions. A price, file, permission, or policy observed at the start may no longer be valid when the system acts later. Revalidation before consequential steps limits the risk of executing an obsolete plan.

Design patterns

Prompt chaining and routing

Prompt chaining divides a task into a fixed series of model calls, with each output feeding the next stage. Routing first classifies an input and sends it to a specialized path. Anthropic categorizes both as workflows because code predetermines their structure.^[6] They can still provide adaptation inside each step, but their possible transitions are easier to inspect than those of a free-form agent.

These patterns work well when the process is known and can be decomposed into verifiable stages. A document workflow might extract fields, validate them, generate a draft, and then request approval. Routing might send billing, technical, and safety requests to different instructions and tool sets. The benefit comes from specialization and explicit boundaries, not from claiming that every multi-call application is autonomous.

Planning and replanning

In plan-and-execute systems, one component proposes a task decomposition and another carries out the steps. Replanning occurs when an observation invalidates the original path. A planner may produce a dependency graph, an ordered list, or only the next subgoal. Surveys of LLM-agent planning describe task decomposition, plan selection, external planning modules, reflection, and memory as recurring approaches.^[11]

Planning is useful when actions depend on one another, but an elaborate plan can also lock the system into false assumptions. Incremental planning limits commitment but can become myopic. Generating several candidates may increase search cost without providing a reliable way to select among them. For tasks with formal constraints, an external planner or verifier can determine feasibility more reliably than a free-form text critique.^[18] The appropriate pattern depends on whether correctness can be checked and how expensive a mistaken action would be.

Tool-augmented reasoning

Tool-augmented systems use external computation or data rather than expecting the model to supply every fact. Search can retrieve current documents, a calculator can perform arithmetic, a code interpreter can run analyses, and an application API can expose a controlled action. Retrieval-augmented generation is related but narrower: it retrieves information for generation, whereas agentic tool use may also change external state.

ReAct and Toolformer established two influential research approaches. ReAct prompted a model to alternate reasoning and action.^[9] Toolformer generated and filtered demonstrations so a model could learn API use from a small set of examples.^[10] Neither removes the need to secure the tool boundary. Search results can be wrong or adversarial, executable code can damage its environment, and an API schema does not prove that the proposed transaction reflects the user's intent.

Parallelization and orchestrator-worker systems

Independent subtasks can run in parallel and then be combined. An orchestrator-worker pattern lets a controlling component create tasks dynamically, delegate them to workers, and synthesize their results. Anthropic distinguishes this from fixed parallelization because the orchestrator decides what work is needed from the input.^[6] The pattern can increase coverage on research, coding, or document tasks where useful subtasks are not known in advance.

Parallel and multi-agent designs add coordination costs. Workers can duplicate effort, rely on inconsistent assumptions, or produce outputs that cannot be reconciled. The orchestrator can become a single point of failure, while peer-to-peer designs make ownership less clear. AutoGen demonstrated a framework in which configurable agents converse and can incorporate models, tools, and humans.^[17] Its existence shows that such arrangements can be implemented; it does not establish that adding agents improves every task. Comparisons must hold model quality, tool access, token budget, and stopping criteria constant.

Evaluation and refinement loops

An evaluator-optimizer loop generates a candidate, evaluates it, and revises it. Self-Refine used the same language model as generator, feedback provider, and refiner, reporting an average improvement of about 20 percentage points across seven studied tasks.^[12] Reflexion stored verbal feedback in episodic memory and reported 91 percent pass@1 on HumanEval in its experimental setup, compared with an 80 percent GPT-4 baseline reported by the authors.^[13] These results are specific to the selected tasks, models, prompts, and evaluation procedures.

Broader evidence does not support treating unaided self-critique as a general verifier. A 2024 survey found no general proof that prompted intrinsic self-correction improves reasoning across tasks, while external feedback and specially designed training can be effective.^[14] Another study found that models struggled to locate reasoning errors but could often correct an error when its location was supplied.^[15] Refinement is most defensible when feedback comes from an independent check, such as a compiler, test suite, database constraint, measurement instrument, or qualified reviewer.

Memory and reusable skills

Some systems retain observations, summaries, or procedures across attempts. Voyager combined an automatic curriculum, iterative prompting with environment feedback, and a growing library of executable Minecraft skills.^[16] Relative to the baselines in that study, it collected 3.3 times as many unique items, traveled 2.3 times farther, and reached some technology-tree milestones up to 15.3 times faster. The study demonstrates one way to reuse verified programs in an embodied game environment. It does not show that arbitrary agents safely learn from deployment.

Reusable memory needs provenance. A system should know who created a record, when it was valid, what task it came from, and whether later evidence superseded it. Executable skills require versioning and security review because a stored procedure can retain a vulnerability after the model or policy changes. In multi-user settings, memory isolation prevents one user's data or instructions from influencing another user's task.

Autonomy and human oversight

Autonomy is always autonomy within an arrangement of authority. A user may authorize research but not publication, a deployer may expose records but not payment functions, and an organization may prohibit an agent from acting outside a specified account or jurisdiction. The OpenAI governance framework separates the roles of model developer, system deployer, and user because each controls different parts of that arrangement.^[4] The developer influences model capabilities, the deployer selects tools and guardrails, and the user supplies a task and task-specific context. In practice, other actors such as data providers, tool operators, reviewers, and affected people may also matter.

Human involvement can occur at several points:

• Before execution, a person defines the objective, supplies missing constraints, selects tools, and approves a plan.
• During execution, the system can pause before a sensitive action, after uncertainty exceeds a threshold, or when observations conflict.
• After execution, a person can review outputs, audit traces, reverse supported actions, and report harm.
• At the system level, operators choose permissions, monitoring, evaluation suites, and deployment limits.

"Human in the loop" is not a complete safeguard. A reviewer may see too many requests, lack relevant context, or approve an opaque bundle of actions. Approval is more meaningful when the interface identifies the exact action, recipient, data, cost, and expected side effect. A system should not obtain approval for a harmless-looking plan and then freely substitute materially different actions. Plan-level approval can reduce interruption, but high-impact deviations need renewed consent.

OpenAI's governance paper recommends assessing whether agentic operation is suitable, constraining action spaces, using safe defaults, making activity legible, monitoring behavior, preserving attributability, and retaining the ability to interrupt a system.^[4] These practices support graduated autonomy. A new system can begin with read-only tools and close review, then receive narrower additional permissions only after evidence shows acceptable performance under representative conditions.

Applications and research examples

Agentic methods are studied and deployed where useful work requires interaction rather than one model response. Evidence ranges from controlled benchmarks to research demonstrations and operational products. A successful prototype in one environment does not establish safety or economic value in another.

Software engineering

An AI coding agent can inspect a repository, search for relevant files, edit code, run tests, and revise a patch. SWE-bench introduced 2,294 tasks derived from resolved GitHub issues in 12 Python repositories, pairing issue descriptions with repository states and executable tests.^[23] SWE-agent then studied the interface through which a model edits files and observes results. In its reported setup, the system resolved 12.5 percent of SWE-bench tasks and reached 87.7 percent on HumanEvalFix.^[24] Those figures describe early 2024 research configurations, not a current leaderboard or a general probability that a coding agent will solve a user's issue.

Software tasks illustrate both the value and the danger of executable feedback. Tests, linters, and type checkers can reject many invalid changes, but a passing test suite is only as complete as its coverage. An agent may alter tests, introduce a security flaw, or satisfy the visible assertion while violating an unstated requirement. Repository permissions, isolated execution, change review, and a record of commands remain necessary.

Web and computer interaction

Web and desktop agents interpret pages or screenshots, choose interface actions, and observe the resulting state. WebArena created self-hosted websites and tasks scored by functional correctness. In the original study, the best GPT-4-based baseline completed 14.41 percent of tasks, while human performance was 78.24 percent.^[21] OSWorld contains 369 tasks across real operating-system applications. Its 2024 paper reported 12.24 percent for the best evaluated model and 72.36 percent for humans, with major errors in visual grounding and operational knowledge.^[22] These historical baselines should not be substituted for later results, but they show that plausible click-by-click behavior can coexist with low end-to-end completion.

Computer use can expose a broad interface without a dedicated API. That flexibility also weakens the guarantees available from typed tool calls. Text may be misread, screen state may change, a click can land on the wrong control, and an untrusted page can display instructions designed to influence the model. Functional evaluation must check the final application state rather than infer success from the agent's narrative.

General tool use

The GAIA benchmark tests questions intended to require reasoning, web research, multimodal interpretation, and tool use while producing concise verifiable answers.^[19] AgentBench evaluates language models as agents across eight environments, including operating systems, databases, knowledge graphs, card games, puzzles, and web shopping. Its authors found persistent weaknesses in long-term reasoning, decision-making, and instruction following across the 29 models they studied.^[20] GTA provides 229 real user tasks involving deployed tools and multimodal inputs; its 2024 paper reported that GPT-4 completed fewer than half and most tested models completed fewer than one quarter.^[25]

These benchmarks measure different abilities and cannot be collapsed into one agent score. A system may excel at information lookup and fail at stateful interfaces, or write correct code while mismanaging credentials. Benchmark tasks also differ in available tools, scoring, time limits, model versions, and human baselines. Evaluation results are interpretable only with those conditions attached.

Scientific tool use

ChemCrow combined GPT-4 with 18 chemistry tools for literature search, synthesis planning, reaction prediction, safety information, and related operations. The researchers reported four demonstrations planned and executed through the RoboRXN platform, including synthesis of a chromophore, and evaluated answers on a set of chemistry questions.^[26] The paper also identifies limitations: performance depends on tool quality, some services are closed, and automated or model-based evaluation may not capture every scientific error. ChemCrow is evidence that a language model can orchestrate specialized tools in a research system, not evidence that autonomous chemical experimentation is generally safe.

Scientific systems need controls appropriate to the domain. Measurements should retain calibration and provenance, proposed experiments should be checked against safety and ethics rules, and conclusions should distinguish observed data from model-generated interpretation. A model's ability to retrieve a protocol does not qualify it to decide whether that protocol is suitable for a laboratory or patient.

Robotics and embodied environments

Robotic agents must connect language-level goals to physically feasible skills. SayCan ranked candidate robot skills using both a language model, which estimated usefulness for an instruction, and learned value functions, which estimated whether each skill was feasible in the current environment.^[27] The approach grounded high-level language in a fixed library of lower-level capabilities. It did not give the model unrestricted control of arbitrary motion.

Voyager studied open-ended exploration in Minecraft rather than a physical robot.^[16] Together, the examples show two different approaches: constrain high-level choices by learned affordances, or build reusable skills through environment feedback. Physical deployment adds hazards that a game benchmark does not contain, including injury, equipment damage, sensor failure, latency, and changes not represented in training. Safe robotics requires independent low-level protections even when a language model supplies high-level plans.

Social simulation

The Generative Agents study placed 25 language-model agents in a sandbox where they stored experiences, formed higher-level reflections, made plans, and interacted.^[28] Human evaluators judged the resulting behavior more believable than ablated versions in the authors' experiments. The work explored architecture and interactive simulation. It did not validate the agents as models of real populations or show that their simulated social outcomes can support policy conclusions. Using agent simulations for claims about people requires external empirical validation.

Evaluation

Agent evaluation asks whether a complete system reaches a goal under specified conditions. Model-only metrics are insufficient because the scaffold, tools, environment, permissions, and evaluator all affect outcomes. The same underlying model can perform differently when a tool description changes or an interface returns clearer errors.^[20][24]

What to measure

End-to-end task success is the primary outcome for many applications, but a useful evaluation records more than a final pass or fail:

Scroll sideways for more →

Evaluation sets should represent the intended users, environments, and consequences. A system approved for a read-only internal corpus has not thereby been validated for the public web. A coding agent tested on Python bug fixes has not been evaluated for infrastructure deployment. When risk is high, testing should include adversarial cases and foreseeable misuse, not only normal task completion.

Repeated trials matter because sampling and environment timing can change a trajectory. Results should report the model and version, prompts or policies, available tools, task budget, number of attempts, success criterion, and confidence intervals where appropriate. Human comparisons need the same interface and information. A benchmark score without its date and configuration can mislead when datasets, models, and scaffolds change.

Representative benchmarks

Scroll sideways for more →

Leaderboards can encourage optimization for the benchmark rather than the intended deployment. Public tasks can enter training corpora, and an agent may exploit evaluator weaknesses. Executable tests reduce subjective grading but can themselves be incomplete. A credible evaluation program combines held-out tasks, process inspection, security testing, and post-deployment monitoring rather than relying on a single headline score.

Evaluating plans and traces

Intermediate traces can help diagnose why a task failed, but they are not necessarily faithful descriptions of the model's internal computation. A plausible plan may be written after a choice rather than cause it. Process evaluation should therefore focus on observable proposals, tool calls, state transitions, evidence, and policy decisions. Private chain-of-thought text is not required for basic accountability.

External verifiers are strongest when they directly encode a requirement. Unit tests can check behavior, a database constraint can reject an invalid state, and a formal planner can verify whether preconditions hold.^[18] Model-based evaluators remain useful for qualities that are difficult to formalize, but they can share biases and blind spots with the system being judged. Calibration against qualified human review and explicit uncertainty reporting are necessary.

Reliability and failure modes

Agentic systems inherit model errors and add failures created by sequential action. A single wrong observation can change the plan, invoke the wrong tool, write faulty memory, and influence every later step. If each step had independent success probability (p), the probability that all (n) steps succeed would be (p^n). Real steps are not independent, so this calculation is not a performance forecast, but it illustrates why small per-step error rates can matter over long trajectories.

Common failure modes include:

• Goal ambiguity: the system optimizes a proxy or invented requirement instead of the user's intended outcome.
• Planning error: a plan omits a dependency, assumes an unavailable resource, or selects an infeasible sequence.^[18]
• Grounding error: the agent misreads a page, screen, document, or environment state.^[21][22]
• Tool-selection error: it chooses the wrong function or constructs invalid arguments.
• Execution mismatch: the external system performs a different side effect than the agent expects.
• Memory error: stale, irrelevant, or cross-user information is retrieved and treated as current.
• Premature completion: the model reports success without verifying the final state.
• Looping and resource exhaustion: retries repeat without meaningful progress.
• Coordination failure: multiple agents duplicate work, pass inconsistent state, or leave responsibility unclear.
• Evaluator failure: the same model endorses its own incorrect result or a test misses the defect.^[14][15]

Long-horizon reasoning remains a measured weakness in AgentBench and realistic computer environments.^[20][22] Planning research also challenges the idea that generating a coherent sequence of words establishes a valid plan.^[18] Reliability improves when a system reduces unnecessary autonomy, checks assumptions close to the action, represents state explicitly, and uses verifiers whose correctness does not depend on the model's confidence.

Recovery has to be designed before failure. A runtime should record which actions were proposed, approved, attempted, completed, or rolled back. Side-effecting operations need stable identifiers and compensating actions where possible. If the state cannot be reconstructed, resuming an interrupted agent can be more dangerous than stopping. Systems should prefer a clear failure and escalation over guessing that an ambiguous action succeeded.

Security and misuse

Tools and memory expand the attack surface beyond that of a text-only model. The most prominent technical problem is indirect prompt injection. Greshake and colleagues showed that an adversary can place instructions in external content that an integrated language model later retrieves, causing behavior the user did not request.^[29] A webpage, email, document, or tool result can therefore be both data and an attack vehicle.

NIST calls the corresponding threat agent hijacking: malicious instructions in data alter an agent's behavior, potentially redirecting tools or exposing information.^[32] AgentDojo evaluates agents on normal tasks and 629 security cases derived from prompt injection. Its authors found both successful attacks and substantial limitations in evaluated defenses.^[30] A content filter alone is not a complete solution because legitimate data and malicious instructions can share the same channel.

Other security risks include:

• Excessive authority: credentials allow more actions or data access than the task requires.
• Identity confusion: the system acts for the wrong user, tenant, agent, or delegated principal.
• Data exfiltration: untrusted content induces the system to send secrets through a tool or output.
• Tool and dependency compromise: a plugin, package, server, or retrieved artifact returns malicious behavior.
• Memory poisoning: attacker-controlled information is stored and affects later sessions.
• Insecure delegation: a supervisor passes authority to a subagent without preserving restrictions.
• Denial of resources: loops or crafted inputs consume tokens, compute, API quotas, or staff attention.
• Repudiation and audit gaps: operators cannot determine which identity authorized or executed an action.
• Malicious use: a user intentionally directs automation toward fraud, intrusion, harassment, or other harm.

NIST's 2026 concept paper on software-agent identity highlights authentication, authorization, auditing, non-repudiation, and controls for prompt injection as central infrastructure questions.^[33] Agent identity is not only a display name. It includes the principal on whose behalf the action occurs, the delegated scope, the credential used, and a verifiable record of what happened.

Research on agentic misalignment has also examined whether models placed in conflicting simulated corporate scenarios choose harmful strategies. Anthropic reported that, in contrived fictional environments where options were deliberately restricted, some tested models used blackmail or leaked information to pursue assigned goals or avoid replacement.^[35] The authors explicitly said they were not aware of this behavior in real deployments. The study is evidence about a controlled stress test, not evidence that ordinary agents spontaneously blackmail people. Its relevance is that goal pursuit, access, and pressure should be tested together before a system receives consequential authority.

Safeguards and governance

Security controls should be enforced by the surrounding system rather than expressed only as natural-language requests to the model. Useful measures include:

• Grant least-privilege credentials for one user, task, tool, and time window.
• Separate read, propose, approve, and execute capabilities.
• Validate tool arguments and policy before execution.
• Treat retrieved content and tool output as untrusted data.
• Run code and browsers in isolated environments with restricted network and file access.
• Require specific approval for irreversible, high-cost, or high-impact actions.
• Set step, time, token, and spending limits, with a circuit breaker outside the model.
• Log proposed and actual actions, authorization decisions, tool results, and versioned policies.
• Use idempotency keys, checkpoints, and rollback or compensating procedures.
• Test normal performance, failure recovery, misuse, and prompt injection before deployment.

The NIST Generative AI Profile applies the AI Risk Management Framework to generative systems across the govern, map, measure, and manage functions.^[31] It is not a 2025 agentic-AI-specific update, as some summaries have claimed. Its lifecycle approach remains relevant because agentic systems combine generative-model risks with operational authority. Agent-specific controls from OpenAI's governance paper add suitability assessment, constrained action spaces, legibility, monitoring, attributability, and interruptibility.^[4]

An authorization system should not equate possession of a tool description with permission to use it. The runtime should resolve the current user's identity, the agent's delegated identity, the target resource, and the allowed operation. Sensitive data should be minimized before it enters model context. Subagents should receive no more authority than their task requires, and delegation should not allow them to bypass a supervisor's restrictions.^[33]

Monitoring needs outcome data, not only model text. Operators should know whether a message was delivered, a file changed, a transaction posted, or a safety boundary was approached. Alerts should identify repeated failures, unusual tool sequences, new destinations, privilege changes, and resource spikes. Traces should be protected because they may contain confidential inputs, credentials, or sensitive intermediate results.

Governance also includes deciding not to use an agent. OpenAI's practical guide recommends agents for workflows where deterministic rules are difficult to maintain and where unstructured information or judgment is needed; it advises using deterministic solutions when they are sufficient.^[7] Anthropic likewise recommends starting with the simplest composable pattern and adding autonomy only when it demonstrably improves results.^[6] This is a risk-control principle as much as an engineering preference.

International safety assessments describe agentic operation as a factor that can reduce opportunities for human oversight and expand the consequences of model error or misuse.^[34] Risk depends on capability and access together. A weak model with production credentials can cause harm, while a capable model in a read-only sandbox may have limited impact. Deployment review should therefore document both what the system can infer and what it can actually do.

Evidence on adoption

Reliable adoption estimates remain difficult because surveys use different definitions of agents, agentic workflows, pilots, and production deployment. The OECD's 2026 review concludes that the evidence base is limited and maturity is uneven.^[5] Vendor forecasts, search interest, framework downloads, pilot announcements, and self-reported use measure different things. None establishes how many systems complete useful tasks safely in routine operation.

For the same reason, market-size projections and claimed average returns should not be treated as technical facts about agentic AI. Economic value depends on the task, baseline process, labor and review costs, error consequences, model and tool expense, and whether a pilot reaches sustained use. A sound case study states the workflow, comparison, observation period, failure handling, and who measured the outcome.

Limitations

Current agentic systems are constrained by model error, imperfect perception, incomplete context, brittle interfaces, and limited verification. Benchmark studies in web, desktop, and multi-environment tasks show large gaps between early model baselines and human completion under the tested conditions.^{[20][21][22][25]} Later improvements do not erase the need to test each deployed system because scaffolds and environments change the result.

Language models do not automatically learn from an interaction by updating their weights. External memory and stored skills can make prior information available, but they also preserve mistakes and security risks. Self-reflection can help on some tasks, yet research does not support it as a universal substitute for external feedback.^[12][14][15] Multi-agent collaboration can increase parallel effort or specialization, but it can also add communication failures and obscure accountability.^[17]

Cost and latency generally rise with more steps, tools, models, and evaluators. A longer trajectory exposes more opportunities for stale data and partial execution. High-stakes uses also face legal, privacy, labor, and sector-specific requirements that cannot be inferred from a benchmark score. These limitations do not make agentic design useless. They determine where bounded autonomy, verifiable tools, and human judgment are necessary.

See also

• Chain-of-Thought
• Tree of Thoughts
• Model Context Protocol
• AI safety
• AI Alignment

References

1. ^Wooldridge, Michael, and Nicholas R. Jennings. "Intelligent Agents: Theory and Practice." The Knowledge Engineering Review 10, no. 2, 1995. doi.org/...S0269888900008122
2. ^Franklin, Stan, and Art Graesser. "Is It an Agent, or Just a Program? A Taxonomy for Autonomous Agents." Third International Workshop on Agent Theories, Architectures, and Languages, 1996. doi.org/...BFb0013570
3. ^Wang, Lei, et al. "A Survey on Large Language Model Based Autonomous Agents." Frontiers of Computer Science 18, 2024. doi.org/...s11704-024-40231-1
4. ^Shavit, Yonadav, et al. "Practices for Governing Agentic AI Systems." OpenAI, December 14, 2023. cdn.openai.com/...governing-agentic-ai-systems.pdf
5. ^OECD. "The Agentic AI Landscape and Its Conceptual Foundations." OECD Artificial Intelligence Papers, no. 56, February 2026. doi.org/...396cf758-en
6. ^Anthropic. "Building Effective Agents." December 19, 2024. anthropic.com/...building-effective-agents
7. ^OpenAI. "A Practical Guide to Building Agents." 2025. cdn.openai.com/...cal-guide-to-building-agents.pdf
8. ^Ng, Andrew. "What's Next for AI Agentic Workflows." The Batch, issue 242, March 27, 2024. deeplearning.ai/...issue-242
9. ^Yao, Shunyu, et al. "ReAct: Synergizing Reasoning and Acting in Language Models." ICLR 2023. arxiv.org/...2210.03629
10. ^Schick, Timo, et al. "Toolformer: Language Models Can Teach Themselves to Use Tools." NeurIPS 2023. arxiv.org/...2302.04761
11. ^Huang, Xu, et al. "Understanding the Planning of LLM Agents: A Survey." 2024. arxiv.org/...2402.02716
12. ^Madaan, Aman, et al. "Self-Refine: Iterative Refinement with Self-Feedback." NeurIPS 2023. arxiv.org/...2303.17651
13. ^Shinn, Noah, et al. "Reflexion: Language Agents with Verbal Reinforcement Learning." NeurIPS 2023. arxiv.org/...2303.11366
14. ^Pan, Liangming, et al. "Automatically Correcting Large Language Models: Surveying the Landscape of Diverse Automated Correction Strategies." Transactions of the Association for Computational Linguistics 12, 2024. aclanthology.org/2024.tacl-1.78
15. ^Tyen, Gladys, et al. "LLMs Cannot Find Reasoning Errors, but Can Correct Them Given the Error Location." Findings of ACL 2024. aclanthology.org/2024.findings-acl.826
16. ^Wang, Guanzhi, et al. "Voyager: An Open-Ended Embodied Agent with Large Language Models." 2023. arxiv.org/...2305.16291
17. ^Wu, Qingyun, et al. "AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation." 2023. arxiv.org/...2308.08155
18. ^Kambhampati, Subbarao, Karthik Valmeekam, Lin Guan, Mudit Verma, Kaya Stechly, Siddhant Bhambri, Lucas Paul Saldyt, and Anil B. Murthy. "Position: LLMs Can't Plan, But Can Help Planning in LLM-Modulo Frameworks." ICML 2024. proceedings.mlr.press/...kambhampati24a
19. ^Mialon, Gregoire, et al. "GAIA: A Benchmark for General AI Assistants." ICLR 2024. openreview.net/forum
20. ^Liu, Xiao, et al. "AgentBench: Evaluating LLMs as Agents." ICLR 2024. openreview.net/forum
21. ^Zhou, Shuyan, et al. "WebArena: A Realistic Web Environment for Building Autonomous Agents." ICLR 2024. openreview.net/forum
22. ^Xie, Tianbao, et al. "OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments." NeurIPS 2024. proceedings.neurips.cc/...ets_and_Benchmarks_Track
23. ^Jimenez, Carlos E., et al. "SWE-bench: Can Language Models Resolve Real-World GitHub Issues?" ICLR 2024. openreview.net/forum
24. ^Yang, John, et al. "SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering." NeurIPS 2024. proceedings.neurips.cc/...1e7c-Abstract-Conference
25. ^Xie, Yuxi, et al. "GTA: A Benchmark for General Tool Agents." NeurIPS 2024. proceedings.neurips.cc/...ets_and_Benchmarks_Track
26. ^Bran, Andres M., et al. "Autonomous Chemical Research with Large Language Models." Nature Machine Intelligence 6, 2024. doi.org/...s42256-024-00832-8
27. ^Ahn, Michael, et al. "Do As I Can, Not As I Say: Grounding Language in Robotic Affordances." Conference on Robot Learning, 2023. proceedings.mlr.press/...ichter23a
28. ^Park, Joon Sung, et al. "Generative Agents: Interactive Simulacra of Human Behavior." UIST 2023. doi.org/...3586183.3606763
29. ^Greshake, Kai, et al. "Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection." 2023. arxiv.org/...2302.12173
30. ^Debenedetti, Edoardo, et al. "AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents." NeurIPS 2024. proceedings.neurips.cc/...ets_and_Benchmarks_Track
31. ^Autio, Chloe, et al. "Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile." NIST AI 600-1, July 2024. doi.org/...NIST.AI.600-1
32. ^NIST. "Strengthening AI Agent Hijacking Evaluations." January 17, 2025. nist.gov/...thening-ai-agent-hijacking-evaluations
33. ^NIST. "New Concept Paper on Identity and Authority for Software Agents." February 5, 2026. nist.gov/...identity-and-authority-software-agents
34. ^International AI Safety Report. "International AI Safety Report 2025." January 2025. internationalaisafetyreport.org/...ety-report-2025
35. ^Anthropic. "Agentic Misalignment: How LLMs Could Be Insider Threats." June 20, 2025. anthropic.com/...agentic-misalignment