← All field notes

AI Agents in Production: A Roadmap Built Around Control

An AI agent needs a clear job, limited access and a reliable way to handle mistakes. Start with one workflow people can review before expanding its responsibilities.

AISoftwareSecurityArchitecture

An AI agent can do more than answer a question. It can use connected software to look up information, prepare work and take actions. That makes a convincing demonstration fairly easy to arrange. A useful business tool needs more: people must understand what it can change, when it needs help and how to recover when a step fails.

Start with the work you want completed. A narrow, dependable workflow is easier to assess than an assistant expected to handle an entire department.

Define the job and a useful result

Describe the input, the person who needs the result and what a successful outcome contains. Preparing a draft from an approved document collection is specific enough to test. “Help with operations” leaves too much open to interpretation.

Prepare a test collection with routine requests, incomplete information and requests outside the intended task. Review the difficult cases alongside the easy ones. This gives the team a consistent way to compare changes.

Make access match the job

Give the agent access only to the accounts, records and actions the workflow needs. The application should check those permissions whenever a tool is used. Instructions to the model help guide its behavior, but do not replace access controls.

Choose which actions can happen automatically and which need a person to review the proposed change. Consider the cost of a mistake and whether it can be reversed. Keep reading information, drafting a response and changing a record distinct in the interface.

Show what happened

People operating the service need a clear history of its steps, the source used and the outcome. A shared tracking reference, sometimes called a correlation ID, connects related steps when they pass through several systems. Protect sensitive values in that history.

The customer-facing status should be equally clear. “Draft ready,” “request submitted” and “change confirmed” describe different outcomes. Use the one the system has actually established.

Handle interruptions without repeating work

A service can finish an action even when its reply never arrives. Before retrying, check whether the action already completed. For supported services, an idempotency key gives repeated attempts the same reference so they do not create duplicate changes.

Set time, usage and cost limits. If a workflow stops halfway through, retain its confirmed progress and explain what remains. Provide a way for an operator to stop the agent or remove its tool access.

Ask for an operational handoff

Before expanding a pilot, review its errors, correction time and operating cost. Ask for the task definition, test cases, permission map, action history and recovery instructions. Those materials help the people responsible for the workflow decide whether it is ready for a wider role.