How We Build an AI Agent

What an agent is, without the marketing

An agent is a language model that can call functions, in a loop, until a task is done. That is the whole idea. The model decides which tool to call, sees the result, and decides what to do next.

Everything that makes it work or fail in production is in the surrounding engineering: which tools it is given, what it is allowed to do without asking, how failure is detected and what happens when the loop does not terminate.

The four parts that matter

1. Tools. Narrow, well-described functions. get_order_status(order_id) beats query_database(sql) every time — narrow tools are testable and cannot do damage.
2. Boundaries. What the agent may do alone, what needs a human, what it may never do. Written down explicitly, enforced in code, not requested in a prompt.
3. Termination. A step limit, a cost limit and a timeout. Agents that cannot stop are the most common production failure.
4. Observability. Every step logged — what was called, what came back, what it decided. Without this an agent is unsupportable.

A prompt asking the model not to do something is a request. A tool that does not exist is a guarantee. Prefer guarantees.

Where agents genuinely earn their keep

Multi-step tasks where the steps vary by case. If the sequence is the same every time, write a normal program — it is cheaper, faster and deterministic. Agents earn their cost when the path depends on what is found along the way.

• Triaging a support ticket: read it, look up the account, check recent orders, draft a reply or escalate
• Reconciling an exception: find the matching record, check three systems, propose a resolution
• Enriching a lead: search internal history, check the CRM, summarise the relationship
• Investigating an alert: pull the logs, check recent deploys, summarise the likely cause

The approval boundary

Every agent we build has a written list of actions requiring human approval. Typically: anything that spends money, anything a customer sees, anything that deletes, and anything above a value threshold.

Approval is a first-class part of the design rather than a safety net bolted on. The agent produces a proposed action with its reasoning, a person accepts or rejects in one click, and the decision is logged. In practice most approvals take seconds, and the rate at which people click accept is itself a quality metric.

Cost control, which nobody mentions in demos

An agent can call a model twenty times to answer one question. That is fine at ten tasks a day and expensive at ten thousand.

• A hard step limit per task, and an alert when tasks routinely hit it
• A daily spend cap that stops the agent rather than the finance conversation
• Caching for the parts of the context that never change
• Routing simple cases to a cheaper path before invoking the full loop

We instrument cost per completed task from day one. It is the number that decides whether an agent survives contact with the finance director.

How we build one, in order

1. Do the task manually and write down every step and decision
2. Build the tools as ordinary, tested functions — no model involved
3. Confirm a human can complete the task using only those tools
4. Add the model as the thing that chooses between them
5. Run it shadowed against real cases, comparing to human decisions
6. Enable it with approval on everything, then relax the boundaries as evidence accumulates

Step three is the one people skip. If a human cannot do the job with the tools provided, the model certainly cannot, and you will spend weeks blaming the prompt.

Frequently asked questions