Measuring Agents in Production

We designed and conducted a survey for practitioners building AI agents, with a strong focus on the technical details of their systems. The survey covers system architecture, evaluation, deployment, and operational challenges through 47 questions (listed in full in Appendix E). To capture AI Agents as practitioners understand them, we invited respondents to describe systems they refer to as AI Agents or Agentic AI without imposing a prescriptive definition.

To ensure relevance, we implemented the survey with dynamic branching logic in Qualtrics, where certain questions only appear based on previous responses. For example, the question about the realized benefits of using agents is only shown to respondents who confirmed they chose agentic over non-agentic solutions (O3.1.1 and O3.1 in Appendix Additional Questions). This adaptive structure, combined with the optional nature of all questions, means each question receives a different number of responses. We report the specific sample size (N) for each result throughout Sections 4–7 in figure captions. We asked participants to focus their responses on a single system if they contributed to more than one agent system (Acknowledgment E.1). Full questionnaire details are available in Appendix E, including the branching logic in Figures 26 and 27.

We distributed the survey through multiple channels to reach practitioners across the AI agent ecosystem: the Berkeley RDI Agentic AI Summit [BerkeleyRDI_AgenticAISummit_2025_misc], the AI Alliance Agents-in-Production Meetup [AIAllianceMeetup_5Aug2025_misc], the UC Berkeley Sky Retreat [SkyComputingRetreatsCamps], and professional networks including LinkedIn, Discord, and X. We release the survey on July 28, 2025, with data collection for this paper ending October 29, 2025.

We received 306 valid responses. 294 participants indicated that they have directly contributed to the building and designing of at least one agent system. Our survey respondents are predominantly technical professionals such as software and machine learning engineers (Figure 4(a)). Among 111 respondents who reported their system’s deployment stage, 82% indicated their systems are in production or pilot phases (Figure 4(b)), demonstrating rapid transition from experimental prototypes to real-world deployments.

To maintain focus on production systems, we filtered the data to 86 responses that explicitly reported their systems as being in production or pilot phases. Production systems are fully deployed and used by target end users in live operational environments, while pilot systems are deployed to controlled user groups for evaluation, phased rollout, or safety testing. This filtering excludes development prototypes, research artifacts, and retired systems, as well as participants who did not report their deployment stage. The definitions for all deployment stages appear in Appendix E.2 N5. We denote production and pilot systems as deployed agents. All survey statistics presented in this paper refer to deployed agents unless otherwise stated. Complete data for 306 valid responses across all deployment stages appears in Appendix A.

To add qualitative depth to our survey findings, we conducted 20 in-depth case studies through interviews with teams building deployed agents across a diverse range of organizations.

We carefully selected our 20 cases to achieve representative samples across application diversity, organizational maturity, and global reach. We only interviewed systems with real-world users: 14 cases are in full production and 6 cases are in final pilot phases. The cases span five key sectors: business operations (3 cases), software development and operations (7 cases), integrated business and software operations (5 cases), scientific discovery (3 cases), and communication services (2 cases). Notably, these deployments extend well beyond commonly known coding agents or general chatbots, demonstrating the breadth of production agent applications. The systems target both internal employees (5 cases) and external enterprise consumers (15 cases). Our selection includes organizations across maturity levels, from seed-stage startups to large enterprises with global footprints (Figure 3). For companies with multiple agent deployments, we presented only distinct use cases to maximize application diversity. The anonymized case studies and their application domains appear in Table 1, with additional details in Appendix D.

Each interview lasted 30 to 90 minutes and was conducted by teams of 2 to 5 organizationally neutral interviewers. We followed a semi-structured interview protocol covering 11 topic areas (detailed in Appendix D.1), including system architecture, evaluation mechanisms, deployment challenges, operational requirements, and measurable agent values. We anonymized and recorded interviews based on participant preferences, with human note-takers capturing insights. To ensure accuracy, we cross-validated final summaries among all interviewers. Per our confidentiality agreements, we anonymized all data and present findings in aggregate.

Most survey questions use structured formats (single-select, multi-select, or numeric), requiring minimal post-processing. For the free-text domain keyword responses used in Figure 2, we used LOTUS [lotus], a state-of-the-art unstructured data processing tool, to identify common domain categories and perform classification. This allowed us to normalize phrases from survey responses to representative label sets. For instance, we grouped responses like “healthcare,” “medical,” and “patient monitoring” under a unified “healthcare” category. Details of this normalization process appear in Appendix B.1. All other figures present results from structured survey questions or interview data without requiring automated processing.

As described in Section 3.1, our survey data in the main paper are filtered to deployed (production and pilot) agents, and our interviews specifically select teams building deployed agents. All results presented in Sections 4–7 refer to deployed agents from either survey responses or interviews, which we explicitly denote throughout the paper. Refer to Appendix A for unfiltered full data.

For all figures that include error bars, we report 95% confidence intervals computed using 1,000 bootstrap samples with replacement.

