# AI Agents in Production: How Businesses Deploy, Evaluate, and Operate Them By Emmett Childs · Updated 2026-10-22 The available evidence describes business agents built around bounded workflows, human judgment, and operational controls. It also shows why “our company uses agents” is an incomplete description: adoption can mean an embedded feature, a pilot, or a system completing work for real users. This guide separates those evidence types and turns the distinction into an operating model. The research is historical evidence with explicit collection periods, checked on 21 October 2026. The engineering procedures below are recommendations, not results from a new benchmark. ## Adoption surveys and deployment studies answer different questions PwC's May 2025 survey of 300 senior executives reports that 79% said agents were being adopted at their companies. That is an executive-reported adoption measure. It does not mean 79% of companies had independently audited autonomous operations, or that the same proportion applies to the wider economy. PwC itself distinguishes embedded productivity improvements from deeper workflow transformation. [PwC AI Agent Survey](https://www.pwc.com/us/en/tech-effect/ai-analytics/ai-agent-survey.html) Measuring Agents in Production, or MAP, examines implementation practices. The study surveyed 306 practitioners and conducted 20 case studies. Its main survey analysis filters to 86 systems in production or pilot phases; the case studies include 14 production deployments and six pilots. The paper reports participation and geographic biases, and individual questions have different response counts. [MAP v3, sections 1 and 3](https://arxiv.org/html/2512.04123v3) These sources are complementary. An executive survey can describe organizational intent and reported uptake. A deployment study can describe how participating teams build and operate systems. Neither supplies a representative global census of agents. ## What the production research suggests MAP describes a preference for controllable designs, off-the-shelf models, and human involvement in evaluation. Reliability is a recurring development problem. Its account is useful evidence about the participating deployments, not proof that a particular workflow length or architecture is optimal for every task. [MAP v3, introduction and findings](https://arxiv.org/html/2512.04123v3) Our interpretation is that an agent should be evaluated as part of a complete operating process. The model chooses actions, but the surrounding system determines what information reaches it, which actions are possible, what persists, and how results are checked. A useful question is therefore not simply “How autonomous is this agent?” It is “Which decisions can this system make, under what conditions, and how do we know the resulting work is acceptable?” ## An operating model for a business agent The following model is an engineering synthesis. It is intended to make deployment choices explicit. ### Trigger and scope A task begins with a user request, a schedule, or an event. Preserve the requested outcome, the initiating authority, the relevant constraints, and the stopping condition. A message can contain useful information without authorizing work. A connected service can deliver an event without authorizing the agent to spend money or modify another system. ### Execution and state Separate the model conversation from the state needed to recover the task. Record completed actions and their identifiers, unresolved decisions, and the next permitted step. An application may pause for approval or an external result. Resumption should not depend on recreating the entire task from an informal summary when authoritative records are available. ### Tools and external effects Tools determine the agent's effective reach. A design should make it possible to distinguish reading a record, preparing an update, and committing that update. Retries require special attention. If an external action completed but the response was lost, retrying the same request may duplicate the action. Use the external system's idempotency or reconciliation facilities where available, and define a recovery path where they are absent. ### Evaluation and acceptance A successful tool call is an execution event. An accepted business outcome is a judgment against the task's requirements. Preserve both. For an internal research workflow, acceptance might require a correct answer with sources. For a record-update workflow, it might require a verified state change in the authoritative system. For a delegated software task, it might require tests and reviewer acceptance. ## Measure the whole task A deployment scorecard should include: - Accepted outcomes divided by all attempted tasks. - Human review and correction time per accepted outcome. - Total operating cost, including failed runs and retries. - End-to-end latency, including queues and approval waits. - Duplicate, unauthorized, or incorrectly applied effects. - Recovery success after interruption or dependency failure. These metrics are proposed measures. Their thresholds should come from the workflow's requirements, not an arbitrary industry-wide target. Compare against the actual alternative: a person using existing tools, a deterministic workflow, or a simpler agent. Include cases where the simpler approach should win. An architecture that improves a difficult research task may add pointless overhead to a routine lookup. ## Separate evaluation from observability Observability explains what happened: traces, messages, tool calls, state changes, and timing. Evaluation judges whether the result was useful or correct. A detailed trace can show that an agent followed a plan which was wrong. A positive user reaction can hide a factual error. A reliable operating process needs evidence of execution and an acceptance method suited to the output. Use recorded failures to improve the task definition, tool interface, context selection, or recovery logic. Replacing the model is one intervention, not the only intervention. ## What changes across organizational boundaries? Inside one application, identity and permissions may be centrally managed. A task involving independently owned agents introduces more questions: who requested the work, which information can cross the boundary, who pays, and what counts as completion? Protocol compatibility makes communication possible. It does not, by itself, establish the authority behind a request or agreement about its outcome. A2A explicitly leaves authorization decisions to the receiving implementation. [A2A enterprise guidance](https://a2a-protocol.org/latest/topics/enterprise-ready/) This is the boundary where a network's value should be measured in useful handoffs, not message volume. A request must reach the relevant agent, enter its working context when appropriate, influence useful action, and produce an accepted result. Each stage can fail independently. ## A deployment acceptance trial Before expanding a workflow, run normal cases alongside a missing-permission case, an ambiguous request, a duplicated event, a dependency timeout, and a restart after an external action. For each case, state the expected behavior and inspect the resulting records. Measure the total cost and human effort. Retain unsuccessful cases rather than reporting only completed demonstrations. The aim is a system whose scope can grow because its behavior is observable and its outcomes are worth relying on. For hosting choices, see [Where to Deploy AI Agents](/research/cloud-agent-deployment/). For delegated identities, budgets, and execution authority, see [When AI Agents Provision Other Agents](/research/agent-provisioning/).