A refund request hits your inbox at 2:14am. A competent AI agent reads it, pulls the order from your database, checks that the purchase is inside the refund window, issues the money back, and logs why. A useless one writes a warm apology and hands the whole thing to a human at 9am.
That difference isn’t the model, and it isn’t prompt magic. It’s the scaffolding around the model: the tools, the stopping rules, the error handling. Most of it you can build in an afternoon once you scope the job properly.
Pick One Job With a Finish Line
“Answer customer questions” is not a job. “Look up an order and tell the customer where it is” is. The first can’t fail in a measurable way, so you can never improve it. The second fails loudly and often, which is exactly what you want in week one.
A job worth automating has three properties. The input arrives in a predictable shape: an email, a form submission, a webhook payload. The output can be checked automatically: a refund ID, a ticket tag, a new database row. And at least one tool already exists to do the hard part. Miss that third one and you’re not building an agent, you’re building an integration first.
Write the success condition down before you open an editor. Something like: “Given a support email, either issue a refund and reply with the transaction ID, or tag it for a human, within 30 seconds.” That sentence will settle a dozen arguments later.
The Four Parts Every Agent Needs
Strip out the vendor branding and every agent that survives contact with real users has the same four components bolted together.
- A model that can call functions. Frontier models handle this well, but a smaller, cheaper one often does the job once the prompt is tight.
- Tools: the actual functions it can run. Order lookup, refund API, ticket tagging, a calendar read. Each needs a clear name, a description, and a return value the model can reason about.
- State: what it remembers within a task. Sometimes that’s just the message history; sometimes it’s a scratchpad of findings like the customer’s order ID and account tier.
- A loop that lets the model look at a tool’s output and decide what to do next.
The loop is where most first builds die
Without a stopping condition, an agent will retry the same failing API call until you notice the bill. Cap it. Six to eight iterations covers the overwhelming majority of support, research, and ops tasks. Past that, force an escalation to a human rather than letting it keep spinning.
Keep a step counter next to your state object and check it at the top of every loop iteration, not the bottom. By the time you check at the bottom, the bad call has already gone out.
Choosing a Stack Without Burning a Week
Three tiers, honestly. No-code platforms like Zapier get you a working agent over a lunch break if the job is mostly moving data between apps and writing something sensible at the end. Self-hosted n8n gives you the same visual approach with your own credentials and no per-task pricing. Code, meaning the OpenAI or Anthropic SDKs plus a plain while loop, gives total control and total responsibility.
If you want the no-code route end to end, these two working examples of building your first Zapier AI agent walk through complete builds with every step named. For something closer to real operations work, this guide to an n8n agent that triages support tickets shows how the routing logic fits together.
Write the System Prompt Like a Job Description
Vague prompts produce vague agents. A decent system prompt for a task agent runs 200 to 400 words and covers four things: what the agent owns, what it explicitly does not own, which tools exist and when to reach for each, and the exact shape of the final answer.
Two habits pay off immediately. Give it at least three worked examples, one clean case, one ambiguous case, one it should refuse. Then spell out the refusal in plain language. “If the order is older than 30 days, do not issue a refund; tag the ticket POLICY_EXCEPTION” outperforms any amount of “be careful” instruction.
Keep prompts in version control. You will edit them weekly, and the day a refund path breaks you’ll want to know which change did it.
Give It Four Tools, Not Fourteen
Tool selection accuracy drops as the menu grows. Start with the smallest set that can complete the job, and write each description as a sentence about when to use it rather than what it does internally.
“Use this to issue a refund. Only call after confirming the order is in date and the amount is under $500” is a tool description doing real work. Make write operations idempotent wherever you can. An agent that retries a refund twice is a very expensive bug, and it will happen the first week.
Log every call with its arguments and return value. Nine out of ten debugging sessions end the moment you read that log.
Test With the Inputs You’d Rather Not See
Real inputs are worse than your test set. Voicemail transcripts with no punctuation. Three unrelated questions crammed into one email. An order number that belongs to somebody else. A message in all caps demanding a manager. A customer who replies “yes” to nothing in particular.
Collect 30 real examples, anonymised, and run the whole set every time you touch the prompt. It’s the highest-return habit in agent building, and it’s the backbone of this step-by-step approach to building AI agents that actually finish the job.
Design for the Step That Fails
Your refund API will time out. Your search tool will return nothing useful. The model will call the wrong function with plausible-looking arguments. None of that is exceptional; it’s a Tuesday.
Decide in advance what happens on a tool error: retry once with backoff, then take a fallback path, usually “gather what you have and escalate.” For anything running more than a handful of steps, give the agent a plan it can consult instead of improvising every move. The patterns in multi-step agent chains that finish the job are worth reading before you hand-roll your own.
Ship It to a Slice, Not the Whole Inbox
Run the agent in shadow mode first. It processes live tickets, produces its answer, and a human approves or overrides before anything sends. Two weeks of that hands you a resolution rate, a list of real failure modes, and enough evidence to widen the lane to 10% of traffic, then 50%.
If your organisation already lives in Google Cloud, building a support triage agent in Vertex AI Agent Builder keeps evaluation, logging and deployment in one place instead of four.
The Boring Numbers That Tell You It’s Working
Four metrics, checked weekly: how many tasks the agent completes unaided, how often it escalates, how many loop iterations the average task takes, and cost per resolved task. Record them before and after every prompt change. Without that baseline you’re guessing.
The escalation rate is the one people misread. It should start high and fall slowly as you patch the gaps. An agent claiming a 95% resolution rate in week one is either measuring something flattering or cheerfully doing the wrong thing at scale.
Model choice, framework, temperature, all of that is tuning. Get the job right, give it the smallest set of tools that can finish that job, and cap the loop before it costs you money. The rest is iteration, and iteration is the easy part once the scaffolding holds.