Among practitioners with deployed agents who evaluated alternatives, 82.6% prefer the agentic solution for deployment. We define non-agentic alternatives as existing software systems, traditional approaches, or human execution. Figure 1 details the specific benefits reported by these practitioners. The top three drivers all target the reduction of human effort: increasing productivity and efficiency (72.7%), reducing human hours (63.6%), and automating routine labor (50.0%). Conversely, qualitative benefits rank lower. Increasing user satisfaction ranks in the middle tier (37.9%), followed by reducing required human expertise and training (34.8%) and enabling novel technology (33.3%). Accelerating failure response times (18.2%), reducing interdisciplinary knowledge requirements (18.2%), and risk mitigation (12.1%) rank last.

These priorities reflect pragmatic deployment realities. Organizations adopt agents to solve immediate operational problems, such as expert-expensive manual work and insufficient staffing capacity. Productivity gains are straightforward to quantify through human-hour reductions, whereas safety improvements and risk mitigation are harder to verify. This focus aligns with our findings on internal deployments (Section 4.3), where organizations tolerate higher error rates by maintaining human oversight to catch these errors.

The top reported reasons for using agents reveal a trend where certain objectives are more verifiable and measurable. For example, time to complete a task (productivity) is concrete and quantifiable, while risk mitigation benefits takes longer to verify. We examine this measurement gap and its implications for deployed agents in Section 7.1.

We find that agents operate in diverse industries well beyond software engineering. Figure 2 shows that the three domains with the highest number of reported deployments in survey are Finance & Banking (39.1%), Technology (24.6%), and Corporate Services (23.2%). We also observe a long tail of applications in Data Analytics (13.0%), Research & Development (11.6%), and other specialized domains (15.9%). This distribution demonstrates that agentic systems deliver practical value across fundamentally different industries.

We find that deployed agents primarily serve human users directly. Survey data indicates that 92.5% of deployed systems serve humans rather than other agents or software systems. As shown in Figure 5(a), internal employees are the primary user base (52.2%), followed by external customers (40.3%). Only 7.5% of deployed systems serve non-human consumers.

The focus on internal users is a deliberate deployment choice. Detailed case studies reveal that organizations restrict deployments to internal environments to mitigate unsolved reliability and security concerns. Internal users operate within organizational boundaries where agent mistakes have lower consequences and human oversight is readily available. An example from our case study, internal PagerDuty agents respond to employee requests, while human engineers can take over when needed.

Furthermore, most systems—including external-facing applications—require domain-specific knowledge to operate. For example, insurance authorization agents support nurses, and incident response agents support site reliability engineers. This reflects a pattern where agents function as tools that augment domain experts rather than replace them. This paradigm also enables human users to serve as the final verifiers of agent outputs, which we discuss further in Section 6.2.

Beyond user type, we examine the scale of the user base. We find that end-user counts for deployed systems vary significantly. As shown in Figure 4(c), 42.9% of deployments serve user bases in the hundreds. However, we also observe high-traffic deployments (25.7%) serving tens of thousands to over 1 million users daily, representing substantial user impact or possibly mature systems.

Relaxed latency requirements are common among deployed agents. Figure 5(b) shows the distribution of maximum allowable end-to-end latency. Minutes is the most common target, followed by seconds. Notably, 17.0% report no defined limit yet, and 1.9% allow hours to days.

The latency tolerance reflects the productivity focus from Section 4.1. Agents are often used to automate tasks that typically take humans hours to complete. Consequently, an agent taking multiple minutes to respond remains orders of magnitude faster than non-agentic baselines. Interview participants emphasized this advantage: even if an agent takes five minutes, that remains more than $10\times$ faster than assigning the task to a person on the team, especially when staffing shortages exist and the task is secondary to the user’s core responsibilities. Examples include nurses examining insurance details and software engineers responding to internal pager duty. Some deployed agents from case studies even batch requests hourly or overnight, further indicating latency is not a primary constraint.

However, this pattern breaks for real-time interactive applications. For example, practitioners building voice-driven systems report latency as their top challenge (Section 7.2) during detailed case study. These systems compete against human conversation speeds rather than task completion baselines. Among our 20 detailed case studies, only 5 require real-time responsiveness. The remaining 15 cases tolerate extended processing times: 7 involve human review with relaxed timing, 5 operate as asynchronous background processes, and 3 have hybrid operation patterns. For these systems, processing times of minutes remain acceptable because the alternative is days of human effort.

We find that deployed agents rely heavily on proprietary models. Only 3 of 20 detailed case studies use open-source models (LLaMA 3 [grattafiori2024llama3herdmodels], Qwen [qwen3technicalreport], and GPT-OSS [openai2025gptoss]), while the remaining 17 rely on closed-source frontier models (Figure 6). Of the teams using closed-source models, 10 explicitly confirm using the Anthropic Claude [AnthropicClaude_nd] or OpenAI GPT [OpenAIclosed2025] families. Specific models mentioned during interviews include Anthropic Claude Sonnet 4 and Opus 4.1, and OpenAI o3, each representing the state-of-the-art model from each provider at the time of the interview. While other participants did not disclose specific models, most interviewees followed the pattern of using the largest and most capable state-of-the-art models as the primary model for their agents from each model family.

