AI Agent

AI agent (artificial intelligence agent) is a goal-directed software system that uses artificial intelligence to interpret information, choose actions and interact with an environment in pursuit of a defined objective. An agent can examine a request or event, decide what to do next, use permitted software tools, inspect the results and change its course when conditions change. The degree of independence varies: some agents only recommend actions, while others are authorized to perform limited operations without case-by-case human approval. An AI agent is therefore identified by its goal-directed behavior and interaction with an environment, rather than by a particular model, interface or level of autonomy.

In everyday use, an AI agent might inspect an incoming service request, retrieve relevant records, identify the next permissible action and update a ticket or ask a person for authorization. Modern agents often use a large language model for interpreting instructions and selecting tools, but an agent need not be based on a language model; earlier and specialized agent systems can use rules, planning algorithms, learned policies or combinations of methods. A conversational chatbot that only answers a question is not necessarily an agent, and a language model by itself has no inherent permission to modify business systems.

An agent's ability to propose or execute a step must be distinguished from its authority to do so. The surrounding application determines available tools, access rights, approval requirements, action limits, monitoring and stopping conditions. These controls are essential because the same model output can be harmless as a suggestion but consequential when connected to production applications, financial records or physical equipment. The term agentic AI is often used for this broader class of systems and operating patterns; it is not a universally standardized synonym for any one kind of agent.

Meaning and defining characteristics

An agent is generally described in relation to a goal, an environment and actions. Its environment may be a software application, a collection of enterprise systems, a simulated task environment or a physical setting. A goal describes the desired outcome; observations tell the agent what is happening; actions affect the environment or provide information to someone who can act. This vocabulary is also found in older artificial intelligence research. Recent LLM-based agents add flexible language interpretation and tool selection, but the basic agent concept is wider than generative AI.

Six characteristics help identify an AI agent in practice:

• Goal orientation: it works toward a specified task or outcome, rather than only calculating a single answer with no subsequent operating objective.
• Perception or observation: it receives information from users, applications, sensors, documents or other tools about the state of its environment.
• Selection of actions: it determines a next step using rules, a plan, a learned policy or model-based judgment. The selection method depends on the agent design.
• Ability to act: it can invoke a tool, submit a proposed operation, navigate an interface, call another service or otherwise affect the task environment, subject to permissions.
• Feedback and adjustment: it can incorporate tool results or changing conditions before deciding what to do next; this does not necessarily mean its model weights are retrained.
• Bounded operation: a usable deployed agent has defined limits, completion criteria, exception handling and an accountable owner, even when it performs some steps independently.

These characteristics do not imply a human-like mind. Words such as reasoning, memory and planning describe functional system behavior and computational mechanisms, not proof of human understanding or consciousness. An agent may also be deliberately narrow: an effective incident-triage agent might operate within a single approved workflow and have no authority outside that service.

What makes an AI agent different from an AI model?

A model processes inputs and produces outputs, such as a probability, ranking, text response or proposed tool call. An agent combines model or rule-based capabilities with objectives, operational state, interfaces and an execution mechanism. The agent system decides whether and how a model output is used. For example, identifying a possible duplicate invoice is a model or analytic function; checking records, assembling evidence and placing the invoice in a permitted review queue is an agent-supported workflow. The organization still determines whether any payment can be released.

This is a useful distinction for enterprise architecture: the model may be supplied by one vendor, while the agent's tools, authorization checks, data sources, workflow integration and audit trail belong to other components. Model quality is necessary for many modern agents but is not sufficient to establish safe or successful business operation.

How an AI agent works

A typical agent operates as an iterative observe-decide-act cycle. It starts with a goal and a set of permitted capabilities, obtains information, chooses a next action, observes the resulting state and repeats until it reaches a completion or stopping condition. An LLM-based agent may use the model at several decision points to interpret information and select tools. The ReAct research approach, published at ICLR 2023, illustrated how reasoning-related steps and externally observable actions can be interleaved in language-model systems.

A representative operating cycle consists of the following functions, though implementations differ:

