Guide

What Is an AI Agent?

A practical definition of AI agents focused on goals, tools, state, permissions, evidence, stop rules, and operator review for real workflows.

An AI agent is a system that uses a model to pursue a goal through planned steps, state, and tools. The useful question is not whether it feels autonomous. The useful question is what it is allowed to do, how it records evidence, and when it stops. A verification-first team defines an agent by its control surface: inputs, permissions, retrieval sources, tool calls, checkpoints, logs, and review gates.

The term gets used loosely. Some teams call any prompt chain an agent. Others reserve the word for systems that choose tools dynamically. For operational design, the label matters less than the failure model. If a model can act outside a single response, read or write data, call APIs, retry work, or hand a result to another system, it needs the same controls described in the agent permission design guide and the agent observability guide.

The problem an agent should solve

An agent is useful when the work cannot be reduced to one deterministic call. Examples include research triage, support knowledge lookup, code review preparation, documentation maintenance, and monitoring workflows. In each case the system must gather context, decide what matters, take bounded actions, and explain its conclusion.

That does not mean every AI feature should become an agent. If the desired output is a summary, classification, extraction, or rewrite, a simple prompt with tests may be better. The prompt testing framework is enough when the input and expected behavior are stable. Agents become worth the extra complexity when the task needs iterative discovery, tool selection, exception handling, and a durable audit trail.

Core parts of an AI agent

A reliable agent has six parts. First is the goal: the explicit outcome the system is optimizing for. Second is the instruction set: what the model may and may not do. Third is state: the working memory, queue, scratchpad, or run context used across steps. Fourth is the tool layer: retrieval, search, code execution, ticketing, email, database, or internal APIs. Fifth is the policy layer: permissions, approval requirements, rate limits, and stop rules. Sixth is evidence: logs, citations, artifacts, scores, and reviewer notes.

If any of those parts are missing, the system is probably an assisted workflow rather than a production agent. That can still be valuable, but it should not be trusted as autonomous infrastructure.

A practical design method

Start by writing the agent contract in plain English. Name the trigger, the allowed data sources, the tools it may call, the maximum number of steps, the conditions that require human review, and the final evidence it must produce. Then design the happy path and at least five failure paths. Include stale retrieval, prompt injection, missing permissions, irrelevant tool results, and unsupported conclusions.

Next, build a fixture set. A fixture is a repeatable input with known expectations, similar to the approach in the LLM evaluation framework. Fixtures should include clean examples, ambiguous examples, adversarial examples, and no-answer cases. The goal is not to make the agent look good; it is to discover where it should stop, ask for help, or return a constrained answer.

Finally, connect the agent to narrow tools first. Read-only retrieval should come before write actions. Draft creation should come before publishing. A human approval step should protect irreversible or external actions until logs show the agent behaves consistently under edge cases.

Failure modes to expect

Agents fail differently from one-shot prompts. They can call the right tool with the wrong argument. They can trust stale retrieval. They can hide uncertainty inside confident final prose. They can retry until they amplify a bad assumption. They can leak private context into a downstream system. They can perform the task but leave no evidence for review.

The AI agent failure modes checklist should be used before launch, not after an incident. Each failure mode needs a matching control: schema validation, allowlists, no-answer rules, timeout limits, reversible drafts, source citations, or operator approval.

Verification checklist

Before treating a workflow as an agent, confirm that it has a named owner, a defined goal, a bounded action set, a visible trace, and a rollback path. Confirm that every external action has a permission class. Confirm that the final answer cites the evidence it used. Confirm that the system can say “I cannot complete this” instead of inventing progress.

For production use, add run review. Sample successful and failed traces each week. Tag failures by cause. Feed those tags into the agent reliability scorecard so the team can see whether reliability is improving or merely being patched prompt by prompt.

Frequently asked questions

What makes an AI agent different from a chatbot?

An AI agent pursues a goal through steps, state, and tools, while a chatbot usually answers one prompt at a time without durable permissions or an execution record.

Should every AI workflow be built as an agent?

No. Use an agent only when the task needs multi-step judgment, tool use, and recovery logic that a simpler prompt or automation cannot handle.

Next step

Use this definition as a review template before building. If the workflow has tools, state, permissions, and evidence, design it like an agent. If it does not, keep the implementation simpler and test it with the same discipline you would apply to any other LLM feature.