AI Agents in Enterprise Workflows: A Production Checklist

Most teams can get an agent to look impressive in a week. Getting the same agent to behave dependably inside a bank, a ministry or a logistics operator takes a different kind of work. This checklist is the one we use when we review an agent before it goes near real data.

1. Start from a bounded workflow

Pick a task with a clear input, a clear outcome and a known escalation path. "Draft a reply to a supplier query and attach the relevant contract clause" is bounded. "Handle procurement" is not. Write down how people do the task today, including the exceptions, because the exceptions are where agents fail.

Then ask honestly whether an agent is needed. If a rules engine or a fixed sequence of steps covers the task, use it. An agent adds variability, and variability has to be paid for in testing and monitoring.

2. Define what the agent may read and do

List the systems the agent can read from, the tools it can call and the changes it can make. Apply least privilege to each one:

• Give the agent its own service identity, never a shared human account.
• Prefer read-only tools. Add write tools one at a time, each with its own justification.
• Scope data access to the case in hand rather than to the whole database.
• Make irreversible actions, such as payments, deletions or external emails, require explicit approval.

3. Design the tools carefully

Tools are the agent's hands, and poorly designed tools cause most real-world failures. Keep each tool narrow, give it a precise description and validate every argument on the server side as if it came from an untrusted client, because it effectively does. Return structured, concise results so the model is not asked to parse noise. If you expose tools through the Model Context Protocol, apply the same authorisation checks you would on any API.

4. Treat retrieved text as untrusted

Documents, emails and web pages that the agent reads can contain instructions aimed at the model. Separate trusted instructions from retrieved content, strip or flag suspicious patterns, and never let retrieved text widen the agent's permissions. Assume that an attacker can put text in front of your agent and design so that the damage is bounded anyway.

5. Build an evaluation set before launch

Collect real, anonymised examples of the workflow: typical cases, awkward cases and cases where the right answer is to stop and ask a person. Define what "good" means for each, run the agent against them and keep the results. This set becomes your regression test whenever the model, the prompt or a tool changes. We cover evaluations and guardrails in more depth in a separate article.

6. Plan for human review

Decide which outputs are sent automatically, which need a reviewer and which are never automated. Make the review step fast: show the reviewer the agent's proposed action, the evidence it used and a one-click way to correct it. Corrections are valuable training data for your evaluation set.

7. Make behaviour observable

Log every run: the input, the retrieved context, each tool call with arguments and results, the final output and who approved it. You will need this to debug, to answer an auditor and to notice drift. Track cost and latency per run, and set limits on steps and spend so a looping agent cannot run unattended.

8. Manage change like software

Version prompts, tool definitions and model identifiers together. Roll out changes to a small share of traffic first, compare against the evaluation set and keep a quick path back to the previous version. Model providers update models, so pin versions where you can and re-run evaluations when you change them.

9. Check the compliance and data position

Know where data is processed and stored, what leaves your network and under which terms. For regulated data this may rule out some hosted options or require redaction before a model call. Involve security and legal early; late discovery here is expensive.

10. Assign ownership

An agent without an owner decays. Name who monitors quality, who handles incidents, who approves changes and who decides when to switch the agent off. Write the switch-off procedure down and test it.

A short go-live gate

Before launch, confirm that you can answer yes to each of these: scope is written down, permissions are least-privilege, tools validate input, an evaluation set exists and passes, review steps are defined, logging is on, limits are set, rollback works and owners are named. If any answer is no, the agent is still a prototype, and that is a perfectly respectable place to be while you finish the job.