3. What Exactly is an AI Agent?

Moving beyond one-shot generation to systems that can pursue goals, use tools, observe results, and adapt their next actions.

The term AI agent is now used to describe everything from a chatbot with a search button to a system that can independently modify software, operate a browser, or coordinate a business process. There is no single universally accepted boundary between an ordinary AI application and an agent.

A more useful way to think about agency is as a spectrum. At one end is a model that produces a single response. At the other is a system that can choose and execute multiple actions, inspect their results, update its approach, request human input when necessary, and continue until it reaches a stopping condition.

The defining feature is not that the system “thinks like a person” or operates without supervision. It is that the model participates in controlling a process over time rather than merely generating one isolated answer.

Models, Chatbots, Workflows, and Agents

These terms are related but should not be treated as interchangeable.

Language Model

A language model receives an input and produces an output. Depending on the model, that output may include text, code, images, audio, structured data, or a request to call a tool.

By itself, the model does not normally execute the requested action. The surrounding application decides what the model can access, which actions are permitted, how results are returned, and when execution must stop.

Chatbot or Assistant

A chatbot provides a conversational interface around one or more models. Modern assistants are no longer necessarily passive: they may search the web, analyze files, execute code, create images, remember preferences, or interact with connected applications.

For this reason, it is no longer accurate to say that every chatbot lacks tools or multi-step capabilities. A conversational interface can contain an agent, invoke an agentic workflow, or remain a straightforward question-and-answer system depending on how it is designed.

Workflow

An AI workflow follows a path substantially defined by the developer. The model may classify an input, generate content, evaluate a result, or choose among a limited number of branches, but the overall sequence remains predictable.

For example:

Extract customer details from an email.
Look up the customer in a database.
Generate a suggested response.
Send the draft to a human for approval.

This workflow uses AI, tools, and several steps, but the developer—not the model—has determined the main sequence.

Agent

An agent is a system in which a model has some responsibility for deciding what action to take next. The developer supplies the available tools, instructions, permissions, state, and safety boundaries, while the model dynamically selects actions based on the goal and the observations returned by the environment.

An agent might decide to:

Search for missing information.
Read a particular file.
Run a query against a database.
Execute and test code.
Ask the user for clarification.
Delegate a subtask to a specialist agent.
Revise its plan after an action fails.
Stop when the task is complete or further action would be unsafe.

📏 Agency Is a Spectrum

A system does not become an agent merely because it calls one function, and it does not need unlimited autonomy to qualify as agentic. Useful systems range from tightly bounded tool-using assistants to longer-running agents that choose among many possible actions.

The practical question is not “Is this a true agent?” but rather: Which decisions can the model make, which actions can it take, and what controls surround those actions?

The Core Components of an Agentic System

Agent architectures vary, but most practical systems combine the following components.

1. A Model

The model interprets the goal, evaluates the current state, selects actions, and produces outputs. Some systems use one general-purpose model, while others route different stages to specialist reasoning, coding, vision, speech, or low-cost models.

The model is an important component, but it is not the entire agent. The surrounding runtime determines what the model is allowed to do and whether its proposed actions are actually executed.

2. Instructions and Goals

The agent needs a clear description of its objective, role, constraints, available resources, and completion criteria. Instructions might specify:

What outcome the agent should achieve.
Which sources it should trust.
Which actions are prohibited.
When it must ask for approval.
How it should handle uncertainty.
What evidence it must provide.
When it should stop.

A vague instruction such as “handle this customer” gives the model too much room for interpretation. A bounded objective such as “identify the customer’s issue, retrieve the relevant policy, draft a response, and request approval before issuing any refund” is much safer and easier to evaluate.

3. Tools

Tools allow the agent to obtain information or change something outside the model. They may be implemented as functions, APIs, command-line programs, database queries, browser controls, Model Context Protocol connections, or calls to other agents.

Common tools include:

Web search and page retrieval.
Databases and knowledge bases.
File reading and writing.
Code execution and testing.
Email, calendars, messaging, and customer-support systems.
Business applications such as CRM, ERP, and ticketing platforms.
Browser or computer-use environments.
Specialist models or sub-agents.

A tool definition normally describes its name, purpose, input schema, and possible outputs. Clear, narrow tool definitions generally produce more reliable behaviour than vague, overlapping tools.

4. State and Context

An agent needs enough state to understand what has already happened and what remains to be done. This may include:

The user’s request and subsequent messages.
Previous tool calls and their results.
A task plan or list of completed steps.
Retrieved documents and relevant evidence.
Application data such as an order, ticket, or project record.
Pending approvals and resumable execution state.

