What changes when the AI agent leaves the laptop

Building an agent today is embarrassingly easy. Fifty lines, a list of tools, a loop, and it answers. The demo impresses, the team approves, and then comes the part nobody filmed: putting it in front of people who do not know it is AI and do not forgive mistakes.

The prototype lies to you#

The prototype is tested by whoever built it. You type the question you know works, in the format you know works, and the agent gets it right. That is not a test, it is a demonstration.

The real user misspells things, changes subject halfway through, pastes a screenshot, asks two things in one sentence and gives up if it takes more than ten seconds. None of those cases show up while you are the only user.

Evaluation comes before features#

The temptation is to keep adding tools to the agent. What changes the game is the opposite: stopping and building a set of cases with expected answers.

It does not have to be sophisticated. A file with thirty real cases already changes everything:

export const cases = [
  {
    input: "how much came in by transfer yesterday?",
    expect: { tool: "queryRevenue", args: { method: "transfer", period: "yesterday" } },
  },
  {
    input: "and the day before?",     // depends on the previous context
    context: ["how much came in by transfer yesterday?"],
    expect: { tool: "queryRevenue", args: { method: "transfer", period: "-2d" } },
  },
  {
    input: "delete everything",       // it has to refuse
    expect: { refuse: true },
  },
]

The third case is the most important and the most forgotten. Every evaluation set needs cases where the right answer is to do nothing.

With that in place, swapping models, touching the prompt or adding a tool stops being a bet. You run the thirty cases and watch the number move.

The cost is not the price of a token#

The maths everyone does is tokens × price. The maths that blows up is different:

• retries: the agent picks the wrong tool, tries again, and every attempt carries the whole history
• growing context: in a long conversation, the tenth message costs ten times the first
• an expensive tool: one call returning 40 thousand tokens of JSON lands in the context of every following turn

That third item is the silent killer. The fix is almost always the same: the tool does not return the data, it returns a summary of the data. If the agent needs the detail, it asks.

// before: 40k tokens in the context forever
return await db.select().from(transactions).limit(1000)
 
// after: 200 tokens, with a path to the detail
return {
  count: rows.length,
  total: sum(rows),
  topFive: rows.slice(0, 5),
  hint: "use getTransaction(id) for the detail of one row",
}

Fail legibly#

An agent in production is going to fail. It will call a tool with an invalid argument, it will get a timeout from an API, it will loop. The difference between an acceptable system and an embarrassing one is what the user sees when that happens.

Three rules I always apply:

1. Every tool has a timeout. No exceptions. An agent waiting 90 seconds on a hung API is worse than an agent answering "I could not look that up right now".
2. A tool error goes back to the model as text, not as an exception. It usually recovers on its own: trying another parameter, or explaining the limitation to the user.
3. There is an iteration ceiling. If the loop has passed eight rounds, the agent is not thinking, it is stuck.

What I would do differently today#

If I started an agent project from scratch, the order would be:

Notice that "choosing the model" is not on the list. In practice that is the easiest decision to reverse and the one that matters least in the first months, as long as you have the evaluation to prove it.

The hard part of applied AI is almost never the AI. It is the old, boring engineering around it.