Building an AI Agent: From Prompt to Production

Building an agent rarely comes down to the model. It comes down to framing, tools, and how the system behaves when something goes wrong.

Step 1. Frame the task

Three questions before any code.

What counts as done? The answer must be checkable. “Handled the ticket” is not a criterion. “A ticket exists with category and priority filled in” is - a program can verify it.

What must the agent never do? That list becomes missing tools and restricted permissions, not prompt text. A constraint written in a prompt is usually respected, not always.

What happens on failure? Stop and call a human, retry, roll back. Having no answer here is the most common reason an agent behaves strangely in production.

And before all of it: is an agent needed at all? If the process is fully known, a workflow is cheaper and more reliable. The test is in the guide pillar.

Step 2. Choose the tools

Tools define the agent’s ceiling. It will not do what it has no tool for, and it will do anything it has a tool for.

Principles that pay off:

• One tool does one thing. A “manage order” tool with five internal modes is a bad tool: the agent will confuse the modes.
• Descriptions are written for someone who has not seen your system. They must answer when the tool applies and when it does not. This is literally what the model chooses by.
• Dangerous things stay separate. Reads and writes are split. Deletion either does not exist or requires human confirmation.
• Errors come back as text, not exceptions. The agent should read what went wrong and try differently. A silent failure reads to it as success.
• Permissions are minimal. A dedicated database user, only the tables required. This is the only constraint that actually holds.

Step 3. The loop

The loop is simple: the model picks a tool, the system runs it, the result goes back, repeat. The real work is in its bounds.

A step limit. Mandatory. Without it, a looping agent burns money until somebody notices.

An explicit stop condition. The agent called a completion tool, or a checkable criterion was met. “The model said it was finished” is weak, because it will say that halfway through too.

Error handling. Distinguish a transient network error from a logical one. The first is retried with backoff; retrying the second is pointless, since the same input yields the same result.

Idempotency. Every action with an external effect must be safe to repeat - see idempotent pipelines.

Per-step logs. What was in context, which tool was chosen, what came back. Without them incident analysis is impossible: you see the outcome but not why it is that outcome.

Step 4. Test before launch

An agent is non-deterministic, so “ran it once, works” means nothing here.

• The same input several times. Behavioural spread is only visible this way.
• Real data, not invented data. Real tickets contain typos, truncation and empty fields, which is where demos fall apart.
• Tool failures. Check what the agent does when the API returns an error or times out. Usually it turns out to report success.
• Edge cases. Empty input, no data, too much data.
• Cost and step count measured on a real sample. This is where you discover the average task takes twenty steps rather than five.

Step 5. Going to production

An order that removes most of the risk:

1. Observation mode. The agent works and proposes; a human performs the action. A week of this shows the real error rate.
2. A narrow slice. One task type, one client, low volume.
3. Verification before widening. The agent’s report is checked by a program, not read by a person.
4. Monitoring. Step counts, failure rate, cost. Quiet degradation is only visible in numbers.
5. Expansion, only once the first four have held.

Guardrails and verification in more depth: rollout. A concrete walkthrough: step by step. The overview is in the AI agents guide.