Build an agent that does real work

What is an AI agent, actually?

Ask the internet and you get: a tireless digital teammate, working around the clock, across your entire business. Fine. Name one task it finishes on its own, and say who reads the result.

The most usable line I have found is in Anthropic's engineering write-up on building effective agents. Their words: workflows are systems where "LLMs and tools are orchestrated through predefined code paths," and agents are systems where "LLMs dynamically direct their own processes and tool usage."

My reading, in operator terms: an agent is a loop. You give it a goal. It picks a step, a tool runs, the result comes back, it looks at that and picks again. It stops when it decides the job is done, or when you stop it.

So three things have to be true before the word means anything. It chooses its own next step. It acts through tools instead of describing actions. It loops until a stopping condition. Most of what gets demoed as an agent is a prompt with a nice interface and a spinner. The spinner is doing a lot of the work.

What separates an agent from a workflow?

Who decides the order of the steps.

• A workflow: you decided the steps. Step three always follows step two, and the model does one job inside a step.
• An agent: you decided the goal and the legal moves. The order changes per run, because it reads what came back and chooses from there.
• A workflow costs about the same every run. An agent costs whatever it decides to spend, which is why the cap matters.

If you can draw your steps on a napkin and they never change, you want a workflow, not an agent. Set up your first AI workflow covers that build.

Anthropic is blunt about the trade: agents bring "higher costs, and the potential for compounding errors," and the advice is to find the simplest solution and add complexity only when it earns its place. Most agent projects I see die at the scoping table, not at the wiring.

When should you not build an agent?

The section most articles skip, so it goes first. Do not build one when:

• The steps are fixed. Re-deciding the order every run only adds ways to be wrong.
• You cannot describe the finished output in one sentence. If you cannot say what good looks like, neither can it.
• The job is one tool and one call. That is an API call with a prompt on top.
• A quiet mistake would be expensive and nobody will read the output. An agent with write access and nobody checking its output is a risk you are paying for.
• You have never done the job by hand, so you do not know where it goes wrong.
• The real bottleneck is that you have no leads, or no clear offer. An agent will happily research an empty sheet.

How do you scope an agent down to one job?

Four things, and the scope is not done until all four are written: one job, a defined input, a defined finished output, a stopping condition.

Here is the boring, inspectable version. Left is how people first say the idea out loud. Middle is the same idea tightened until it is buildable.

Notice what the right column keeps saying. Narrower input, checkable output, somewhere to put uncertainty, a reason to stop. That is the whole scoping move.

How to build an AI agent: the four parts you must specify

Whatever you build on, you specify the same four things. Running example: an agent that researches an inbound lead and drafts the first follow-up.

1. The goal, written as a finished output

Not "research the lead well". Write the shape of the thing you want on screen: five numbered parts, each either filled or marked as not found. A goal you can inspect is a goal it can hit. A goal you can only feel is one it will confidently claim to have hit.

2. The tools it may use

A tool, in the provider's own terms, is a name, a description, and an input schema saying which arguments it takes. Anthropic's tool use docs show the round trip: the model replies with a tool use block naming the tool and the arguments it chose, your side runs the real operation, and you hand the outcome back as a tool result so it can continue. On a platform like n8n you never write that loop. You attach tools as sub-nodes and the agent picks between them.

Descriptions matter more than people expect. Anthropic says tool design deserves as much attention as prompt engineering, and reports spending more time on their tools than on the overall prompt. My rule from that: the fewest tools that make the job possible, each described as if to a new hire who cannot ask a follow-up question.

3. The context it gets

What it knows before it starts: your offer, who you sell to, the fields in the sheet, three of your own real emails so the drafts sound like a person. Conversation memory (n8n exposes it as a memory sub-node holding prior messages) stops the agent repeating itself. Context stops it being generic. Most weak agent output is a context problem, not a model problem.

4. The guardrails

What it may touch, where a human signs off, what it does when unsure, how long it may keep going. Its own section, below, because that is where the real work lives.

What does the job spec for a real agent look like?

ROLE
You research one inbound lead and draft one first email. You do not send anything.

INPUT
One row: company name, contact name, contact email, website, and the message they left on the form.

FINISHED OUTPUT
A note with exactly these five parts:
1. What the company does, in one sentence, with the page you read it on.
2. Their likely reason for contacting us, quoted from their own form message.
3. Three facts that would make an email feel specific, each with a source link.
4. A drafted email, 120 words or less, in the voice of the three samples provided.
5. A confidence line: high, medium or low, and one sentence saying why.

TOOLS YOU MAY USE
- web_search: find public pages about the company.
- fetch_page: read one page you already have a URL for.
- crm_lookup: read our own record for this email address, if one exists.
You may not use any tool that is not on this list. You have no send tool.
You have no write access to the CRM. If a step seems to need one, stop and say so.