We find that open-source adoption is rare and is driven by specific constraints rather than general preference. Among the three cases using open-source models, motivations include high-volume workloads where inference costs at scale are prohibitive, and regulatory requirements preventing data sharing with external providers. For example, one team from detailed case study serve continuous infrastructure maintenance agent leverages the company’s existing internal compute resources (e.g., GPUs) to serve a fine-tuned open-source model to meet cost constraints.

For the majority of cases, model selection follows a pragmatic, empirical approach focused on downstream performance. Interviewees report that they test the top accessible state-of-the-art models for each task and select based on performance. Unlike the high-volume open-source use cases, these teams note that runtime costs are negligible compared to the human experts (e.g., medical professionals, senior engineers) that the agent augments. Consequently, they default to the best-performing closed-source models regardless of inference cost.^†††Rankings based on public model leaderboards at the time of development. Additionally, 4 out of 20 detailed case studies combine LLMs with specialized off-the-shelf models (e.g., text-to-speech, chemistry foundation models) to handle specific modalities.

Number of Distinct Models. While a substantial portion rely on a single model, the majority coordinate multiple models to meet functional or operational needs. Survey results show that 40.9% of deployed agents use exactly one model, while 27.3% use two, 18.2% use three, and 13.6% use four or more. Among detailed case studies, 10 out of 20 (50%) combine models to address specific functional needs. We identify two drivers: cost optimization and modality. First, teams combine models of varying sizes to balance latency, cost, and quality. For example, one agent workflow from case study routes simple subtasks like pattern recognition to smaller models while reserving larger models for subtasks requiring higher reasoning capabilities. Second, teams integrate models to handle distinct data modalities. Communication agents leverage text-to-speech models alongside LLMs, while scientific agents employ domain-specific foundation models (e.g., chemistry) alongside general-purpose reasoning models.

Operational constraints also drive multi-model adoption. We find that multi-model architectures can emerge from lifecycle management needs rather than complex reasoning requirements for the agent task. Detailed case studies reveal that teams maintain multiple models to manage agent’s behavioral shifts from model migration. Organizations often run legacy models alongside newer versions because agent scaffolds and evaluation suites depend on the specific behaviors of the older model, where sudden updates might degrade output quality. Additionally, governance policies enforce teams to route subtasks to different model endpoints based on user or developer access levels. Thus, architectural complexity often reflects strategic operations rather than task difficulty.

Interestingly, we observe a heavier tail towards agents using more distinct models when we examine the full survey data, including prototyping and research agents that have not yet been deployed (Figure 16(a)). Deployed agents are more likely to converge on fewer number of distinct models compared to non-deployed agents, suggesting that teams explore richer multi-model combinations during early experimentation but consolidate onto a smaller set of models as they move toward deployment. We hypothesize this might be also reflecting the additional operational burden of maintaining many distinct model endpoints.

We observe a strong preference for prompting over model weight updates in deployed agents. We find that 14 out of 20 (70%) detailed case studies rely solely on off-the-shelf models without supervised fine-tuning (SFT) or reinforcement learning (RL) (Figure 6). Additionally, 2 teams from detailed case studies explicitly report that foundation model capabilities already meet their target use case, making fine-tuning unnecessary.

Only 5 of 20 detailed case studies actively use SFT. These teams target deployment in business-specific corporate contexts where leveraging highly contextual information improves downstream performance. For example, customer product support agents benefit from fine-tuning on specific product offerings and policies. However, performance gains do not always justify the development overhead. Among the 5 detailed case studies actively using fine-tuned models, 3 consider SFT essential, while 2 apply it selectively for enterprise clients where customization requirements justify the additional cost. Three additional teams from interview case studies express strong interest in future adoption for similar reasons. Notably, we find that 4 of the 5 detailed case studies that employ SFT do so in combination with off-the-shelf LLMs, rather than relying on fine-tuned models exclusively.

Regarding reinforcement learning (RL), only 1 scientific discovery case from our interviews uses an RL post-trained model. Three other teams express interest in exploring RL for software testing in future development cycles.

This data, however, does not diminish the value of post-training models for agent applications. Interviews show that SFT and RL is challenging to implement and brittle to model upgrades. Given that off-the-shelf base models can already do most of what the agent applications need, teams prefer methods with lower integration overhead that do not increase already high development and maintenance burdens.

We find that humans dominate system-prompt construction in production systems. Our survey data reveals that 33.9% of deployed agents use fully manual methods with hard-coded strings. Another 44.6% use a hybrid approach where humans manually draft prompts and then use an LLM to augment or refine them, and 3.6% rely on utilizing predefined prompt templates. Only 8.9% of respondents use a prompt optimizer (e.g., DSPy [khattab2024dspy]) to improve their agent systems, and just 3.6% report letting agents autonomously generate their own prompts.

