AI engineering

What separates an AI agent demo from a production agent

A demo agent needs to work once, in front of you. A production agent needs to work ten thousand times, unsupervised, including on inputs nobody anticipated. The gap is mostly engineering, not prompting.

Agent demos are easy now. A capable model, a few tools, a well written prompt, and you can build something impressive in a weekend. The impressive part is real. The problem is that the distance between that and something you can leave running is much larger than it looks, and almost none of the distance is about the prompt.

The tool layer is the product

In a demo, tools are thin wrappers over an API. In production, each tool is a small piece of defensive software:

  • A typed input schema, so a malformed model call fails at the boundary with a message the model can recover from, rather than passing garbage downstream
  • Validation beyond the type, checking that the record exists, the value is in range, the action is permitted for this context
  • An idempotency key, so a retried call does not repeat a side effect
  • Least privilege credentials scoped to exactly what the tool needs
  • Structured logging of the call, the arguments, the result, and the latency

Most of the engineering effort in a production agent goes here. It is unglamorous and it is what makes the difference.

Evaluation is not optional

You cannot tell whether an agent got better or worse by trying it a few times. Model outputs vary, and human judgement of quality is unreliable across sessions. Without an evaluation harness you are making changes and hoping.

A workable eval set is smaller than people expect. Fifty to a hundred cases drawn from real history, each with a defined pass condition, gets you most of the value. Score them automatically. Run them before every release. Gate the release on the score.

If you cannot measure whether a change made the agent better, you are not engineering, you are gambling.

Autonomy is earned per case type, not granted globally

The instinct is to ask how autonomous the agent should be, as though it is one dial. It is not. It is a dial per case type, and each one moves independently based on evidence.

The progression we use on every build:

  1. Shadow mode. The agent runs and produces output, a human does the real work, and the two are compared. This costs nothing operationally and generates the eval data you need.
  2. Draft mode. The agent produces the output, a human reviews and sends. Time saved is real, risk is near zero.
  3. Narrow autonomy. Case types where shadow and draft data show high reliability run without review. Everything else still routes to a human.
  4. Widened autonomy. The threshold moves as evidence accumulates, reviewed on a schedule rather than on enthusiasm.

Budget ceilings, in the code

An agent with a planning loop and no ceiling will occasionally find a way to spend a lot of money in a short time. Hard limits on tokens per run, tool calls per run, wall clock time per run, and total spend per day. These are not configuration suggestions, they are enforced in code and the run terminates when they are hit.

The escalation path matters more than the success path

Most of the quality difference a user perceives comes from what happens when the agent cannot do something. A good escalation carries the full context to the human: what was attempted, what was found, what the ambiguity is. A bad one dumps the conversation on somebody who has to start from scratch, which is worse than not having the agent.

Define the escalation triggers explicitly. Anything touching money, anything with a legal or compliance keyword, anything where the confidence signal is below threshold, anything the user has asked for twice.

Observability, because you will need to explain a decision

At some point somebody will ask why the agent did a specific thing on a specific date. You need to be able to answer that with a trace: the input, the retrieved context, the reasoning, the tool calls, the outputs. Store it. The storage cost is trivial compared to the cost of not being able to answer.

Build the trace viewer in week one. You will use it more than any other part of the system.

What this means for timelines

A demo takes days. A production agent takes four to eight weeks, and roughly seventy percent of that time is the tool layer, the evals, the guard rails, and the observability. Anyone quoting you two weeks for a production agent is quoting you a demo.

Written from work we have actually delivered. If your situation looks like the one described here, the quote form takes about two minutes and there is no sales sequence attached to it.

Get a free quote

Same problem, your business?

Describe it in the form. Within 24 hours you get an honest read and, if it is worth doing, a fixed price against a written scope.