What is an AI agent?¶
An AI agent is a system that receives an objective, decides which actions are needed to move toward it, can execute those actions through tools, and uses the results to decide the next step. A language model may propose an action, but the complete agent also includes the runtime, tools, state, permissions and the logic that decides when to stop.
The essential distinction is this: a chatbot generates a response; an agent can change the state of another system.
The 60-second answer¶
Autonomy does not remove control. It moves control into the available tools, permissions, step budget, and stopping policy.
A tool call does not grant authority by itself. The fact that the model emits send_email(...) does not mean the system should execute it. The runtime must validate arguments, permissions, risk and state before producing an external effect.
Chatbot, workflow, copilot and agent¶
A workflow is not inferior because it is deterministic. If the steps are already known, it is usually easier to test, explain and constrain. Agency adds value when the sequence depends on the environment and encoding every branch in advance is not worth the complexity.
The components of an agent¶
A reliable agent needs more than a prompt and several functions:
- Objective — what successful completion means.
- Context — what information it may use in the current turn.
- Tools — which actions exist and what their contracts are.
- State — which operations are pending, completed or failed.
- Memory — what information may persist between sessions and with what provenance.
- Policy — what requires authorization, what is forbidden and what budget exists.
- Verification — how the system proves that the result is correct.
The AI Agents — from responding to acting series develops these components through five progressive chapters.
Tool calling is not the same as agency¶
An LLM can produce structured arguments for a function. That is tool calling. Agency appears when the system can decide when to use a tool, interpret its result and choose what to do next.
A tool should remain a software contract. The model proposes a call; the runtime keeps the authority boundary and decides whether it may execute.
send_email(to, subject, body)
action + structured arguments
{ status, id, error? }
Memory, context and state are different things¶
All three layers participate in the same task, but they answer different questions: context is the model's working view, memory preserves retrievable information, and operational state describes the real execution maintained by the runtime.
Bounded working view: instructions, messages, retrieved documents and selected runtime signals.
User: “send the report”
The request exists; the external effect does not yet.
request accepted · op_id=42
Context reflects state; it does not replace it.
operation in progress · op_id=42
The model can keep conversing while the task continues.
delivery completed · result_id=m_7f2
Only now can it state that the operation completed.
Selected persistence: preferences, confirmed facts or summaries, with provenance, scope and deletion rules.
—
A user intention is not yet an executed fact.
—
Accepting work does not mean completing it.
—
Do not persist an outcome before verifying it.
report sent · result_id=m_7f2
It may be persisted if the memory policy allows it.
Runtime data: operation status, retries, locks, idempotency, errors and observable results.
status=requested
A request exists, but no execution has been accepted yet.
status=accepted · op_id=42
The runtime has accepted responsibility for the operation.
status=running · retry=0 · lock=held
The task remains live even when the conversation turn changes.
status=succeeded · result_id=m_7f2
The effect is confirmed by the system that executed it.
The separation becomes critical when a tool takes time. The conversation may record that an action was requested while the runtime knows it is still executing. Operational state — not chat text or retrieved memory — must therefore govern what actually happened and what the system may claim to the user.
How to evaluate an agent¶
A convincing final answer is not enough. You need to measure the complete task: what the agent decided, what it was allowed to execute, what effect it produced, and whether the system ended in a correct, recoverable state.
Define what successful completion means before execution begins.
Selects an action and proposes arguments from the available context.
Validates schema, permissions, risk, and any required approval.
Produces an observable result: success, error, timeout, or retry.
Checks the real effect, idempotency, and whether recovery remains possible.
Communicates only what is supported by the observed result.
A trace exposes transitions that a final score hides. It separates a tool-selection failure from an authorization, execution, state, or user-communication failure, and turns each incident into a reproducible case.
How to evaluate an AI agent develops a gate architecture for outcome, trajectory, safety and operational economics.
Why security changes when the system can act¶
A chatbot that misinterprets a document may produce a wrong answer. An agent with broad permissions can turn the same misinterpretation into an external action.
Security therefore has to live outside the prompt as well: least privilege, per-operation authorization, isolation, human approval for sensitive actions, observability and an external path to stop execution.
The AI Security series covers prompt injection, jailbreaks, poisoned memory, red teaming and production controls.
When using an agent makes sense¶
Agency is useful when:
- the objective is clear but the sequence changes depending on what happens;
- several tools are available;
- intermediate results determine the next step;
- the system can verify progress and outcome;
- permissions and cost can be bounded.
A conventional workflow may be better when the path is known, the error budget is tiny or a deterministic function solves the problem with less risk surface.
Where to go deeper in 5sigmas¶
- What is an agent and what is not?
- Agent anatomy: tools, memory and state
- How to evaluate an agent
- Agent security
- From demo to production
- Proactive and reactive agents and tool calls
Frequently asked questions¶
Is ChatGPT an AI agent?¶
It depends on the capability being used. A chat interface that only generates text behaves as a conversational assistant. A system that can choose tools, operate on external resources and continue from their results includes agentic behaviour. The label should describe the real system, not only the model it uses.
Is RAG an agent?¶
Not necessarily. Retrieving documents and passing them to a model can be a deterministic workflow. It becomes part of an agent when the system can decide when to search, which source to query and what to do next with the result.
Does an agent require multiple models?¶
No. One model can coordinate multiple tools. Multi-agent systems are one possible architecture, not a requirement.
Does more autonomy mean a better agent?¶
No. In production, bounded autonomy usually matters more: minimal tools, budgets, verification and a clear stopping criterion.
Primary sources¶
- Yao et al. — ReAct: Synergizing Reasoning and Acting in Language Models
- Anthropic — Trustworthy agents in practice
- OpenAI Agents SDK — Context management
- OpenAI Agents SDK — Sessions
- OpenAI Agents SDK — Run state
- OpenAI Agents SDK — Tracing
- OpenAI Agents SDK — Tool guardrails
- OpenAI Agents SDK — Agent orchestration
- Model Context Protocol — Authorization