How to build an AI agent that works in production

To build an AI agent you give a language model three things: a set of tools it can call, a connection from those tools to your real business data, and a loop that keeps calling the model until the task is done or a limit stops it. Everything else in a working agent is constraint, and if you want the definition itself before the build, what an AI agent is, part by part covers it.

The model is the easy part. The constraints are the build.

This guide is written for the person who has been asked to make one work: the operations lead, the head of digital, the founder who wants to know what they are buying. It covers when an agent is the wrong answer, the three ways to build one, the steps in order, the five ways agents fail in production, and what a build costs in Dubai.

Does this task actually need an agent?

An agent is only justified when the model has to decide what to do next. If the sequence of steps is fixed, you do not have an agent problem, you have an integration problem, and a plain workflow will be cheaper, faster, and easier to debug.

The test we use: draw the process as a flowchart. If you can finish the drawing, build the flowchart. Agents earn their extra cost and their extra failure modes in three conditions:

• The input is unstructured. Free-text email, a scanned invoice, a WhatsApp message. Something has to read it before anything can route it.
• The path varies case by case. Looking something up sometimes, escalating other times, and needing a second lookup only when the first one is ambiguous.
• The rules change faster than you can ship them. If a rules engine would need editing every month by someone who does not write code, a model reading the current policy is the better shape.

Email triage is the clearest example of all three at once, which is why it is the workflow we get asked about most. We wrote up how an email triage agent is put together separately. Invoice matching, quote generation, and first-line support qualification tend to have the same shape.

What does not need an agent: moving a record from one system to another, sending a notification when a deal closes, generating a report on a schedule. Those are integrations. Adding a model to them adds cost and a new way to be wrong.

What are the three ways to build an AI agent?

There are three, and they differ less in what they can do than in who can maintain them and how you find out when they are wrong.

The numbers behind those rows, checked against the vendors' live documentation:

No-code platforms meter by activity, not by message. On Zapier Agents, an activity is any billable action the agent takes: firing a trigger, answering from a knowledge source, running an action, browsing or scraping a page, or performing a web search. The Free plan allows 400 activities a month with a limit of 10 activities in a single run; Pro allows 1,500 a month with 40 per run. When a run hits the per-run limit it stops and asks you before continuing. (Verified July 2026.) That per-run cap is the one to check first, because a research-style agent that reads five records before deciding burns through it quickly.

Frameworks give you the loop and a step ceiling. n8n's AI Agent node needs a chat model and at least one tool sub-node connected to it, and its Max Iterations option defaults to 10 model runs per response. Since version 1.82.0 all AI Agent nodes run as the Tools Agent. (Verified July 2026.) LangGraph enforces the same idea in code: recursion_limit defaults to 25, and exceeding it raises a GraphRecursionError rather than looping forever. You raise it by passing a config, for example recursion_limit set to 1000. (Verified July 2026.) Both defaults exist for the same reason, and you should know the number before you go live rather than after.

Custom code means you write the loop against the model API directly. With the Claude API you send a tools array, the response comes back with stop_reason of tool_use and one or more tool_use blocks, your code executes them and sends the outputs back as tool_result blocks carrying the matching tool_use_id, and the loop repeats. (Verified July 2026.) That is the entire mechanism. It is less work than it sounds, and it is the reason a custom agent can be debugged with a stack trace.

The decision here follows the same logic as the older Zapier versus custom integration question: capability is rarely the deciding factor, ownership and failure handling usually are.

How do you build an AI agent, step by step?

In order, and none of these are optional in a system anyone depends on:

1. Write down the decision. Name the one decision the agent makes and what a correct answer looks like, in the words of the person who makes that decision today.
2. Confirm it needs an agent. If the steps are fixed, build a workflow instead and stop here.
3. Define the tools and their schemas. Every action the agent can take becomes a named function with a typed input schema and a description that says when to call it.
4. Ground it in your business data. Give the agent tools that read live records from your systems rather than pasting a document into the prompt.
5. Write the orchestration loop. Call the model, execute any tool calls it returns, send the results back, repeat until it answers or a limit stops it.
6. Set guardrails. Cap the iterations, cap the spend, allowlist the actions that write data, and make every write idempotent.
7. Build the escalation path. Decide what happens when the agent is unsure or a tool fails, and route that to a named human queue with an owner.
8. Evaluate before you trust it. Score it against a labelled set of real past cases, then run it in shadow mode next to the human doing the job.
9. Deploy and watch it. Log every tool call with its inputs and outputs, alert on the failure modes below, and review the escalation queue weekly.

The rest of this article is the detail behind steps three to nine.

How do you define the agent's tools?