1. Receive the goal and scope. The agent obtains the task, intended result, available context, permitted actions and any instructions about when to stop or escalate.
2. Observe the current state. It reads relevant information from trusted interfaces or explicitly identified external sources. Retrieved content may contain errors or adversarial instructions and should not be treated as an authority to change permissions.
3. Choose the next step. A planner, policy or model determines whether more information, a calculation, a tool call, an approval or a final response is appropriate.
4. Check permission and execute. The host application validates whether the action is allowed. A tool then executes an authorized operation or requests a human decision.
5. Interpret the result. The agent checks success, failure or changed conditions, records relevant state and decides whether to continue, revise its plan or hand off.
6. Complete, stop or escalate. The run ends when the outcome is established, a limit is reached, a safety rule is triggered or further authorization is needed.

The cycle is not automatically reliable. A tool may fail, return stale information, carry malicious content or perform an unintended change. Strong systems separate a model's proposal from a validated tool invocation, and they confirm important side effects rather than accepting the agent's statement that a task was completed.

Tool use and environmental feedback

In many modern systems, tools are application programming interfaces (APIs), approved database queries, search functions, document processors, ticket operations or controlled computer interfaces. A tool can retrieve information without modifying anything, or it can create a side effect such as updating a record. These are different permission classes. Tool availability does not prove that the agent is authorized to use a particular operation for every user or every record.

The observations returned by a tool become part of the agent's operating context. A retrieved webpage might contain a relevant fact alongside text instructing the agent to ignore previous rules. An adequately governed agent treats that text as untrusted task data, not as a new instruction source. The application also needs an authoritative way to check whether the task was actually completed, such as the destination system's readback or a transaction record.

State, memory and adaptation

Agent state may include the current objective, previous tool results, partial work, pending approvals and a record of steps already taken. Some agents can retrieve longer-lived user or organizational information through a governed memory facility. Other agents have only a temporary task context. Neither capability implies continuous learning: adding a record to memory is different from changing the underlying model through training.

A long-running agent must distinguish resumable work from work already performed. If a tool times out after submitting a change, repeating the operation without checking its result may create duplicate tickets, orders or payments. Idempotency controls, transaction identifiers and exact confirmation of completed actions are therefore important where an agent can modify systems.

Components of an AI agent system

The exact architecture varies with task complexity, operating environment and risk. In an LLM-powered agent the language model may supply much of the flexible decision logic, while other software enforces constraints and carries out actions. In simpler or specialized agents, a rules engine, search algorithm or learned control policy may play a comparable decision role.

Component	Role in the agent	Practical boundary
Goal and instructions	Define the requested outcome, scope, task rules and stopping conditions.	Business authorization is not created merely by writing a permissive prompt.
Model, policy or planner	Selects actions or generates candidate plans based on current inputs.	The reasoning component may be mistaken and must not bypass access controls.
Data and observation interfaces	Provide relevant records, tool results, environment signals and context.	Inputs can be incomplete, outdated, sensitive or adversarial.
Tool and action interfaces	Retrieve information, perform computations or request changes through software functions.	Each operation needs a permission scope, validation and defined side-effect handling.
Task state and memory	Preserve relevant context, intermediate results and pending decisions.	Retention, privacy, freshness and resumption rules are distinct from model training.
Orchestration and execution runtime	Controls repeated steps, tool calls, handoffs, retries and termination.	Prevents uncontrolled loops, duplicate actions and indefinite operation.
Security and policy controls	Check data access, action authorization, risk limits and approvals.	These controls should be enforced by the host environment, not left solely to model instructions.
Monitoring and evidence records	Capture actions, results, errors, approvals and operational outcomes.	A plausible final response is not proof that the external operation succeeded.

The components show why an agent is a compound system rather than simply an enhanced prompt. A highly capable model with no access to tools can provide useful advice but cannot by itself perform a business operation. Conversely, a collection of powerful tools without explicit authorization and observation controls can magnify errors.

Forms and types of AI agents

