What an AI agent actually needs before it reaches production

A demo where a model calls a tool is a weekend's work. Putting the same thing in front of customers, with access to systems that hold money or personal data, is a different engineering problem, and almost none of it is prompt engineering.

Decide what it is allowed to do

The instinct is to give the agent broad access and constrain it in the prompt. But a prompt is a request. The credentials are the permission boundary, so scope them to the task and the question of whether the model can be talked into something dangerous stops being interesting.

In practice this means a separate, short-lived identity per task, with exactly the tools that task needs and no standing access to anything else.

Make consequential actions reversible

Sort every action the agent can take into three buckets: safe to do freely, safe if it can be undone, and needs a person. Most systems only need the middle bucket to be genuinely reversible (a soft delete, a draft state, a queued change) for the whole thing to become far less frightening.

Evaluate it like software, not like a demo

Non-deterministic behaviour does not excuse you from testing; it changes what the test looks like. Build a held-out set of real cases with expected outcomes and run it on every change to the prompt, the tools or the model version.

Without that, you are comparing anecdotes. Behaviour does drift: a model version bump can quietly change how the agent handles an edge case that nobody remembers is important.

Know when the answer is not an agent

A lot of problems described as agentic are a workflow with one uncertain step. If the sequence of actions is known in advance, a conventional pipeline that calls a model for the ambiguous part is cheaper to build, cheaper to run and far easier to reason about when it misbehaves.