A tool is a function the model can ask you to run. In the Claude API each one carries three fields: a name, a description, and an input_schema describing its parameters in JSON Schema. (Verified July 2026.) The other model APIs use the same shape under different names.

Two things decide whether tools work, and neither is the code.

The description is the trigger, not the summary. Anthropic's documentation is explicit that with the default tool_choice of auto, the model decides on each turn whether to call a tool, and that this boundary is steerable through the prompt. (Verified July 2026.) So a description that says what the tool does ("Looks up a customer") gives the model less to work with than one that says when to call it ("Call this when the message references an existing customer by name, email, or account number"). Most agents that "do not use their tools" have descriptions written for the developer rather than the model.

Constrain the inputs at the schema level. Mark required parameters required, use enums where the set of valid values is fixed, and turn on strict schema conformance if the API offers it. In the Claude API that is a strict flag of true on the tool definition, which guarantees the tool call matches your schema exactly. (Verified July 2026.) You can also set disable_parallel_tool_use to true if you want at most one tool call per turn, which makes an agent slower and much easier to reason about while you are still building it. (Verified July 2026.)

Keep the tool set small. An agent with 6 well-described tools is more reliable than one with 30, because every additional tool is another thing to confuse with a neighbour.

How do you ground the agent in your business data?

By giving it tools that query live systems, not by pasting your data into the prompt. Prompt-pasted data is stale the moment it is written, it has no permission model, and it grows until it costs real money on every single call.

What that means in practice:

• Return records, not prose. A tool that returns the invoice row with its ID, amount, due date, and status gives the model something to reason over. A tool that returns a paragraph describing the invoice gives it something to misread.
• Filter by permission inside the query. The agent should be issuing a query scoped to the requesting user, not receiving everything and being asked to be discreet. A prompt instruction is not an access control.
• Return the count with the page. If the underlying API paginates, the tool should say how many records exist in total, not just hand over the first 20. This one line prevents the third failure mode below.
• Say when the data was read. A timestamp on the tool output lets the agent, and later you, tell the difference between "no open invoices" and "the billing system was down".

Document search sits on the same principle. If the agent needs to answer from policies, contracts, or product documentation, retrieval belongs behind a tool the agent chooses to call, so that you can log what it retrieved and check whether the answer actually came from there.

What does the orchestration loop actually do?

It is a while loop with four moves. Send the conversation and the tool definitions to the model. If the response asks for tools, execute them. Send the results back, each one tagged with the ID of the call it answers. Repeat until the model returns an answer instead of a tool call, or until a limit fires.

Three details that matter more than they look:

A single turn can request several tools at once. Execute them, then return all of the results together in one message. Splitting them across separate messages degrades the model's willingness to batch calls in future turns, which makes every subsequent run slower and more expensive.

A failed tool is still a result. Return an explicit error rather than silently dropping the call, so the model can react to it. The Claude API has an is_error flag on the tool result for exactly this. (Verified July 2026.) Dropping the result instead leaves the model waiting on an answer that never arrives.

The loop is where the cap lives. Every framework enforces one because every unbounded agent eventually loops. If you write the loop yourself, you write the cap yourself.

What guardrails does an AI agent need?

Five, and they are cheap to add at build time and painful to retrofit:

• An iteration cap. Frameworks default to a small number for a reason: n8n's node defaults to 10 model runs, LangGraph's recursion limit to 25. (Verified July 2026.) Pick your own number, then log every run that hits it, because a run that hits the ceiling is a run that did not finish.
• A spend cap. Per run and per day. An agent in a loop is a billing incident before it is an outage.
• An allowlist for writes. Reads can be liberal. Anything that creates, updates, sends, or pays should be an explicitly named tool, and destructive actions should require a confirmation step rather than being available by default.
• Idempotency on every write. Agents retry. If the same tool call can fire twice, it will, and your customer gets two invoices. Idempotency keys make the retry harmless.
• A dry-run mode. The same agent with every write tool replaced by a logger. This is what lets you evaluate it honestly, and what you turn on first when something looks wrong in production.

When should the agent hand off to a human?

Escalation is a feature, not a fallback, and it needs to be built with the same care as the happy path. Design it to fire on four triggers:

• The agent's own confidence is low, or it produced an answer it cannot support with a tool result.
• The case crosses a value threshold you set. Refunds above a certain amount, contracts, anything a regulator would ask about.
• The input does not match any category the agent was evaluated on.
• A tool failed and the retry also failed.

The handoff itself has to land somewhere real: a named queue, a named owner, a response time, and the full context of what the agent already tried. An escalation that arrives as a notification into a shared channel with no owner is an escalation that will be missed, and the whole point of the escalation path is that it is the safety net under everything else.