Agent classifications describe different properties and are not mutually exclusive. A system can be both goal-driven and narrowly authorized, or both an LLM-based agent and one participant in a larger multi-agent workflow.

By decision mechanism

• Rule-based or knowledge-based agents: use represented knowledge, condition-action rules or search to select behavior. They are important in the history of AI agents and remain relevant in bounded environments. A trivial fixed automation is not necessarily an AI agent merely because it runs without human intervention.
• Learning-based agents: use machine-learned models or policies to estimate states, choose actions or adapt through experience. Reinforcement learning is one relevant learning paradigm, though not every learning-based agent uses it.
• LLM-based agents: use language models to interpret goals, reason over context and select among tools or next steps. This is a prominent architecture in contemporary enterprise agent applications.
• Hybrid agents: combine a language model, explicit rules, conventional workflow logic and other predictive or planning components. Their action permissions may be more constrained than their conversational flexibility suggests.

By operating arrangement

Arrangement	Defining property	Interpretation
Single-agent system	One agent coordinates the assigned goal and available tools.	It may still depend on many ordinary software services.
Multi-agent system	Several agents exchange tasks, observations or results under an orchestrated arrangement.	More agents create coordination and accountability challenges as well as possible specialization benefits.
Human-supervised agent	A person approves selected steps or can interrupt an operation.	The value of oversight depends on meaningful information and actual stop/override authority.
Bounded autonomous agent	Performs specified actions without individual approvals, subject to pre-established controls.	Autonomy is restricted by scope, permissions, risk and stopping rules.
Physical or robotic agent	Interacts with a physical environment through sensing and actuation.	Additional safety, sensing and control requirements apply; not all AI agents are software-only in their effects.

The label autonomous agent can be misleading without the qualifying operational scope. An agent may choose its own next data source yet be unable to approve an invoice, deploy a software release or send an external message. An evaluation should describe actual powers and decision boundaries instead of assigning a vague autonomy rating.

AI agents compared with related technologies

AI agents overlap with conversational software, automation and generative models but should not be equated with any of them.

Related concept	Main distinction from an AI agent
Artificial intelligence	The broad field encompassing models, methods and systems; an agent is one form of goal-directed AI application.
Large language model	Generates or processes sequences; may supply an agent's decision logic but does not itself define tool access or permissions.
Generative AI	Focuses on producing content; an agent focuses on pursuing a goal through selected actions, and may use generative AI.
Chatbot or conversational AI assistant	May answer questions or guide a user without controlling a multi-step task. Some assistants also have agent features.
Robotic process automation	Usually executes established, rule-based steps; an AI agent may select different actions in response to changing observations.
Workflow automation	Follows defined orchestration rules; an agent can choose steps dynamically within an allowed operating space.
Agentic AI	Broader term for AI systems and patterns involving agent-like goal pursuit and action, potentially with multiple agents.
AI Governance	The organizational system of decision rights, policies, accountability and controls that applies to agent deployment and operation.

A workflow that calls an LLM is not automatically an agent. Anthropic distinguishes systems that follow predefined orchestration paths from those in which an LLM dynamically directs its own tool use and process. Other publishers use AI agent more broadly, including narrow rule-based or workflow-controlled systems. Both usages occur; an encyclopedic definition should identify the underlying behavior and not impose one vendor's proprietary boundary as universal.

Where AI agents are used

Enterprise agents are commonly proposed for work in which the system must collect information, interpret a situation and interact with one or more applications. Actual availability, authority and success depend on the specific implementation; an advertised capability is not evidence of a reliable deployment.

Context	Example of an agent's role	Boundary that matters
IT service management	Retrieve a ticket's context, recommend routing, request missing information or perform permitted record updates.	Emergency and production changes still require the applicable approval and change authority.
Cybersecurity operations	Correlate alerts, collect evidence, open an investigation or propose containment.	Privileged containment steps need explicit authorization and incident procedures.
Software engineering	Examine a repository, run approved tests, propose code modifications and prepare a reviewable change.	Test results do not replace secure review or authorization to deploy.
Customer service	Retrieve order details, investigate a case and initiate an allowed service action.	Identity checks, financial thresholds and appeal routes remain necessary.
Procurement and finance	Collect contract terms, compare records or assemble evidence for an invoice exception.	Agent-selected information is not delegated payment or contracting authority.
Research and analysis	Locate sources, run calculations, cross-check claims and compile a report.	Sources require verification; a generated report is not itself independent evidence.

