What is an AI agent? A plain-English definition

An AI agent is a program where a language model decides what to do next, calls tools to do it, looks at the result, and repeats until the task is finished. That's the whole idea. Most of the noise around the word comes from products that stretch it to cover a chatbot with a nicer label.

This post gives you a definition you can use to cut through that, a way to tell agents apart from simpler setups, and a rough test for whether your project needs one at all.

The definition, in one loop#

Strip away the branding and every agent has three parts.

1. A model that reads the current situation and chooses an action.
2. Tools the model can call: search, a database query, a shell command, an HTTP request, a file edit.
3. A loop that feeds each tool result back to the model so it can choose again.

The loop is the part people skip over. A chatbot answers once. An agent acts, observes, and acts again, with the model steering. If you want the mechanics in detail, how the agent loop works walks through a single turn from start to finish.

Here's the shape in plain pseudocode:

messages = [user_goal]
while True:
    reply = model(messages, tools=tools)
    if reply.wants_tool:
        result = run_tool(reply.tool_name, reply.tool_input)
        messages += [reply, result]
    else:
        return reply.text

Ten lines. Everything else in the agent world (memory, planning, sub-agents, guardrails) is something bolted onto that loop to make it behave better.

A concrete example#

Say you tell an agent: "The checkout test is failing, fix it."

A plain chatbot would guess. It hasn't seen your code, so it offers generic advice about mocking and async timing.

An agent does something closer to what a developer would. It runs the test suite and reads the failure. It opens the file named in the stack trace. It notices a date being compared as a string, edits the comparison, and runs the test again. The test passes, so it stops and tells you what it changed.

Nobody scripted those steps. The model chose them based on what each tool returned. That's the property to look for: the path isn't fixed in advance.

Chatbot, workflow, agent#

These three get lumped together, and the difference matters when you're deciding what to build.

Anthropic's engineering write-up on building effective agents draws the same line. Workflows are systems where code orchestrates the model and tools along predefined paths. Agents are systems where the model directs its own process and tool use. It's worth reading the original, because the distinction helps you resist reaching for an agent when a workflow would do.

A quick example of a workflow: take an incoming support email, classify it, look up the customer, draft a reply from a template, and queue it for review. Every step is known. The model does the classification and drafting, but your code owns the order. It's reliable, cheap, and easy to test.

Turn that into an agent by removing the fixed order. Now the model decides whether to look up the customer, whether to check the order history first, whether to escalate, and when it's done. You gain flexibility and lose predictability.

Autonomy is a dial, not a switch#

Calling something "an agent" hides how much freedom it has. A more useful way to think about it is a dial.

• Suggest only. The model proposes actions, a human approves each one.
• Act with guardrails. The model acts on its own inside a narrow sandbox, with limits on what it can touch.
• Act with review. The model completes the whole task and a human checks the result before it ships.
• Fully autonomous. The model acts, and nobody looks unless something breaks.

Most successful products today sit in the middle two. Full autonomy is rare in production, and for good reason: the model will occasionally be confidently wrong, and the further the dial turns, the more expensive that mistake gets. Something that only drafts is cheap to get wrong. Something that sends money or deletes data is not.

Coding assistants are a good illustration. They edit files freely, because files sit in version control and a bad edit is one command away from being undone. They ask before running risky commands, because a shell can't be rolled back so easily. The permission model follows the reversibility of the action.

Why agents are harder than they look#

The demo always works. The trouble shows up at volume.

Errors compound. Suppose each step in a run succeeds 95 percent of the time. That sounds excellent. Across ten steps, the chance that every step goes right is about 60 percent. Across twenty it drops to roughly a third. Long runs need error recovery, not just good luck.

Cost and latency multiply. Each loop iteration is another model call, and later calls carry the whole conversation so far. A task that a single prompt handles in two seconds can take a minute and cost many times more as an agent. Techniques like prompt caching help, but the shape of the problem stays the same.

Debugging is odd. With ordinary code you read a stack trace. With an agent you read a transcript: what it saw, what it decided, why the next call looked reasonable at the time. If you don't log that transcript, you can't fix anything.

Failures look plausible. A crashed program is obvious. An agent that quietly did 90 percent of the job and reported success is not. You need checks that don't rely on the agent's own account of what happened.

None of this means agents are a bad idea. It means the engineering around the model deserves as much attention as the model.

When you actually need one#

Reach for an agent when most of the following are true:

