Building AI Agents That Work in Production

An agent completing a demonstration shows that a workflow is possible. Running that workflow for a business adds different questions: what happens when an input is incomplete, a tool fails, or an action would be expensive to undo?

Those questions belong in the design before the agent starts changing records or communicating with customers.

Decide Whether the Task Needs an Agent

An agent can use a language model to choose steps and tools as it works toward a goal. A workflow can instead follow a predefined sequence, with AI used only for a specific task such as interpreting a document.

Anthropic’s Building effective agents recommends starting with the simplest approach that meets the need and adding complexity when justified. It distinguishes predefined workflows from agents that direct their own tool use, and notes the tradeoffs in cost and latency.

A complex business process does not automatically require multiple agents. Compare a single model call, a fixed workflow, or one agent before adding coordination between several agents.

Test the Whole Task, Not Just Individual Steps

Consider an illustrative calculation: if ten steps each succeed independently with a probability of 95%, and all ten must succeed with no recovery, the chance of complete success is 0.95 raised to the tenth power, about 60%.

That is a mathematical example, not a measured agent failure rate. Real steps can have correlated errors, and checks or retries can change the result. The practical point is to measure successful completion of the whole task on representative inputs.

Keep ordinary calculations, date formatting, and exact record lookups in conventional code where possible. Test the model’s contribution where interpretation is actually needed.

Plan for Failures and Duplicate Actions

Tool calls can time out, return incomplete data, or succeed without the caller receiving a confirmation. A retry policy needs to distinguish those cases.

Retrying a read is different from retrying an order submission. Use duplicate protection and check the recorded outcome before repeating a consequential action. Set limits on attempts, elapsed time, and spending so an agent cannot loop indefinitely.

For longer workflows, record completed steps and provide a clear handoff when the system cannot continue. Any fallback model or process needs its own evaluation before it is trusted to produce the same result.

Make Actions Visible and Reviewable

Record the relevant inputs, tool calls, outputs, approvals, and final outcome, with appropriate access and retention controls. Logs should help someone understand what happened without unnecessarily collecting sensitive material.

Track completion rate, correction time, latency, and total operating cost. A workflow that appears successful but creates substantial cleanup work needs that cost included in its evaluation.

Put Approval at the Right Boundary

Define which actions the system may take and which require a person. Creating a draft is different from sending it; preparing an order is different from placing it.

Use concrete checks such as missing fields, source evidence, reconciliation totals, or policy limits to trigger review. A model saying it is confident is not, by itself, a validated measure of correctness.

When staff correct an output, save an appropriate example for evaluation. Improvement requires a deliberate change to the data, instructions, tools, or model, followed by testing. Collecting feedback alone does not automatically retrain the system.

Release One Workflow at a Time

Start with a limited workload and an owner who can inspect the results. Expand when the complete task meets agreed quality and cost targets, including exception handling.

Where to start: To talk through a workflow, its permissions, and what a useful pilot would need to prove, ask about a custom AI tool. For everyday problems like missed calls or backups, our free checks are quicker.