The model’s context window provides temporary working context, but production systems frequently store state outside the model so that runs can be resumed, audited, summarized, or transferred between components.

5. Memory and Retrieval

“Memory” is an umbrella term rather than a mandatory database architecture. It may refer to:

Working memory: Information needed during the current run.
Conversation state: Relevant history from an ongoing interaction.
Episodic memory: Records of previous tasks or outcomes.
Semantic memory: Stored facts, policies, documents, or user preferences.
Procedural memory: Instructions, examples, or reusable strategies for completing a task.

A vector database is one possible retrieval mechanism, but it is not synonymous with long-term memory. Depending on the application, a relational database, document index, knowledge graph, event log, user profile, or ordinary application state may be more appropriate.

Stored memories should be scoped, permissioned, reviewable, and removable. Automatically saving everything the model encounters can create privacy, security, accuracy, and data-retention problems.

6. An Execution Loop

The agent runtime repeatedly gives the model the current goal and relevant state. The model then selects an action, the runtime executes it, and the result is returned as a new observation.

A simplified loop looks like this:

Interpret the current goal and state.
Select the next permitted action.
Validate the requested action and arguments.
Execute the tool or request human approval.
Return the result to the model.
Update the state and decide what happens next.
Finish, pause, escalate, or continue.

The agent does not necessarily create a complete plan before acting. Some systems plan explicitly, some plan only a few steps ahead, and others select one action at a time as new information becomes available.

7. Environmental Feedback

Agents need observations grounded in the external environment. Examples include:

A search result.
A database record.
A compiler error.
A failed login.
A test result.
A browser screenshot.
A confirmation that an email was sent.
A message that an action was denied.

The agent uses these observations to determine whether it is making progress. It may retry, change tools, revise a query, ask for assistance, or conclude that the task cannot safely be completed.

8. Stopping Conditions

An agent should not continue indefinitely. The runtime needs explicit stopping conditions such as:

The requested result has been produced and validated.
A required approval has not been granted.
The agent has reached a maximum number of steps or a spending limit.
The same action has failed repeatedly.
The agent lacks required information or permissions.
A guardrail has blocked the next action.
The task has been cancelled.

Stopping safely is part of successful agent behaviour. An agent that recognizes that it cannot proceed is often more useful than one that continues taking speculative actions.

The Agent Loop

A common conceptual pattern is:

Goal → Decide → Act → Observe → Update → Repeat

Imagine an agent asked to investigate a failed software build:

Goal: Determine why the build failed and prepare a proposed fix.
Decision: Inspect the latest build logs.
Action: Call a tool that retrieves the logs.
Observation: The logs show that a dependency version cannot be resolved.
Update: Inspect the dependency configuration and package registry.
Next action: Propose a compatible version, modify an isolated branch, and run the tests.
Completion: Present the tested change for human review rather than merging it automatically.

The useful behaviour comes from the feedback loop: each external result influences the next action.

What About ReAct?

ReAct—short for reasoning and acting—is an influential pattern introduced in research on language-model agents. It interleaves model deliberation, external actions, and observations so that information gathered from the environment can guide subsequent decisions.

A simplified, developer-visible representation might look like this:

Decision: Current pricing information is required.
Action: Call an approved market-data tool for the requested symbol.
Observation: The tool returns a timestamped price and market status.
Decision: Verify the currency and include the timestamp in the answer.

However, ReAct should not be interpreted as a requirement for the model to reveal or narrate its private internal reasoning. Modern agent systems may use hidden reasoning, brief plans, structured action requests, summaries, state machines, or direct tool calls. Developers and users generally need access to the agent’s actions, evidence, decisions, and outcomes—not an unrestricted transcript of internal chain-of-thought.

🔄 ReAct Is One Pattern, Not the Definition of an Agent

ReAct remains useful for understanding the interaction between decisions, actions, and observations. Production systems may also use routing, prompt chaining, parallel execution, evaluator–optimizer loops, explicit planners, deterministic state machines, or combinations of these patterns.

Autonomy Does Not Mean Absence of Control

The word autonomous can create the misleading impression that an agent should be left to operate without boundaries. In production, useful autonomy is normally bounded autonomy.

The system may allow the model to choose how to complete a task while restricting:

Which tools it can access.
Which records or files it can read.
How much money it can spend.
Which external systems it can modify.
How many steps it can take.
Whether it can contact other people.
Which actions require confirmation.