HOW TO WORK
- Read the form message first. It usually states the real reason better than research will.
- Search for the company, then read at most four pages.
- If a fact is not on a page you actually opened, write: not found.

STOPPING
Stop when the five parts are filled, or after eight tool calls, whichever comes first.
If you stop early, return the note anyway and name the parts that are missing.

WHEN UNSURE
If you cannot confirm you found the right company (same name, different business),
stop, return confidence: low, and describe the exact ambiguity.

NEVER
- Never invent a metric, a headcount, a funding round, or a customer name.
- Never state a price, a discount, or a guarantee.
- Never send, schedule, or reply to anything.

Two blocks do most of the work, and they are the two people delete first: the tool list, which says out loud what the agent does not have, and the stopping rules, which include what to do when it is unsure. Without them you get an agent that keeps going and eventually gets creative.

The upstream half, finding the leads that land in that sheet, is its own job. I wrote it up in find leads with AI.

How do you keep an AI agent on rails?

Four questions, in this order. What may it touch. Where does a human approve. What does it do when unsure. How would you find out if it were quietly wrong.

The cheapest guardrail is the tool you never gave it. An agent with no send tool cannot send the wrong email, however confused it gets. That is a design decision, not a setting, and it costs nothing.

The platforms cover the rest. n8n documents an approve tool calls step: for sensitive tools the agent pauses and asks first, you approve or reject, and it continues from where it stopped with your decision. OpenAI's Agents SDK documents guardrails running alongside the agent, on the incoming input and on the final output, with a tripwire that halts the run when one fires. Their docs frame part of the point as not paying a slow, expensive model to work on a request that should never have been accepted.

My reading: approvals for irreversible actions, guardrails for the failures you can predict, a tight tool list for everything you did not think of. Keep the approval point on as few steps as possible, or you have invented a slower way of doing the work yourself.

How do AI agents actually fail?

It loops

It searches, does not find what it wants, searches again in slightly different words, repeats. n8n's Tools Agent node has a Max Iterations option, described in their docs as how many times the model should run to try to generate a good answer, with a small default (ten when I checked). Treat it as a spend limit, not a safety feature. The real fix is in the prompt: say what finished means, and what to do when a fact cannot be found.

It calls the right tool with the wrong arguments

The provider documentation is honest about this one. Anthropic's tool use docs note that when the prompt does not contain enough to fill a required parameter, the model may notice and ask, or it may infer a reasonable-looking value you never supplied. Nothing errors. The lookup runs. The note comes back beautifully written about the wrong company. Countermeasures: mark parameters required, use the strict schema option if your provider has one, and build tools that return no match instead of a best guess.

It half-finishes and reports success

Four parts are real and the fifth is a fluent paragraph covering for a page it never opened. The expensive one, because it does not look like a failure. It looks like output.

How do you find out it has been wrong for a week?

You will not get an alert. Nothing is erroring, the runs are green, the output is fluent. So the check has to be a habit.

1. 1Read three full runs a week, end to end. You want the steps it took, not the answer it landed on. n8n keeps a sessions view with the messages exchanged, the tools used and any pending approvals.
2. 2Keep a rejection log. Every time you rewrite a draft before using it, write one line saying why. After twenty lines, the pattern is the next edit to the spec.
3. 3Make the agent grade itself and sort by that. The confidence line exists so you can filter.
4. 4Spot check the high confidence runs. Low confidence output is already being read. High confidence is where a quiet week of wrong hides.

What does building one really cost you?

Opinion, from my own builds, with no numbers attached to your business because I have not seen your business.

Most of the time does not go into building. It goes into writing the job down precisely enough that something without your judgment can do it. Wiring an agent on a platform is an afternoon. Deciding the finished output, the tool list, and what happens when a page will not load is the week.

Then the cost after launch, which people forget. An agent with write access is a colleague whose work you review, and reviewing is attention. For the first few weeks I would expect review time to be close to the time saved. The return shows up once the spec stops changing.

Every agent I have scoped ended up narrower than the version I started with. Not because the models cannot do more, but because the narrow one is the one I could tell was working.

What to ask before you build anything

The wrong question is what could an agent do for me. Everything sounds plausible at that altitude. The question worth answering: which single job in my week has a clear input, a finished output I would recognise on sight, and a step where I currently decide something that does not really need me?

Say the answer in one sentence before you open any tool. If it comes out with fixed steps, go build the workflow instead and be glad. If you are still picking a first project, start at where to start with AI.

The honest close

Your first agent may not survive contact with real inputs. Mine often do not survive the first twenty rows.

Look at what you are left holding: a one-page spec of the job, the tools it genuinely needs, the permissions on each, the stopping rules, and a log of every time the output was wrong and why. That is the clearest description of that job anyone in your business has written, and it works for a person too.

So, the small application. Take one job from this week and write its five lines: input, output, tools, stopping rule, what to do when unsure. Then ask whether it needs a loop at all. Half the time the answer is no, and you just saved yourself a build.