What it actually takes to run AI agents in production

An agent that impresses in a demo answers one happy-path question. An agent in production answers thousands of real questions — misspelled, angry, ambiguous — and acts on real systems where a mistake has a cost.

The gap between the two is not a better model. It is engineering: scoped permissions, deterministic guardrails, and a clear answer to what happens when the agent is wrong.

Across the agents I run for clients — support, sales qualification, internal operations — the same four layers show up every time.

Start with the agent drafting and a human approving. Measure accuracy weekly. When a category of decisions stays above your threshold for a month, promote it to automatic. Autonomy is earned in production, not granted at launch.

An agent may read a customer email, a retrieved document or a webpage that contains text telling it to ignore its rules. Treat all of those inputs as untrusted information. A document can supply facts for an answer, but it must not acquire the authority to change tool permissions or approval requirements. Prompt wording alone is not a reliable security boundary.

Put permission checks in the system executing each action. A customer-support agent should not gain access to a different customer's order simply because a message contains an order number. Verify the requesting user and scope the lookup before returning data. Keep credentials out of the model's context wherever possible and avoid writing sensitive content indiscriminately into logs.

Build an evaluation set from representative tasks with permission to use the data. Include missing documents, outdated information, conflicting instructions, ambiguous requests and attempts to trigger unauthorised actions. Define the expected behaviour for each case, including situations where the correct answer is a refusal or a request for clarification.

Score different dimensions separately: factual correctness, retrieval quality, tool choice, permission compliance and successful handover. A fluent answer can still be operationally wrong. Re-run the set when you change the model, prompt, tools or knowledge source. Keep a record of the changes so a regression has a traceable cause.

External systems can time out after accepting an action. If an agent retries a payment, booking or message blindly, it can create a duplicate. Give consequential operations a stable request identifier and check their status before repeating them. Let deterministic application logic control the retry policy rather than asking the model to improvise.

A useful fallback tells both the customer and the operator what is known. For example, 'your request has been received and is awaiting confirmation' is different from announcing completion. Keep the item in a visible queue, retain enough context for a person to continue and set responsibility for resolving it. A silent failure is not a safe fallback.

Before release, name the person who owns the knowledge source, the person who responds to incidents and the person authorised to disable tools. Agree on the information each needs. Monitor unresolved tasks, unexpected tool calls, latency and cost alongside answer quality; a technically functioning agent may still be creating work elsewhere.

Start with a limited task and controlled audience. Expand permissions only when evidence supports the change, not after an arbitrary period of good-looking demos. If you need a support or operations agent, the most productive first conversation is about the actions it may take, the information it may see and the decisions that must stay with your team.