Some vendors report operational agent use in these areas, but deployment claims should be assessed independently of marketing descriptions. Experimental task benchmarks demonstrate defined technical performance, not general reliability or enterprise return on investment. Stanford's 2026 AI Index analyzes agent performance across task environments and makes this scope distinction relevant.

Levels of autonomy and decision rights

The practical significance of an AI agent depends on what it is allowed to do, not merely what it could propose. The following categories are illustrative operating arrangements, not a universal industry scale.

Allowed activity	Example	Typical control question
Observe and explain	Read permitted ticket data and suggest a resolution.	What sources and personal data can the agent access?
Prepare a proposed change	Draft a response or stage a record update without committing it.	Who reviews and authorizes the proposed action?
Execute a reversible, low-risk action	Apply an approved label or assign an eligible ticket within prescribed rules.	Can the action be audited, rolled back and repeated safely?
Execute a consequential action	Send an external message, issue a refund or modify a production setting.	Does the specific agent have the necessary delegated authority and approval for this case?
Stop or escalate	Pause on ambiguity, failed validation, a security alert or an unapproved change.	Can a human reconstruct what happened and recover the task safely?

These permissions should be enforced in the tools, identities and business systems used by the agent. If an agent is instructed to ignore a purchasing limit, a correctly designed payment service should still reject the unauthorized transaction. Broad service-account permissions, shared credentials or unrestricted integration tokens can defeat this separation.

Multi-agent coordination

A multi-agent system divides work among multiple software agents. For example, one agent may gather source information, another may analyze a technical issue and a third may check a report for missing evidence. A coordinating component must manage task handoffs, shared state, permissions, outputs, and the decision about when the overall task is finished.

Specialization can be useful when tools, context or responsibilities differ materially. It also introduces more opportunities for miscommunication, repeated work, conflicting actions and unclear accountability. Several agents operating in sequence do not automatically outperform one agent. The suitable architecture depends on the tasks, error costs, resource constraints and available evaluation evidence; complex orchestration should not be treated as a maturity goal in itself.

Security risks and failure modes

AI agents connect inference to action. This introduces operational risks beyond a model generating an incorrect answer. A malicious instruction in a webpage, email or document can become dangerous if a system treats it as permission to call an external tool; similarly, a mistaken decision can trigger several downstream actions before anyone notices. NIST's 2026 analysis of responses to its AI-agent security inquiry identified agent-specific security concerns, while OWASP's Top 10 for Agentic Applications 2026 organizes prominent risk categories and mitigation guidance.

Failure mode	What can go wrong	Relevant control principle
Instruction injection and goal manipulation	Untrusted text persuades the agent to abandon its task or reveal information.	Separate system instructions from retrieved content; independently enforce tool privileges.
Excessive permissions	An agent can access or change records beyond the user's legitimate scope.	Use identity and access management, least privilege and per-action authorization.
Unsafe tool invocation	Incorrect parameters, fabricated identifiers or inappropriate actions create side effects.	Validate inputs and action constraints at the tool and destination system.
Data leakage and privacy failure	Private records are included in external requests, logs or unauthorized destinations.	Apply data classification, outbound controls, minimization and retention limits.
Memory or context contamination	Misleading, stale or malicious state influences later decisions.	Apply trusted provenance, expiration, scope separation and review of persisted state.
Cascading or duplicate actions	Repeated attempts create duplicate transactions or spread an earlier error.	Use idempotency, bounded retries, transaction verification and stop rules.
Agent-to-agent trust failure	One agent accepts another agent's unsupported claim or overbroad instruction as authority.	Validate every handoff and maintain independent permissions and evidence records.
False completion	The agent announces success although a tool failed or the intended change did not occur.	Confirm outcome against authoritative destination records, not only a generated summary.