• The task is open-ended. You can't list the steps in advance because they depend on what turns up.
• The number of steps varies a lot from one run to the next.
• You can check the result with something outside the model: tests, a schema, a rule, a human glance.
• Mistakes are recoverable, or a person approves the risky parts.
• The task is worth the extra cost. A hundred dollars of tokens to save a minute of work is a bad trade.

Stick with a plain prompt or a workflow when the steps are known, when latency matters, or when you need identical behavior every time. Invoice extraction, classification, summarization, and most content transformations fall here. A single well-written prompt beats an agent on speed, cost, and reliability for these jobs.

A middle path is common and underrated: a workflow with one agentic step inside it. Your code handles intake, routing, and delivery. The model gets loose only in the part of the job that truly needs judgment.

What "multi-agent" means#

You'll also hear about multi-agent systems. That's just several agent loops that hand work to one another, often with one coordinating and the others specialized. They can help when a task splits into independent pieces or when one context window can't hold everything. They also multiply cost and add coordination bugs. It's a topic of its own, and multi-agent systems gets a full treatment later in this series.

Where agents show up today#

The label gets stuck on everything, so it helps to know where the real ones live.

Coding. This is the most mature category. The agent reads a repository, edits files, runs tests, and iterates until they pass. It works because the environment gives constant, objective feedback: the compiler and the test runner don't care how confident the model sounds.

Research. An agent searches, reads sources, follows references, and assembles a report. Quality depends heavily on how well it checks its own sources, which is why research agents tend to include citations and a review step.

Support and operations. Triage a ticket, look up an account, draft a response, escalate when unsure. These usually run with a human approving anything customer-facing.

Data chores. Clean a messy spreadsheet, reconcile two exports, fill in missing fields from public sources. Tedious for people, well suited to a loop that can inspect its own output.

Browser and desktop tasks. The agent looks at a screen and clicks. It's impressive and still slower and flakier than an API call, so treat it as the option of last resort when no API exists. There's more on that in computer use and browser agents.

Notice the pattern: the wins come where feedback is fast and mistakes are cheap.

Three myths worth dropping#

"More autonomy is always better." It isn't. Autonomy is a cost you pay for flexibility, and you should pay only as much as the task demands. A human approving one step out of ten often gives you ninety percent of the value with a fraction of the risk.

"A smarter model removes the need for engineering." Better models do make agents more reliable, and each release moves the line of what's feasible. They don't remove the need for good tools, clean context, limits, logging, and tests. If anything, a more capable model makes it tempting to skip those, right up until the first expensive surprise.

"Agents replace workflows." They sit alongside them. A well-run system usually has a workflow skeleton that handles the predictable 80 percent and lets an agent loose on the rest. Teams that try to make everything agentic tend to rediscover the value of a fixed pipeline the hard way, usually after the invoice arrives.

How to talk about agents with your team#

Vague language causes bad projects. When someone says "let's build an agent for this," ask them to fill in a short template: what is the goal, what tools does it need, what does done look like, how will we know it worked, and what's the worst thing it could do. If they can't answer the last two, the project isn't ready, however good the demo looked.

It also helps to agree on vocabulary early. Use "workflow" for fixed paths, "agent" for model-directed ones, and "tool" for anything the model can call. Half of the arguments in this space are people using the same word for different things.

How to start small#

If you're building your first one, keep the scope tight.

1. Pick one narrow task with a clear finish line. "Triage new GitHub issues into labels" beats "manage my project."
2. Give it two or three tools, not twenty. Each extra tool is another way to get confused. Designing tools covers what makes a tool easy for a model to use.
3. Cap the loop. Set a maximum number of steps so a confused run stops instead of spending your budget.
4. Log every step: the prompt, the model's choice, the tool input, the tool output. You'll want this within the first hour.
5. Add one external check. A test, a validation rule, a diff a human reads.
6. Measure before you expand. Run twenty realistic tasks, count the successes, read the failures. Then decide what to add.

If you'd like a working starting point, building your first agent with the Claude API has a complete example you can run and modify.

The short version#

An agent is a model in a loop with tools, where the model chooses the path. It's the right shape for open-ended, checkable, recoverable work, and the wrong shape for anything you could write down as a fixed recipe.

That definition will survive the next round of product names. When someone announces a new "agentic" feature, ask three questions: what tools can it call, who decides the next step, and what stops it. The answers tell you more than the marketing does.