Track the escalation rate from day one. It is the single most useful number an agent produces. If it climbs, something upstream changed. If it falls to zero, the agent has probably stopped escalating things it should.

How do you evaluate an AI agent before you trust it?

With a labelled set of real past cases, scored per decision, before it is allowed to write anything. In order:

1. Collect real cases. Between 50 and 100 actual past inputs, chosen to include the awkward ones, not just clean examples. If you only test on the easy cases you have measured nothing.
2. Have the current human label them. The person who does this job today writes down the correct answer for each. This set is the asset. It outlives the model, the framework, and the prompt.
3. Score per decision, not per conversation. "The agent handled it well" is not a measurement. "It chose the right tool in 47 of 50 cases and the right routing in 44" is.
4. Run it in shadow mode. The agent processes live traffic and records what it would have done, while the human continues to do the work. Compare daily. This is where you find the failure modes that no test set predicted.
5. Then let it act, narrowly. Start with the highest-confidence category only, keep everything else escalating, and widen from there.

Re-run the evaluation set every time you change the prompt, add a tool, or change model version. Prompt edits are code changes, and an unversioned prompt is an untested deployment.

How do you deploy and monitor an agent?

Deployment is the easy half. The monitoring is what determines whether you find out about problems from your dashboard or from a customer.

Log, for every run: the input, every tool called with its arguments and its output, the number of loop iterations, the input and output token counts, and the final action taken. Store it where you can query it. Most agent debugging is answering "which tool did it call, and what came back" and that is unanswerable after the fact unless you wrote it down.

Then alert on four things: runs that hit the iteration cap, tool error rate, escalation rate moving in either direction, and median cost per run. Not total cost, which grows with volume and tells you nothing. The median is what tells you the agent's behaviour changed.

Where this breaks

Five failure modes, all of which we have had to design around. None of them announce themselves. Four out of five produce a confident, plausible, wrong answer, which is why the catch column matters more than the failure column.

What does it cost to build an AI agent in Dubai?

Our published bands run AED 10,000 to 50,000 depending on how many systems the agent touches, which is roughly USD 2,700 to 13,600 at the pegged rate. The full band table, with the scope and the indicative timeline behind each number, sits in what AI agent development costs in Dubai.

Model usage is billed separately and usually surprises people by being small. Published Claude API prices in July 2026: Claude Opus 5 at USD 5 per million input tokens and USD 25 per million output tokens, Claude Sonnet 5 at USD 2 and USD 10 under introductory pricing through 31 August 2026 and USD 3 and USD 15 after that, and Claude Haiku 4.5 at USD 1 and USD 5. Opus 5 and Sonnet 5 carry a 1M token context window; Haiku 4.5 carries 200k. (Verified July 2026.)

Illustrative arithmetic, not a measurement: an agent run that sends 20,000 input tokens and generates 1,000 output tokens on Sonnet 5 at the introductory rate costs 20,000 x 2 / 1,000,000 = USD 0.04 in input plus 1,000 x 10 / 1,000,000 = USD 0.01 in output. About USD 0.05, or under AED 0.20 per run. Ten thousand runs a month is roughly AED 1,800. That is the shape to sanity-check your own estimate against, using your own token counts.

Two levers move that number. Prompt caching bills cache reads at 0.1x the base input price, with a 5-minute cache write at 1.25x, so it pays for itself after a single reuse. The Batch API is 50% off both input and output for work that does not need to be immediate. (Both verified July 2026.) Neither helps if your agent has no repeated prefix and no batchable work, which is why measuring per-run tokens comes before optimising them.

If you want the commercial detail rather than the build detail, our AI agent development service page covers scope, engagement shape, and what the retainer includes.

Should you build an agent or buy one?

Buy, or rather rent, when the task fits a shape the platform already supports, your volume sits inside the plan limits, and nobody loses money when the agent is wrong. That describes most first agents, and starting on a no-code platform for two weeks is the cheapest possible way to find out whether the workflow was worth automating at all. A meaningful share of agent ideas do not survive contact with real inputs, and it is far better to learn that for the price of a monthly subscription than for the price of a build.

Build when at least one of these is true: the decision logic depends on your own rules and needs a test suite and a review history; a wrong answer costs money, a customer, or a compliance obligation; the run is longer than the platform's per-run activity cap; or the agent needs to reach a system with no connector. Those are the conditions where ownership stops being an abstraction, and they are the only honest reasons to spend AED 10,000 or more.

What should not decide it is the subscription bill. At the volumes most UAE businesses actually run, a custom build does not pay for itself out of platform fees, and any vendor telling you otherwise has skipped the arithmetic. Build for testability, for failure handling, and for owning the logic. Those are worth paying for. Saving a plan fee is not.

And if the flowchart finished, do not build an agent at all.