Security needs to protect both the model interaction and the connected software. Conventional authentication, authorization, logging, vulnerability management and segregation of duties remain essential, but their application has to account for dynamically selected actions and machine-to-machine delegation. A language-model guardrail may help recognize an unsafe request but should not replace a deterministic authorization decision by the system that owns the resource.

Governance and organizational accountability

Agent governance concerns who may authorize an agent, what purpose it serves, whose data it accesses, which actions it may take and how failures are detected and corrected. It is part of broader AI governance and enterprise technology governance; it is not created automatically by purchasing an agent platform.

Common accountability arrangements involve a business process owner who accepts the intended outcome and operating limits, a technology or product owner responsible for integration and reliability, security and privacy functions responsible for independent control requirements, and people authorized to approve consequential actions. In some organizations these responsibilities are combined; in others they are separated by risk and organizational scale. A person should be accountable for the operating process even when routine steps are delegated to an agent.

Governance evidence can include an agent inventory, purpose and risk classification, approved tool list, access grants, test results, escalation rules, change history, run traces, exceptions and periodic control reviews. The amount of evidence should be proportionate to the consequences of the agent's actions. The voluntary NIST AI Risk Management Framework 1.0 provides a broader risk-management reference; NIST stated in 2026 that revision work was under way, so references should preserve the applicable version.

The control boundary is especially important when an agent operates across a vendor ecosystem. A vendor's model can select an action, but the enterprise remains responsible for the identities, approvals and downstream effects it authorizes in its own environment. A controlled handoff to a person is an ordinary, legitimate agent outcome rather than proof that the agent failed to be autonomous.

Evaluating an AI agent

An agent should be assessed as a complete task-executing system rather than only by the language model powering it. Evaluations must represent the target environment, permissions, data, failure cases and acceptable outcomes. A benchmark for answering multistep questions may be useful for technical comparison but does not show whether an agent can safely process financial records or perform a production change.

Evaluation dimension	Possible measure	Why interpretation matters
Task completion	Verified correct completion rate over a defined set of tasks.	A confident final response is not proof of a completed external operation.
Action correctness	Correct tool and record selection; unnecessary or harmful actions.	A correct final answer can conceal an unsafe intermediate operation.
Operational reliability	Timeouts, retries, recovery quality, repeated-run variation and partial failures.	Success in one run does not establish repeatability under changed conditions.
Security and permissions	Unauthorized access attempts, policy violations, unsafe data transfers and successful control enforcement.	Tests must cover adversarial inputs and tool-side enforcement.
Human supervision	Escalation accuracy, approval burden, override effectiveness and recoverability.	Excessive escalation can negate benefits; absent escalation can conceal risk.
Cost and efficiency	Total time, tool calls, compute and operating cost per successful, quality-adjusted task.	Lower response time alone may hide rework or downstream cost.
Business outcomes	Process quality, error-adjusted throughput, customer impact or avoided loss against a credible baseline.	Correlation or a laboratory benchmark does not by itself establish return on investment.

Reliable evaluation requires explicit denominators, representative cases, a suitable baseline, timestamps and a way to detect harmful side effects. For agents that continue across sessions, it also requires tests of interrupted tasks, stale context, changed permissions and repeated execution. Monitoring should preserve enough trace information for a reviewer to reconstruct actions and confirm the final state without indiscriminately retaining sensitive content.

When agent behavior is useful and when it is not

AI agents can be useful when a task requires several observations and actions, the next step depends on information discovered during execution, and the system can validate results within defined limits. Examples include investigating inconsistent records, collecting dispersed case information, or coordinating a controlled service workflow. An agent is less compelling when a straightforward query, a single model inference or a deterministic workflow already solves the task reliably.

The choice has trade-offs. Agents may use more model calls, tools and operating time than a fixed workflow; added flexibility can mean greater variance, higher cost and more difficult testing. Where the path is predictable and the consequences of a wrong action are high, fixed automation with limited AI assistance may be preferable. Anthropic's engineering guidance explicitly distinguishes predictable workflows from flexible agent-directed processes and advises starting with simpler patterns where sufficient.

