What Makes a System an Agent — and When You Don't Need One

An agent is a model plus a harness

An AI agent is a system in which a language model decides, step by step, which action to take next — usually by calling a tool — observes the result, and repeats until it judges the task done. The model supplies the decisions. Everything around the model — the tools it can call, the permissions on those tools, the loop that runs it, the memory it reads, and the checks on what it does — is called the harness. Most of the reliability, cost and security of an agent is decided by the harness, not by the choice of model, which is why building agents in 2026 is largely called harness engineering.

That definition has a practical edge. When an agent fails in production, the cause is rarely "the model isn't smart enough." It is usually one of these: a tool returned an error the model read as success; the loop had no stopping rule; a remembered fact had gone stale; a handoff dropped a constraint; an instruction hidden in a retrieved document was followed. Every one of those is a harness defect, and every one can be fixed without touching the model.

Three systems that get called agents

The word "agent" is applied to almost anything that calls an LLM, which makes it hard to reason about. A useful test is: who decides what happens next — your code, or the model?

System	Who picks the next step	Example	Is it an agent?
Single call	Nobody — there is one step	Classify a support ticket into one of six queues	No
Workflow	Your code, in a fixed order	Retrieve → draft a reply → check the draft against policy	No — a pipeline with LLM steps
Agent	The model, at run time	"Resolve this refund request" — the model chooses which records to look up, whether to issue a refund, and when to stop	Yes

A workflow can be complicated and still not be an agent. What makes something an agent is that the sequence of steps is decided at run time by the model, so two runs of the same request can take different paths. That property is the source of everything useful about agents — they handle cases nobody enumerated in advance — and of everything hard about them: variable cost, variable latency, and a path you can't fully test in advance.

When you don't need one

Most tasks that arrive labelled "build an agent" are better served by one of the first two rows. Before you build a loop, ask three questions:

1. Can you write the steps down? If the correct sequence is the same for nearly every input, write it as a workflow. Code that calls the model at fixed points is cheaper, faster, and far easier to test than a model that re-derives the same sequence on every run.
2. Is the output one of a fixed set of answers? Routing, tagging, triage and extraction are classification or extraction problems. Treat them as a single call with a schema, a labelled evaluation set, and a threshold — not as an agent that "decides where this ticket goes."
3. Would a wrong step be expensive or irreversible? An agent chooses its own actions. If an action moves money, deletes data or emails a customer, you will need confirmation gates, tight permissions and execution-based checks (all covered later in this course). That work is worth doing when the task genuinely needs run-time choice, and wasted when it doesn't.

A good rule: start with the least autonomous design that can do the job, and add autonomy only where a real input needs it. AI401's orchestration lesson made the same argument for frameworks. It applies more strongly here, because every step you let the model choose is a step your tests can't enumerate.

The cases that do need an agent share a shape: the next step depends on what the last step found. "Did the customer who filed the most tickets last quarter renew?" can't be planned up front, because you don't know which customer to look up until the first lookup returns. You met this in AI402's lesson on agentic retrieval; this course generalises it from search to every kind of tool.

What goes wrong, and where this course fixes it

AI coding assistants will produce a working agent in minutes. The code usually has the same gaps, because the gaps are in decisions the prompt never mentioned:

• Tools that return raw API output, including errors wrapped in a success response, so the model loops or acts on a failure (Module 1: the loop, tool design, MCP and skills).
• Memory with no source or date, and compaction that silently drops the constraint the user cared about (Module 2: state and memory).
• A team of agents where one agent with better tools would do, and handoffs that lose facts (Module 3: orchestration).
• Dashboards mistaken for evaluation, and evals that grade the final message instead of what actually changed (Module 4: evaluation and reliability).
• Tools with more permission than the task needs, tool output trusted as if it were instructions, and loops with no budget (Module 5: security and control, ending with a capstone audit of an AI-built agent).

Each lesson is written against those gaps. Most labs run on a small, deterministic mock harness — a scripted "model" and fake tools — so they're free, need no API key, and every bug reproduces exactly, which is what a debugging exercise needs.

The professional skill

You will not write most of your agent code by hand. What you need is the ability to look at an agent — its tools, its loop, its memory, its permissions and its evals — and say which part will fail first, how you'd find out, and what to change. That judgment is what this course builds, and it transfers across frameworks, because frameworks change every few months and harness defects don't.

---

Summary: An agent is a model that chooses its own next action in a loop; the harness is everything around it — tools, permissions, loop, memory and checks — and it decides most of an agent's reliability, cost and security. Use a single call or a fixed workflow whenever the steps can be written down or the output is one of a fixed set; reach for an agent only when the next step genuinely depends on what the last one found.

Next: The agent loop itself — plan, act, observe, decide — and the stopping rules that a model can't be trusted to enforce on its own.