Why Your First AI Agent Should Be Ugly

The first version of an agent should embarrass you a little.

Not because quality does not matter, but because at the start you do not yet know what quality means for the job. You have a guess. The guess is usually wrong in a specific, predictable way: you have overestimated how hard the reasoning is and underestimated how messy the inputs are.

What actually goes wrong

Ask a team to build an agent and they will spend the first three weeks on the model, the prompt and the tone of voice. Then it meets production and fails on things that have nothing to do with any of that.

A customer writes "my order hasn't arrived" and the system has three different records under three different email addresses. A document is a scan of a fax of a PDF. A policy was superseded in March and both versions are still in the knowledge base. None of these are model problems. All of them sink the agent.

You cannot discover any of this by thinking about it in a meeting. You discover it by shipping something and reading the traces.

Ship it dumb, instrument it hard

The trade we make is deliberate. Version one is allowed to be narrow, slow and slightly unimpressive in conversation. It is not allowed to be silent.

That means every run records what came in, what the agent decided, which tools it called, what came back, and whether a human touched it. Boring, structured, complete. That log is the actual deliverable of the first sprint. The agent is just the instrument you built to generate it.

Then you do the thing nobody wants to do: you read a hundred of them. Not a dashboard, not an average score. A hundred actual runs. Within about thirty you will find the failure you did not predict, and it will not be the one you built a guardrail for.

Widen the boundary only where it was earned

An agent with a job description has a boundary: what it may decide alone, what must be escalated, what it must never touch. The temptation is to set that boundary from intuition at the start and then defend it.

Set it tight instead. Let the agent handle one slice with a human reading everything. When the logs show it handled two hundred of those in a row without a bad call, widen it. Evidence, not optimism.

This is slower for about three weeks and dramatically faster for the following six months, because you skip the phase where everyone argues about what the agent should be allowed to do and instead look at what it has demonstrably done.

The ugly version is the honest version

A polished demo hides the boundary question, and the boundary question is the whole job. The moment a polished agent makes one confident wrong call in front of a customer, you lose the room and the project.

An agent that says "I am not sure, here is what I found, a person is looking at it" is less impressive in a board meeting and much harder to kill.

Setting that boundary, and then moving it on evidence rather than optimism, is most of what an AI agent build actually consists of.