How to build your first AI agent: start with the check, not the model

An agent is a model running in a loop: it decides which tool to use next based on what the last one returned, and it decides for itself when the job is finished.

That separates it from the two things it is usually confused with. A chatbot answers once and stops. A workflow runs a fixed sequence of steps that you chose in advance. An agent chooses the steps.

Anthropic's own guidance on building agents draws exactly that line, and adds the part most tutorials leave out: agentic systems trade speed and cost for better performance on the task, and a great many problems do not need one at all. Deciding whether you need an agent is the first decision, and "no, a single well-written call will do" is a common and correct answer.

Not an assistant that runs your business. A task with a clear start, a clear end, and a result you can check in about a minute: sorting a support inbox into three piles, pulling one figure out of twenty PDFs into a spreadsheet, drafting a reply from a template and your calendar.

The reason is feedback, not modesty. You already know what a good result looks like, so you will notice when it is wrong. An agent doing work you do not understand yourself is an agent you cannot supervise, and an unsupervised first agent is how people conclude that agents do not work.

One paragraph. What goes in, what comes out, and the three ways the result could be subtly wrong while still looking fine.

This is the step almost everyone skips, and it is the one that decides everything after it. That paragraph becomes three things at once: the instructions you give the agent, the condition it uses to decide it has finished, and the test you use to decide whether it worked.

If you cannot write the paragraph, you do not have an agent problem. You have a definition problem, and no model will solve it for you, because a model asked to do something undefined will cheerfully define it itself and you will not like its definition.

Every tool is another way for the agent to be wrong. Start with the minimum that completes the task, often just one thing to read and one place to write, and add a tool only once you have watched it fail for lack of it.

The descriptions of those tools are the real prompt. The model decides what to call almost entirely from each tool's name and description, so a vague description turns every decision into a guess. Anthropic's guidance makes the same point, arguing that tool definitions deserve as much engineering attention as the main instructions do.

Design them to be hard to misuse. Take a customer ID rather than a customer name that might match three people. Return a clear error rather than an empty result the agent will read as "nothing found". Small choices like these prevent more failures than any amount of prompt rewording.

When AI produced drafts, checking was free because it sat in the path: you could not send the thing without reading it. An agent that acts removes that step. A finished action arrives as a notification, and people acknowledge notifications rather than audit them.

So your first agent should either only read, or write to somewhere a person approves before anything leaves: a draft folder, a staging sheet, a queue.

Anything that sends, pays, deletes, publishes or commits gets an approval step, even when the agent is right nine times out of ten. Especially then, because that is exactly when people stop looking. Loosen it later, one action at a time, when you have evidence it is safe.

Collect ten to twenty real examples from your own history, each paired with the answer you would accept. That is your evaluation set, and it is the most important thing you will make.

Run the agent against all of them every time you change the instructions or a tool. Without it you are tuning by feel: you fix the case in front of you and silently break three others you are no longer looking at, which is how agents get worse while everyone believes they are improving.

Keep every failure and add it to the set. A growing list of cases the agent got wrong is the most valuable thing the whole project produces, because it is the only honest record of what the agent can and cannot do.

A surprising number of tasks people build as agents are fixed sequences in disguise. If the steps are the same every time, write them down as steps, and use the model only at the points where judgement is actually needed.

Give it the loop, the freedom to choose its own steps, only once the path genuinely varies from case to case and a fixed sequence keeps breaking. Anthropic's guidance notes that the most successful implementations it has seen used simple, composable patterns rather than elaborate frameworks.

The asymmetry is worth remembering. You can always give an agent more autonomy later. Winning back trust after it did something expensive on its own is much harder.

Less than you would think depends on this. The major model providers all offer tool calling and a way to run an agent loop, Anthropic among them with its Agent SDK, and no-code automation tools can handle the workflow version from step 6 without any code at all.

Pick whatever your team can actually debug when it goes wrong at four in the afternoon. The first five steps decide whether the agent is any good; the framework mostly decides how pleasant it is to fix.

Look back over the six steps and only one of them involves much software. The rest are writing down what done looks like, deciding what the agent may touch, and building a way to tell whether it worked.

That is the same skill as delegating to a person well: a clear brief, a definition of done, sensible limits on what they can do without asking, and a way to check the work without redoing it.

Which is why the people who build good first agents are very often the people who were already good at handing work to others. The model is new. Knowing what you are actually asking for, and being able to tell when you did not get it, is not.