Our detailed case studies confirm this pattern. Only 1 out of 20 (5%) detailed case studies has explored automated prompt optimization. The remaining cases rely on primary human construction, sometime using LLMs for augmentation. While recent research [zhang2025agenticcontextengineeringevolving, agrawal2025gepareflectivepromptevolution, khattab2024dspy] proposes automating prompts into parametric optimizations, we find these methods rare in deployment. We speculate from interview conversations with practitioners that they prioritize controllable, interpretable methods that allow for fast iteration and debugging over automated or “black-box" methods that requires additional engineering overhead.

We find that prompt complexity increases with system maturity. Among deployed agents from survey, we observe a wide distribution: while 51.5% of systems use short instructions under 500 tokens, there is a long tail of massive prompts (Figure 8(b)). Specifically, 24.2% of deployed agents use prompts between 500 and 2,500 tokens, 12.1% use between 2,500 to 10,000. Notably, another 12.1% even exceed 10,000 tokens .

We explore the core architectural patterns that support production deployment. To ensure clarity, we adopt the terminologies visualized in Figure 22: an agent completes a high-level task, which decomposes into logical subtasks, consisting of granular atomic steps (e.g., model calls, tool use).

Number of Steps. We find that production agents tend to follow structured workflows with bounded autonomy. We ask survey participants how many steps their deployed systems execute within a subtask before requiring human input. Most systems operate within tight bounds: 46.7% of deployed survey agents complete only 1–4 steps, and an additional 21.7% perform 5–10 steps (Figure 8(c)). A smaller subset (16.7%) extends to tens of steps, while only 6.7% report systems with no explicit step limit. Interestingly when we expand the analysis to include all agents including both deployed and not yet deployed agents in Figure 16(c), the distribution shifts toward substantially higher step counts. This indicates that prototypes and research systems are more likely to run tens of steps or have no explicit limit on autonomous cycles, reflecting more aggressive exploration of open-ended autonomy during early development.

Practical constraints drive this design choice. Case study participants identify problem complexity, non-determinism in agent self-planning, and latency requirements as key limiting factors. Practitioners intentionally impose limits on reasoning steps to maintain reliability and manage computational time and costs. This simplicity reflects a broader preference for predictable, controllable workflows over experimental open-ended autonomy in production environment.

Number of Model Calls. While distinct from logical steps (which often include non-inference actions like tool execution), we specifically analyze model calls to gauge the inference intensity of deployment systems. We observe that within a single subtask, deployment systems typically execute model calls on the order of tens or less. The majority (66.7%) of deployed survey agents use fewer than 10 calls per subtask, with 46.7% using fewer than 5 calls. This is followed by 33.3% using tens of calls, 9.0% in the hundreds, and 6.1% in the thousands. Interestingly, another 12.1% do not set explicit limits. This aligns with our detailed case studies, where 3 teams confirm executing tens of model calls per subtask (up to 40–50 calls).

Experimental systems are far more likely to sit in the long tail, with many agents routinely making tens of calls. In contrast, deployed agents concentrate in the lower-call regime, suggesting that teams aggressively cap or refactor call budgets as they move from experimentation to deployment to probably control cost, latency, and failure amplification.

Despite the pattern of limited model calls, 31% of deployed survey agents already use various inference-time scaling techniques, compared to 44% in experimental systems. While this figure currently includes simpler methods like composing outputs from multiple models (Section 5.1), future work may determine how advanced techniques—such as self-planning, search-based reasoning, and self-verification—perform in production, as these approaches may then lead to higher numbers of model calls and steps before human intervention .

Agent Control Flow. We observe that production agents favor predefined static workflows over full open-ended autonomy. We find that 80% of our detailed case studies utilize a structured control flow. These agents operate within well-scoped action spaces rather than freely exploring the environment to self-determine objectives.

Detailed case studies provide insight into these control flow patterns. Nine cases utilize various forms of agentic Retrieval-Augmented Generation (RAG) pipelines, ranging from single agents retrieving information via tool calls to sophisticated pipelines with over 20 subtasks that explicitly configure retrieval at certain steps. For example, one insurance agent follows a fixed sequence: coverage lookup, medical necessity review, and risk identification.^‡‡‡This is a simplified example workflow to illustrate the core logic, redacted to protect the anonymity of the interviewee. While the agent possesses autonomy to complete each subtask (e.g., deciding if a case needs human intervention for risk identification), the high-level objective and expected output of each subtask remain fixed.

Open-ended autonomy remains rare. We observe only one case where agents operate with unconstrained exploration. Notably, this system runs exclusively in a sandbox environment with rigorous CI/CD verification on the final outputs, avoiding direct interaction with production environment.