A research agent may be allowed to search and summarize independently but require approval before emailing its findings. A coding agent may edit and test files in a sandbox but require a human to approve deployment. A customer-service agent may draft a refund but be prevented from issuing one above a specified value.

Guardrails and Human Approval

Giving a model tools creates risks that do not exist in ordinary text generation. An incorrect paragraph can be edited; an incorrect tool call might delete data, expose confidential information, purchase an item, or send a message to the wrong recipient.

Production agents therefore need controls outside the model itself, including:

Least-privilege access: Give the agent only the permissions needed for the task.
Input validation: Check tool arguments before execution.
Output validation: Confirm that results match required schemas and business rules.
Human approval: Pause before consequential, irreversible, sensitive, or high-value actions.
Sandboxing: Isolate code execution and file operations from important systems.
Spending and step limits: Prevent uncontrolled loops and unexpected costs.
Audit logs: Record model calls, tool calls, approvals, results, and errors.
Prompt-injection defences: Treat retrieved content as untrusted data rather than authoritative instructions.
Identity and authorization checks: Verify that both the user and the agent are permitted to perform the requested action.

🛑 The Model Is Not the Security Boundary

Instructions such as “never delete an important file” are not sufficient protection. Consequential restrictions should be enforced by application code, permissions, approval systems, and tool design rather than relying solely on the model to obey a prompt.

Single-Agent and Multi-Agent Systems

Some applications use one agent with several tools. Others divide the work among multiple specialized agents.

A multi-agent system might contain:

A coordinator that delegates work.
A research agent that gathers evidence.
A coding agent that implements changes.
A reviewer that evaluates the result.
A compliance agent that checks policy constraints.

Multiple agents can improve specialization and separation of responsibilities, but they also add latency, cost, communication overhead, and new failure modes. A multi-agent architecture should be used because the task benefits from distinct roles—not merely because it sounds more advanced.

When Should You Use an Agent?

Agents are most useful when a task:

Requires a variable number or order of steps.
Depends on information discovered during execution.
Requires interaction with external tools or environments.
Contains exceptions that are difficult to encode as fixed rules.
Has a clear objective or verifiable completion criteria.
Can tolerate some model-driven decision-making within defined boundaries.

Examples include:

Investigating and fixing software defects in a sandbox.
Researching a question across many sources.
Triaging support requests and retrieving customer information.
Reconciling records across several business systems.
Preparing reports that require iterative data gathering and validation.
Operating an application through a browser when no suitable API exists.

When Is a Workflow Better?

An agent is not automatically the best solution. A deterministic workflow is usually preferable when:

The required steps are known in advance.
The task can be expressed reliably in ordinary code.
Errors would be highly consequential.
Strict consistency and predictability are required.
A single model call or retrieval step solves the problem.
The process must be easily audited and formally tested.

For example, calculating tax, applying an eligibility rule, validating a payment amount, or enforcing access permissions should normally remain deterministic. A model can help interpret an ambiguous request, but established code should perform the authoritative calculation or policy check.

🧱 Start With the Simplest Architecture That Works

Begin with a single model call or deterministic workflow. Add tool selection, loops, planning, memory, or multiple agents only when evaluations show that the additional flexibility produces enough value to justify the additional risk and complexity.

How Do You Know Whether an Agent Works?

Traditional language-model evaluations often measure the quality of an individual answer. Agent evaluations must measure the complete trajectory and its effect on the environment.

Useful measures include:

End-to-end task completion rate.
Correct tool-selection rate.
Validity of tool arguments.
Number of unnecessary or repeated actions.
Recovery rate after tool failures.
Quality and accuracy of the final result.
Compliance with permissions and approval rules.
Latency and cost per successfully completed task.
Frequency of required human intervention.
Rate of unsafe or irreversible action attempts.

Testing should include ordinary examples as well as malformed inputs, unavailable tools, misleading retrieved content, ambiguous instructions, expired credentials, conflicting data, and attempts to manipulate the agent through prompt injection.

Why Agents Matter

Agentic systems change the role of generative AI from producing content to participating in processes. A model can gather information, operate software, transform files, coordinate services, and carry a task through several stages rather than merely explaining how a person might perform it.

However, describing an agent as a “digital worker” can overstate its independence and reliability. Current agents are better understood as probabilistic software components capable of bounded decision-making. They can automate valuable parts of knowledge work, but they still require carefully designed tools, permissions, evaluations, observability, and human accountability.

The strongest agent systems do not remove people indiscriminately. They allocate work deliberately: deterministic software handles fixed rules, models handle interpretation and flexible decisions, tools perform external actions, and humans retain control over judgement-heavy or consequential outcomes.