AI agents are in production.The operating model is now the bottleneck.
A 2026 engineering survey reports growing AI agent use while state, reliability, security, and cost remain important operating-model concerns. This is our analysis of what the 2026 engineering data means for enterprise leaders.
Temporal's 2026 survey suggests that AI agent use may be moving faster than some operating models. Engineering teams can use agents to generate code, test it, analyze systems, and assemble working prototypes. The harder question is not only whether an agent can produce useful work. It is whether the organization can operate that work within defined safety, reliability, and economic boundaries inside a real business process.
Temporal's 2026 State of Development report makes that tension visible. Among 554 engineers and engineering leaders in the United States and United Kingdom, 80.8% said they now use AI agents daily or more often, up from 47.3% one year earlier. Almost half said agents are already in production or core to how they ship. At the same time, 41.1% encounter issues daily or more often, and the leading productivity constraints are tracking state, debugging, and managing cost.[1]
Within this survey sample, the numbers suggest that access alone is not a complete measure of readiness. Operational discipline may be the more important differentiator. Teams can test that hypothesis by measuring whether their operating model turns probabilistic output into controlled business execution.
In this survey, adoption extends beyond pilots
Within Temporal's survey sample, frequent use increased 70.8% year over year. The median respondent reported using five agents, while the average was 10.7, suggesting that a smaller group in the sample used larger fleets.[1] These results support adding portfolio-design questions to the enterprise conversation: which agents exist, which outcomes they support, which systems they can touch, and who is accountable for them.
The survey's self-described successful cohort used agents more frequently and across more use cases. They were more likely to apply agents to technical design, security, customer support, code, and internal knowledge research.[1] This is a correlation, not proof that broader use caused success. One hypothesis to test is that coordinated support across a workflow can create more value than a disconnected task assistant.
Breadth can also expand the failure surface. Each additional tool, data source, and action may add a permission boundary, a state transition, a cost path, and an accountability question. An organization can have high adoption and low readiness at the same time. We use the term agent operations gap for the risk that activity grows faster than the controls and shared services required to make it dependable.
Agent use accelerated
A 70.8% year-over-year rise in frequent use changes the management question from adoption to operations.
Reported speed highlights the next operating question
If a workflow cannot explain its current state, authorized actions, cost per completed outcome, last evaluation result, and human escalation owner, treat it as experimental until the required operating evidence exists.
In the survey, 91.1% said agents had improved or fundamentally changed their productivity, and 51.3% said they could move from a working AI-generated prototype to production-ready code in hours or faster.[1] These are self-reported results from this sample, not independently measured performance benchmarks. The self-described successful cohort reported only a 1.2-times speed advantage over other respondents, suggesting that reported success was associated with more than speed alone.
The management hypothesis is that as more teams generate answers quickly, differentiation may shift to what happens around those answers. Can the system recover after a tool fails? Can a reviewer see what evidence drove the decision? Can the agent resume without repeating a payment, ticket, or database update? Can a team test a lower-cost model for a low-risk task without reducing outcome quality? Can an owner stop the workflow before a local error becomes a business incident?
Fast generation can hide slow operations. A prototype may appear complete while identity, evaluation, rollback, cost allocation, and incident ownership are still manual. The prototype-to-production clock only measures part of the journey. The production-to-trust clock measures whether the organization can depend on the system after the launch meeting ends.
The agent is not the operating system
A model can reason, but it does not automatically provide the durable machinery a business process needs. It does not create a reliable source of workflow state. It does not know which retry is safe. It cannot grant itself authority, define its own budget, or decide when an action requires independent review. Those responsibilities belong to the system around the model. NIST's Generative AI Profile likewise treats trustworthiness as work across design, development, use, and evaluation, not as a model-only property.[2]
The leading blockers in the report support this view. Tracking state ranked first, followed by debugging and cost management.[1] These are system concerns. They are solved through architecture, telemetry, policies, durable execution, and operational ownership. A prompt can influence behavior, but it cannot serve as the only control plane for a process that writes records, contacts customers, changes infrastructure, or moves money.
This report proposes six shared layers for a practical agent operating model. They can be reused across teams, even when individual agents use different models, frameworks, or cloud services. Standardizing these layers may let teams experiment at the model edge without recreating the safety and operations core for each workflow. OpenTelemetry's GenAI conventions define common fields for agent identity, conversations, operations, and evaluation scores, an example of emerging shared agent semantics.[3]
Where is the work now?
Persist goals, evidence, decisions, checkpoints, and completion status outside the model so a workflow can resume safely after failure.
The goal is not to centralize every agent decision. It is to make the boundaries consistent. Product teams should be free to choose an appropriate reasoning pattern for their workflow. The enterprise should still have a defined way to answer who acted, what happened, why it was allowed, how well it worked, what it cost, and who owns the exception.
A production scorecard makes readiness visible
Agent programs can mistakenly use feature progress as a proxy for readiness. The agent can call another tool, process another document type, or complete another task, so the program appears closer to production. A more useful scorecard tests whether the workflow can handle expected operating conditions: partial failure, stale data, ambiguous requests, changing permissions, cost spikes, and human disagreement.
The difference between a pilot question and a production question is evidence. A pilot asks whether something can work. Production asks whether the organization can prove that it keeps working within defined boundaries. That proof should be visible to engineering, security, finance, risk, and the business owner without each group reconstructing the story from a different dashboard.
This scorecard is intentionally model-neutral. A company may use Amazon Bedrock, Azure OpenAI, Gemini, Claude, open models, or several providers. Model choice affects quality, latency, and price. It does not remove the need for durable state, scoped authority, measurable outcomes, and accountable escalation.
From possible to provable
| Dimension | Pilot question | Production question | Required evidence |
|---|---|---|---|
| State | Can it finish the happy path? | Can it resume without duplicating side effects? | Durable execution trace |
| Reliability | Did it work in the demo? | Can failures be reproduced and contained? | Evaluation history and incident replay |
| Security | Can it reach the tool? | Should this actor take this action now? | Identity and policy decision log |
| Economics | What did the model call cost? | What did the completed outcome cost? | Workflow unit economics |
| Accountability | Who reviewed the output? | Who owns the exception and reversal? | Escalation and approval record |
A phased path to operating discipline
Begin with one workflow where the organization can connect technical behavior to a business result and learn under controlled conditions. Use the phases below to create the operating contracts and evidence needed for a production decision. Set the schedule after reviewing data access, integrations, required reviews, testing, risk, and team availability.
Start with a process, not a disconnected task. A useful candidate has repeatable volume, a measurable outcome, available data, a clear owner, and exceptions that humans can recognize. Avoid beginning with a process where success is subjective, the data is inaccessible, or one wrong action creates an irreversible outcome. Those conditions make controlled learning more difficult.
The sequence matters. Teams often begin by adding tools and autonomy, then add governance after something goes wrong. Instrumentation should come first. Read-only comparison should come before action. A named owner and reversal path should exist before a production permission is granted. Each phase should produce evidence that the next phase can inspect.
Frame
Start hereSelect one high-volume workflow, name the business outcome, map the current process, and define the actions that require human authority.
Instrument
Build the controlsCreate the identity, state, telemetry, evaluation, and cost contracts before widening the agent's tool access or autonomy.
Pilot
Test with usersRun in read-only or recommend mode, compare agent decisions with expert decisions, and tune exception thresholds using production-like data.
Operate
Operate and expandRelease bounded actions, monitor outcome and cost, rehearse failure paths, and expand authority only where the evidence supports it.
Tactical Edge builds the system around the model
Tactical Edge works with enterprises that are ready to move from scattered AI activity to an operating capability. Our Advisory and Strategy work identifies the workflow, outcome, authority boundary, risk profile, and economics before a large build begins. Agent Programs and Design and Engineering then turn that operating design into a bounded production system.
For software delivery, Connectory runs production pull-request reviews through app.connectory.ai, applying repository context and workspace policies to return findings in GitHub before merge. Agent Governance engagements define permissions, policies, approval gates, and evidence requirements for the customer's scoped AI workflows. AgentOps and Managed AI Operations can instrument quality, drift, cost, incidents, and selected business outcomes after deployment. On AWS, we select controls and services for the use case, which may include Amazon Bedrock, Bedrock AgentCore, AWS Identity and Access Management, AWS Lambda, Amazon CloudWatch, and durable workflow components. AWS documents AgentCore as modular services spanning tools, identity, memory, policy, runtime, observability, and evaluations.[5]
The point is not to sell a larger stack. It is to remove the structural reasons useful prototypes stall. Sometimes the right answer is a focused architecture and operating model. Sometimes it is a pilot with a strict evidence gate. Sometimes an existing agent needs better observability and policy rather than a rebuild. The engagement should match the operational gap.
This approach also keeps model choice in perspective. Model capabilities and pricing can change. A well-designed operating layer may help an enterprise test those changes without rebuilding identity, state, evaluation, cost controls, and human escalation for each provider decision.
The differentiator may be operational
The Temporal survey found that its self-described successful cohort experienced issues about as often as others while reporting better results.[1] That association challenges the idea that maturity means eliminating failure, but it does not prove which practices caused the difference. One interpretation is that stronger operating loops help teams see, contain, and learn from failure.
The report also found that successful teams use more tools, search more places for help, and show greater trust in agent output.[1] Because success in the survey is self-reported, these relationships should be treated as correlations rather than proof of causation. Still, the pattern is coherent: competence compounds. Teams with stronger operating practices can absorb more tools and more use cases because they have a way to judge what is working.
A useful strategic question for 2026 is not only how many agents an organization can launch. It is whether the organization can turn each launch into a governed, observable, economically sound operating capability. The survey indicates that adoption is rising within its sample. Each organization should measure whether its operating model can support that adoption at the scale and risk level it intends.
Four decisions to carry forward
- 1In Temporal's 2026 survey sample, 80.8% reported daily-or-more agent use and 41.1% reported agent issues daily or more often.
- 2The survey supports examining operating discipline alongside speed, while its self-reported correlations do not establish causation.
- 3This report proposes six readiness layers: state, identity, orchestration, evaluation, economics, and human accountability.
- 4A phased program can establish useful evidence for one well-scoped workflow; set the timing after reviewing access, complexity, and risk.
Turn agent activity into an operating capability.
Start with one workflow. Define the authority boundary. Build the evidence layer. Expand autonomy only when the system earns it.
Design your operating modelTemporal commissioned Qualtrics to survey 650 AI-agent users between April 29 and May 25, 2026. After quality review, the published analysis covered 554 engineers and engineering leaders, primarily in the United States and the United Kingdom. Comparisons involving the successful cohort are based on respondents' own assessment and show association, not causation.
[1]Temporal Technologies, "The State of Development 2026," August 25, 2026. https://temporal.io/reports/state-of-development-2026
[2]National Institute of Standards and Technology, "Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile," July 26, 2024, updated April 8, 2026. https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence
[3]OpenTelemetry, "Generative AI Semantic Conventions," accessed August 26, 2026. https://opentelemetry.io/docs/specs/semconv/registry/attributes/gen-ai/
[4]FinOps Foundation, "FinOps for AI," accessed August 26, 2026. https://www.finops.org/framework/technology-categories/ai/
[5]Amazon Web Services, "What is Amazon Bedrock AgentCore?" accessed August 26, 2026. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/what-is-bedrock-agentcore.html