The need for an agent is therefore a property of the problem and environment, not an organization's desire to use the newest AI architecture. No universal benchmark score or autonomous-agent label establishes suitability for a particular enterprise.

Illustrative example: an IT service request agent

Consider a hypothetical organization receiving employee service requests through an ITSM platform. An approved agent is tasked with identifying missing information, consulting relevant service articles and preparing correct routing or resolution steps. The agent can read the request, retrieve authorized device and service information, compare the case with policy and update non-sensitive ticket fields. If the next step involves a production configuration change, it must refer the request to the relevant change authority rather than changing production systems itself.

Suppose the agent encounters a request to restore access to a restricted application. The language model proposes that the employee's account be added to a privileged group. The host access service checks whether the requester, business approval and agent identity authorize this action; no such approval is present. The agent must stop or request approval even if its generated explanation seems persuasive. In a different case, the agent may be permitted to ask the user for missing details and place the ticket in the correct queue without further review.

After the run, a human reviewer can inspect which sources were consulted, what tool operations were attempted, whether the permission checks rejected inappropriate actions, and whether the ticket actually reached its expected state. The example demonstrates goal-directed action, feedback and bounded authority. It is illustrative, not evidence of a particular vendor deployment or measured cost savings.

Relationship to other AI and management concepts

An AI agent is a system role or application arrangement, not a replacement name for the AI model, business process or governance structures around it. The nearest knowledge-graph relationships are:

• Parent field: artificial intelligence includes agent systems along with other reasoning, predictive and generative methods.
• Enabling technologies: Machine Learning, large language models and generative AI can provide perception, decision or language capabilities, depending on the agent design.
• Operating mechanism: tool use, orchestration, task state and observations connect decisions to permitted changes in the environment.
• Organizational controls: AI Governance, identity management and relevant business authorities govern what the agent may do.
• Distinct operating patterns: multi-agent systems, agentic AI and workflow automation overlap in practice but have different scopes and boundaries.

Frequently asked questions

Is an AI agent the same as a chatbot?

No. A chatbot may simply respond to user questions. An AI agent is defined by goal-directed selection of actions and interaction with its environment. A chatbot can acquire agent capabilities when it uses authorized tools to pursue a task, so the two categories can overlap.

Does every AI agent use a large language model?

No. Rule-based, planning-based and learning-based agent systems predate the current generation of language models. Many contemporary software agents use LLMs for flexible interpretation and tool selection, but that is one implementation choice.

Does an AI agent need to learn continuously?

No. An agent can update its task state or memory from tool results without retraining its underlying model. Whether it retains information across tasks or adapts its model depends on the deployment design and controls.

Can an AI agent act without human approval?

Some agents are authorized to execute defined, low-risk actions automatically. Others require approval for specified steps. An agent's technical ability to request a tool call does not confer organizational authority to execute that action.

What is the difference between an AI agent and agentic AI?

An AI agent is an individual goal-directed system or component. Agentic AI generally refers to the broader style or collection of systems using agent-like planning and action. Publisher terminology varies, and the two terms are sometimes used interchangeably.

Are multiple agents necessarily better than one agent?

No. Multiple agents can separate roles and tools, but they add coordination, permissions, observability and recovery demands. They should be justified by demonstrable task requirements and evaluation rather than by an assumed superiority of complex architectures.

How should an organization know whether an agent succeeded?

It should verify the intended result in the relevant system or process and evaluate task quality, unauthorized actions, recovery, cost and downstream outcomes against the defined operating requirements. The agent's own completion message is supporting evidence, not sufficient proof.

See also

• Artificial Intelligence (AI)
• Generative AI
• Large Language Model (LLM)
• Agentic AI
• Multi-Agent System
• AI Agent Orchestration
• AI Agent Security
• AI Agent Evaluation
• Tool Calling
• Robotic Process Automation (RPA)
• AI Governance
• Identity and Access Management (IAM)