However, we identify a growing interest in expanding autonomy. Four detailed case studies employ a planning and routing agent to decompose input requests and dispatch them to task-specialized agents. Another team specializes agents into generators and verifiers, enabling greater autonomy through automated verification. Several teams share that they are experimenting with flexible workflows by allowing agents to make autonomous decisions about next steps or by using planning and orchestration agents.

We find a divergence in framework adoption between survey respondents and interview case studies. Among deployed agents from the survey, two-thirds (60.7%) use third-party agentic frameworks. Reliance concentrates around three primary frameworks: LangChain/LangGraph [langchain, LangChain2025LangGraph] leads with 25.0%, followed by CrewAI [CrewAI2025Homepage] at 10.7%, with LLaMAIndex [LlamaIndex2025Homepage] and OpenAI Swarm [OpenAI2025SwarmGitHub] both at 3.6% (Figure 9).

In sharp contrast, our detailed case studies reveal a strong preference for custom in-house agent implementations. Only 3 of 20 (15%) detailed case studies rely on external agent frameworks (2 use LangChain, 1 uses BeeAI). The remaining 17 teams (85%) build their agent application entirely in-house with direct model API calls. For example, one interview case explicitly shared that their agents are their own implementation of ReAct loops. Notably, two additional teams report starting with frameworks like CrewAI during the experimental prototyping phase but migrating to custom in-house solutions for production deployment to reduce dependency overhead.

We identify three core motivations for building custom solutions from the detailed case studies. First, flexibility and control are critical. Deployed agents often require vertical integration with proprietary infrastructure and customized data pipelines that rigid frameworks struggle to support. For example, one agent-native company deploys customer-facing agents across varied client environments, necessitating a bespoke orchestration layer. Second, simplicity drives the decision. Practitioners report that core agent loops are straightforward to implement using direct API calls. They prefer building minimal, purpose-built scaffolds rather than managing the dependency bloat and abstraction layers of large frameworks. Third, security and privacy policies sometime prohibit the use of certain external libraries in enterprise environments, compelling teams to develop compliant solutions internally.

During development, teams conduct offline evaluation to assess agent performance before deployment. Figure 10(a) shows that 38.7% of survey respondents compare their deployed agentic systems against non-agentic baselines such as existing software systems, traditional approaches, or human execution. The remaining 61.3% do not perform baseline comparisons. Among these, 25.8% report their systems are truly novel with no meaningful baseline for comparison. While we do not know reasons behind why the remaining 35.5% did not conduct the comparison, in-depth interviews reveal that baseline comparison is often challenging even when alternatives exist. One reason is that non-agentic baselines frequently combine multiple components, making systematic technical comparison difficult. The HR support agent development team illustrates that agent solution replace a baseline process combining company document lookup, human procedures, and non-LLM HR software. While outcomes such as task completion time are measurable, isolating technical performance for comparison is challenging.

Beyond baseline comparison, teams employ benchmark evaluations. We refer to benchmark here as a curated set of tasks or questions with known correct answers. Among 20 teams, 5 build custom benchmarks. One team builds benchmarks from scratch, collecting ground truth labels through collaboration with domain experts. Four teams synthesize existing data to curate benchmarks, drawing from past test cases, system logs, pull requests, and support tickets. One team also leverages public benchmarks during early development. The remaining 15 teams (75%) evaluate their agents without benchmark sets, using alternative methods such as A/B testing, user feedback, and production monitoring.

Among the 5 teams building custom benchmarks, our interviews reveal a prevalent evaluation pattern despite diverse domains and organizations (e.g., human resources, cloud infrastructure, and business analytics). Teams establish a golden question-and-answer set, collect user interaction and feedback data, then work with subject matter experts to examine quality and expand the golden set. This process extends into production runtime, enabling LLM-as-a-judge online evaluation pipelines. Based on our analysis, the convergence of nearly identical pipelines across diverse contexts suggests research and development opportunities in reusable data ingestion pipelines, curation methods for golden sets, and synthetic generation techniques for evaluation datasets.

We ask participants which evaluation strategies they employ, allowing multiple selections. These methods apply to both offline evaluation during development and online evaluation in production environments. Four methods dominate responses: human-in-the-loop evaluation, model-based evaluation, rule-based evaluation (heuristics or syntactic checks), and cross-referencing evaluation (verification against knowledge bases or reference datasets). The exact question and method descriptions appear in Appendix E.

