What is AI Agent?
AI Agent is a software system in which an AI model can choose the next step, tool, or handoff from observed state while an application runtime controls execution, permissions, budgets, persistence, and termination.
Quick Facts
| Full Name | Artificial Intelligence Agent |
|---|---|
| Specification | Official Specification |
How It Works
Agent, Workflow, and Chatbot Boundaries
A chatbot can answer a message without controlling an external process. A deterministic workflow follows code-defined branches. An agent is appropriate when the exact next step cannot be fixed in advance and a model selects among bounded actions from changing evidence. A system can combine all three: deterministic workflow stages may contain an agentic decision point.
Planning, persistent memory, self-reflection, and multiple agents are optional patterns, not defining requirements. Adding them increases state, latency, and failure modes, so each capability should justify itself against a simpler baseline.
Run Loop and State
A typical loop assembles trusted instructions and current state, calls the model, classifies the result as a final answer, tool proposal, handoff, clarification, or refusal, executes allowed work, appends the observation, and repeats. Every run needs a stable identity, maximum turns, time and cost budgets, cancellation, and explicit terminal states.
Conversation messages are only one view of state. Production systems also track task version, tool call IDs, approvals, external effect status, checkpoints, and artifact references. The runtime should be the authoritative state writer when concurrent or resumable work is possible.
Tools, Authority, and Side Effects
Tool schemas help a model form arguments, but a generated call is a proposal rather than authorization. The executor must derive tenant, user, resource scope, and current policy from trusted context; validate arguments; separate read and write capabilities; and require approval for consequential actions.
Side effects need idempotency keys and an effect journal. A timeout does not prove that an operation failed, so retries must distinguish safe replay from an unknown outcome. Tool results and retrieved content are untrusted observations that can contain prompt injection or stale data.
Evaluation, Recovery, and Operations
Evaluate the complete trajectory, not only the final prose. Useful measures include task success, valid tool selection, argument correctness, authorization decisions, recovery from partial failure, duplicate-effect rate, escalation quality, latency, and cost. Compare the agent with a single-call or deterministic workflow baseline.
Production controls include traceable release identity, redacted event logs, sandboxed execution where needed, checkpoints, pause and resume, human escalation, kill switches, and rollback. An agent that reaches a plausible answer while violating policy or losing effect state has failed.
Key Characteristics
- Model-directed within bounds: the model selects a next step while the runtime retains authority
- Environment-coupled: observations from tools or users update the state used by later decisions
- Explicitly terminated: success, refusal, escalation, cancellation, timeout, and budget exhaustion are distinct states
- Stateful when required: task, call, approval, checkpoint, and effect identities survive retries or resume
- Least-privilege by design: available actions and resource scopes are derived from trusted runtime context
- Evaluated as a system: trajectories, effects, failures, latency, and cost matter alongside answer quality
Common Use Cases
- Investigating a software issue when the required files, tests, and repair steps are not known in advance
- Researching a question across sources while retaining claim-level provenance and requesting clarification when evidence is insufficient
- Triaging support cases and proposing bounded actions that require deterministic policy checks
- Operating a long-running workflow that can pause for approval and resume from a checkpoint
- Coordinating specialist workers when delegation outperforms a single-agent and fixed-workflow baseline
Example
Loading code...Frequently Asked Questions
What is the difference between an AI agent, a chatbot, and a workflow?
A chatbot primarily produces conversational responses. A workflow follows code-defined steps and branches. An agent lets a model choose among bounded next actions based on changing state and observations. These categories can overlap, and a workflow with one model-directed decision point does not make every part of the system autonomous.
Does an AI agent need planning, memory, or multiple agents?
No. The minimal useful pattern is a model choosing a next action in a controlled feedback loop. Planning, persistent memory, reflection, and delegation are optional. Add each only when representative evaluations show that it improves task success enough to justify extra state, latency, cost, and operational risk.
Can a valid tool call be executed automatically?
Schema validity is not authorization. The runtime must identify the caller and tenant from trusted context, verify current resource state and policy, constrain arguments, and request approval when required. A syntactically valid call can still target the wrong account, repeat a side effect, or violate business rules.
How should an AI agent recover after a timeout?
Record the call ID, idempotency key, request, and effect status before execution. After a timeout, query the downstream system or reconcile its journal before retrying because the result may be unknown rather than failed. Resume from authoritative state and never ask the model alone to infer whether a side effect occurred.
How should an AI agent be evaluated?
Measure end-to-end task success and trajectory quality: correct tool choice and arguments, policy decisions, evidence use, recovery, duplicate effects, escalation, latency, and cost. Include adversarial and partial-failure cases, compare with simpler baselines, and retain human review for outcomes whose harm cannot be safely automated.