What Is An AI Agent?

Concepts Covered

• AI agents
• Goals
• Multi-step workflows
• Tools
• State
• Loops
• Stop conditions
• Autonomy boundaries
• Agent versus chatbot
• Why agents need evaluation

1. Plain-English Definition

An AI agent is a system that uses a model inside a multi-step workflow to pursue a goal, often with tools and state.

That definition is intentionally about a system, not only a model.

A simple model call may be:

question -> model -> answer

An agent-like workflow may be:

goal -> inspect context -> choose next step -> use tool -> observe result -> continue or stop

The model may help decide the next step. The product still defines boundaries around what can happen.

2. Why This Idea Exists

Some tasks do not fit one response.

Consider:

• investigate a failing test
• plan a trip under constraints
• triage a support case
• gather information from several tools
• edit code, run checks, and revise

These tasks involve steps. A useful system may need to look at an intermediate result before deciding what to do next.

Agent vocabulary exists because modern AI products increasingly combine models with workflows that can act over several steps instead of returning one isolated completion.

3. The Beginner Mental Model

Think of an agent as a loop with a job.

see state
choose next move
act through allowed tools
see new state
stop when done or blocked

This mental model is more useful than imagining an independent robot employee.

It highlights the engineering pieces:

• the goal
• the available context
• the model decision
• the tools
• the state across steps
• the stopping rule

4. What That Mental Model Misses

The loop picture is useful, but it can sound more capable than the system really is.

First, a model can make a bad next-step decision. Agents inherit model uncertainty and add workflow risk.

Second, tools can have real side effects. Reading a file is different from sending an email or deleting data.

Third, state can drift. A long agent run may carry stale assumptions, bad summaries, repeated failures, or partial work.

Fourth, autonomy is a product choice. Some systems suggest actions. Some require approval. Some act inside narrow safe boundaries.

Fifth, calling something an agent does not remove ordinary software design. Permissions, retries, timeouts, audit logs, idempotency, rollback paths, and user trust still matter.

5. A Concrete Example

Imagine a coding assistant asked:

Fix the failing checkout test.

A one-shot assistant might read the prompt and suggest a patch.

An agent-style workflow might:

1. inspect the failing test output
2. read the relevant source files
3. propose an edit
4. apply the edit inside allowed workspace boundaries
5. run the targeted test
6. inspect the result
7. stop if fixed or revise if still failing

The value comes from observing results between steps.

The risk also comes from those steps. The workflow needs limits and user-visible accountability.

6. How It Works At A Practical Level

At a practical level, an agent system often combines:

• a model call
• instructions and context
• tool definitions
• state about the task
• a controller or loop
• stop and escalation conditions

A simplified path:

task state -> model chooses action -> tool runs -> result updates state

Then the loop decides whether to continue.

The controller may be ordinary application code. It can limit tools, require approvals, cap steps, store traces, handle errors, and decide when a human should take over.

That is why an agent is best learned as an architecture shape, not a personality.

7. Where You See This In Real AI Products

In coding assistants, agent flows can inspect files, edit code, run tests, and reason over outputs.

In customer-support automation, an agent workflow may gather account facts, retrieve policy context, draft an action, and wait for approval.

In research assistants, the workflow may search, read, summarize, and refine a result over several steps.

In operations tooling, a narrow agent may inspect alerts, fetch diagnostics, and recommend a runbook action.

The common pattern is a model participating in a bounded multi-step software workflow.

8. Common Confusions

An agent is not just any chatbot.

A chatbot can answer one turn. An agent usually adds goal-directed steps, tools, state, or loops.

An agent is not the same thing as a tool.

The tool performs an allowed operation. The agent workflow decides when and how to use it.

An agent is not safe because it sounds helpful.

Action boundaries and evaluation matter more as side effects grow.

Autonomy is not all-or-nothing.

A product can suggest, ask approval, act in a sandbox, or act automatically in a narrow scope.

9. What This Does Not Mean

This does not mean every AI product should become an agent.

Many tasks are better as one model call, retrieval plus answer, a deterministic workflow, or ordinary software.

This does not mean the model owns responsibility for side effects.

The product owns tool access, permissions, approvals, and recovery paths.

This does not mean longer loops automatically improve quality.

More steps can also multiply cost, latency, and failure opportunities.

10. What To Learn Next

Agents become concrete when you understand their software boundary. Continue with Tool Use And Function Calling.

Then close the foundation layer with What Are Evals?.