Human-in-the-loop verification. The majority (74.2%) rely on manual, human-in-the-loop evaluation (Figure 10(b). These evaluations typically involve domain experts, operators, or end-users directly inspecting, testing, or validating system outputs to ensure correctness, safety, and reliability.

Human experts play a critical role during development for offline evaluations. Agent developers work directly with domain experts or target users to validate system responses. For example, medical professionals are directly involved when testing and evaluating the correctness of healthcare agent systems. In one case, a company even forgoes automated evaluation methods entirely, relying instead on human experts to provide feedback to hand-tune agent configurations for each client’s deployment environment.

Human experts also serve as verifiers during agent execution for online evaluation. Teams commonly have human experts perform final actions based on agent output, serving as a layer of guardrails. For example, one site reliability engineering agent suggests actions based on analysis across system stacks, but human experts make the final decision on what to execute. The agent does not directly modify the production environment.

Model-based evaluation. Model-based evaluation methods such as LLM-as-a-judge are the second most common approach, used by 51.6% of respondents (Figure 10(b)). While this evaluation method applies for both offline development time and online runtime evaluation, 7 of 20 interview case studies use LLM judges for online evaluation during agent execution.

Model-based evaluation does not eliminate human involvement. Figure 10(c) shows the co-occurrence of different evaluation strategies, revealing that among the 51.6% of survey respondents who use model-based evaluation, a substantial portion (38.7%) also employ Human-in-the-Loop verification. In detailed case studies, all interviewed teams using LLM-as-a-judge combine it with human review. Specifically, these teams use LLM judges to evaluate confidence in every final response, combined with human subsampling. An LLM judge continuously assesses each agent’s final response. If the judge scores above a preset confidence threshold, the output is accepted automatically. Otherwise, the request routes to human experts. Additionally, human experts sample a preset percentage (e.g., 5%) of production runs even when the LLM judge expresses high confidence, verifying correctness to ensure consistent alignment at runtime. Development teams update prompt instructions and agent configurations based on this production feedback.

Other methods. Rule-based evaluation methods and cross-referencing strategies show comparable adoption rates (41.9% and 38.7% respectively). Rule-based evaluation consists of simple logic checks such as grammar and syntax verification or domain-specific rules. For example, coding agents verify outputs through compilation checks and test suites, while analytical agents may apply domain-specific rubrics to assess output quality. Cross-referencing evaluation uses external sources for grounding and fact-checking to verify the accuracy and quality of generated answers or solutions. This includes retrieving supporting evidence from trusted knowledge bases or comparing outputs against reference datasets.

Evaluation method patterns. Co-occurrence analysis reveals that human-in-the-loop evaluation is the most common method used together with other evaluation strategies (Figure 10(c)). Practitioners anchor automated, rule-based, and cross-referencing methods around human judgment rather than relying on them in isolation.

Notably, human-in-the-loop (74.2%) and LLM-as-a-judge (51.6%) dominate compared to rule-based verification (42.9%). Based on our analysis, this pattern may suggests that production agents already handle complex tasks beyond classification, entity resolution, or pattern matching. These agents operate in domains requiring nuanced judgment where rule-based methods prove insufficient. For example, customer support voice assistance and human resource operations demand expertise beyond pattern matching, explaining why practitioners require human and LLM verification to assess output correctness.

Difficulties creating benchmarks. As defined in Section 6.1, benchmarks are curated sets of tasks or questions with known correct answers used for offline evaluation during development. Among interviewed teams, 5 build custom benchmarks. However, benchmark creation proves challenging for three reasons based on our case study interviews.

First, specific domains lack accessible public data. In regulated fields like insurance underwriting, the absence of public data forces teams to handcraft benchmark datasets from scratch through collaboration with domain experts and target users. Second, creating high-quality benchmarks at scale is resource-intensive and time-consuming. One interviewed team reported spending months creating an initial set of approximately 40 unique environment-problem-solution scenarios, followed by another six months to scale the dataset to roughly 100 examples. Third, benchmark creation is nearly infeasible for agent applications focused on highly customized client integrations. One interviewed voice agent team illustrates this challenge: while core features are straightforward to test without extensive data, the primary engineering effort involves client-specific customizations such as proprietary toolsets, product offerings, and localized dialogue tuning. Creating standardized benchmarks for every possible client configuration is impractical. Given these challenges, 75% of interviewed teams forgo benchmark creation entirely, instead relying on A/B testing or direct client collaboration to iterate based on human feedback until expectations are met.

Agent behavior breaks traditional software testing. Three case study teams report attempting but struggling to integrate agents into existing CI/CD pipelines. The challenge stems from agent nondeterminism and the difficulty of judging outputs programmatically. Despite having various forms of existing regression tests from baseline systems, these teams have not yet identified effective methods to adapt them for nondeterministic agent behavior to create test set that cover sufficient runtime scenarios with different nuances.

Verification mechanisms and benefit quantification. Based on the interview case studies, we observe that agent faces two broader evaluation challenges. First, robust verification mechanisms do not always exist. Coding-related agents benefit from strong correctness signals through compilation and test suites, such as software migration agents and site reliability agents in Table 1. However, many agents operate in settings without robust and fast verification. For example, insurance agents receive true signals only through real consequences such as financial losses or delayed patient approvals. These signals arrive slowly and in forms difficult to automate for evaluation. Second, the final benefits of using agents are not always easy to measure. Section 4.1 shows agents target productivity gains because end-to-end time and human hours quantify straightforwardly. Applications with harder-to-measure benefits remain less explored. For example, we observe fewer cases of agents reducing cross-domain knowledge needs or mitigating risks, potentially because benefits manifest indirectly or over longer timeframes.

We examine the degree to which agent execution latency hinders deployment. Survey results indicate that latency represents a manageable friction rather than a hard stop for most teams. Figure 11 shows that only 14.8% of deployed survey agents identify latency as a critical deployment blocker requiring immediate resolution, while the majority (59.3%) report it as a marginal issue, where current latency is suboptimal but sufficient for deployment. We suspect that this tolerance may correlates with the prevalence (15/20 in detailed interview case studies) of asynchronous agent execution paradigm (Section 4.4) and (52.2% from survey) internal user bases (Section 4.3). Notably, we observe a consistent latency distribution across the full survey dataset, including experimental systems (Figure 19(b)). We believe this consistency signals a broader preference for building offline agents, as discussed in Section 4.4.

Interactive agent latency requirements. While latency is not a critical challenge for most agent applications, it remains a critical bottleneck for real-time interactive agents. Two interviewed teams, building voice and specialized chat agents, report continuous engineering efforts to match human conversational speeds. Unlike asynchronous workflows, these systems require seamless turn-taking where delays disrupt the user experience. Achieving fluid real-time responsiveness beyond rigid turn-based exchanges remains an open research question and development challenge.

Practical latency management. Interview participants describe two approaches to managing latency. First, teams commonly implement hard limits on maximum steps or model inference calls, typically derived from heuristics. Second, one team adopts a creative solution by pre-building a database of request types and agent actions (tool calls), then employing semantic similarity search at runtime to identify similar requests and serve prebuilt actions, reducing response times by orders of magnitude compared to reasoning and generating new responses. These workarounds demonstrate that practitioners currently rely on system-level engineering to bypass the inherent latency costs of foundation models.

Security and privacy consistently rank as secondary concerns in both of our survey and interviews, with practitioners prioritizing output quality and correctness. Figure 21(a) shows that Compliance and User Trust ranks fourth among challenge categories. Given that Section 4.3 shows 52.2% of systems serve internal employees and many systems with human supervision, this prioritization reflects current deployment environments and requirements rather than dismissing security’s importance.

Data ingestion and handling. Survey results in Figure 12 show that 89.7% of systems ingest information from databases, 65.5% ingest real-time user input, and 51.7% ingest other real-time signals. Notably, 69.0% of systems retrieve confidential or sensitive data, while only 34.5% retrieve persistent public data. Given the high prevalence of sensitive data usage and user inputs, preserving privacy is critical. Our interview case studies reveal that teams address this through legal methods. For example, a team building healthcare agents report relying on standard data-handling practices and strict contractual agreements with model providers to prevent training on their user data.

Security practices. In-depth interview participants describe four approaches to managing security risks through constrained agent design. First, six teams restrict agents to “read-only” operations to prevent state modification. For example, one SRE agent case study generate bug reports and proposes action plans, but leaves the final execution to human engineers. Second, three teams deploy agents in sandboxed or simulated environments to isolate live systems. In one instance, a code migration agent generates and tests changes in a mirrored sandbox, merging code only after software verification. Third, one team builds an abstraction layer between agents and production environments. This team constructs wrapper APIs around production tools, restricting the agent to this intermediate layer and hiding internal function details. Finally, one team attempt to enforce role-based access controls that mirror agent user’s permissions. However, the agent team reports this remains challenging, as agents can bypass these configurations when accessing tools or documents with conflicting fine-grained permissions.

A paradox emerges from our data: while nearly 40% of practitioners identify reliability, robustness, and scalability as their primary development concern (Section 7), these systems have successfully reached deployments in production or pilot stages (Section 4). This raises a critical question: how do agents reach production if reliability remains an unsolved challenge? We observe that practitioners ensure reliability via deploying agents with strict constraints on both execution environments and agent autonomy, often combined with close human supervision.

Our in-depth case studies reveals several deployment environment patterns. Some agents operate in read-only mode, never modifying production state directly. For example, SRE agents perform debugging then generate detailed bug reports that engineers review and action. Other agents serve internal users where errors carry lower consequences and human experts remain readily available to correct mistakes (Section 4.3): for example, Slack bot response automation for internal tickets. Systems with write access deploy through sandbox environments where outputs undergo rule-based verification before production integration. Some teams combine read-only access with sandboxes mirroring production environments to further mitigate risk. We observe that these patterns shift the reliability challenge from ensuring correct autonomous agent actions at each step to verifying that final outputs meet acceptable quality thresholds.

Section 5.4 shows 68% of production agents execute fewer than ten steps before requiring human intervention. Organizations deliberately bound agent behavior within specific action spaces through prompting and limited tooling. External-facing systems use particularly restricted agent workflows where customer trust and economic consequences demand tighter control. For example, rather than allowing an agent to autonomously decide if and where to search via tool call, teams employ agentic RAG architectures with pre-determined retrieval steps that restrict the agent to specific document store. We believe this pattern reveals a deliberate engineering trade-off. Production teams balance capability with controllability such that these systems deliver value through well-scoped automation while maintaining reliability guarantees.

An open question remains: how can future agents expand autonomy while maintaining production-level reliability? The field has not established clear pathways for systematically relaxing these constraints while preserving safety guarantees. We observe that one emerging pattern to achieve this goal is the merging of distinct subtasks into a single task. For example, commercial coding assistants adopt test-driven development by merging coding and testing into a unified agent execution flow [ClaudeCode2025, cursor2025]. We believe this pattern of decoupling logical task abstraction from agent execution steps has potential to extend to other domains. The way humans break down tasks into subtasks might not be the right way to organize agent control flow (Figure 22). Progress requires advances in two areas: agent evaluation must move beyond correctness metrics to assess other aspects of reliability (e.g.: five 9s) under varying autonomy levels, and engineering practices that systematically specify and verify bounded operations at different abstraction levels.

Our study reveals an encouraging finding: production agents already operate across more than 26 domains (Figure 2), extending well beyond coding-related agents and chatbots. We find that practitioners extract real value from current model and agent capabilities (Figure 1).

Our detailed case studies show that current frontier models, utilizing prompting strategies alone, already possess sufficient capabilities to cover a diverse range of production use cases. Section 5.1 shows that 70% of deployed survey agents rely on off-the-shelf models without any fine-tuning. This data pattern demonstrates that practitioners enable substantial deployment by leveraging existing model capabilities within well-scoped applications rather than waiting for model improvements. We already see diverse implementations where agents support healthcare workflows, manage business operations, and accelerate scientific discovery in production (Table 1).

Figure 5(a) and our case interviews reveal that relatively little attention has been given to applying agents to software-facing rather than human-facing problems. Most production agents interface directly with users through chat, voice, or interactive workflows. We observe fewer deployments for direct software operation, maintenance, and optimization tasks. We believe opportunities to improve automation in these software-integrated systems remain under-explored, though realizing this potential requires addressing the reliability challenges discussed in Section 8.1.

Beyond the directions we highlight in prior sections, we identify additional research questions based on deployment patterns in RQ1–4.

We show that agents often operate without clean and fast correctness signals in the real-world (Section 7.1). We observe an analogy with silent failures, where catching errors during runtime is challenging and success signals arrive through real consequences like financial loss or customer dissatisfaction. Engineers dedicate substantial effort ensuring agent quality through close human oversight, demonstrating effective practices that enable current deployments. However, the field has yet to reach consensus on effective ways to identify what and when errors or low-quality responses occur. We believe understanding agent failure modes [whydomultiagentllmsystemsfail], developing agent observability tools, and advancing runtime failure mitigation techniques represent important open research directions in addition to benchmarking and CI/CD integration (Section 7.1).

Significant evidence shows interest in post-training for agents [Cursor2025ComposerRL, qu2024recursiveintrospectionteachinglanguage, cao2025skyrlagentefficientrltraining, yuan2025agentrtraininglanguagemodel, Huang2025_biomni, song2024agentbankgeneralizedllmagents, park2025maporlmultiagentpostcotrainingcollaborative, ma2025coevolvingyoufinetuningllm], yet Section 5.1 shows fine-tuning and reinforcement learning remain uncommon in deployment despite potential benefits. Our interviews reveal development effort currently prioritizes making agents work reliably over improving model capabilities for preference optimization, specialization, or cost trade-offs. We speculate this pattern emerges for two reasons: first, supervised fine-tuning and reinforcement learning impose barriers to entry, requiring large amounts of representative data or environments alongside with specialized ML expertise; second, model upgrades introduce complexity when fine-tuned models must adapt to new base versions. We believe the field needs more sample-efficient post-training approaches that remain robust to model upgrades and translate into repeatable engineering practices.

We find in Section 5.4 that 30% of deployed survey agents already adopt inference-time scaling techniques, with the use of multiple models being most popular. From detailed case studies, we find these are commonly simple methods, such as routing distinct subtasks to specialized models. We believe recent advances in generate-verify-search approaches [alphaevolve, barbariansgateaiupending] have significant potential for non-science agent applications as well because they provide stronger reliability guarantees while maintaining controllability and explainability. However, realizing this potential may requires infrastructural support and redesign, such as building simulators and designing verifier. How to adapt agent runtime environments to support such inference-time search technique, and how to effectively utilize them in an online execution settings, are open research questions.

We show in Figure 13 that 93% of current production agents take text or speech in natural language as inputs. Both our survey trends and interviews show high interest in expanding agent modalities to include images, spatiotemporal sequences, video, and scientific data. Interview participants suggest that teams currently focus on applications that are easy to measure and validate. We believe that once these initial deployments work reliably, agent features and capabilities will expand to handle richer input modalities.