A demo of an AI agent runs in a clean room. Inputs are predictable, the tool set is narrow, and somebody on the team quietly nudges a stuck conversation back on track before a prospect notices. None of the protection survives the move to production, where inputs turn ambiguous, tool sets expand, and nobody is standing by to nudge anything.
Agentic systems do not rescue weak engineering. They amplify whatever already exists underneath them: every gap in observability, every missing test, every unclear line of ownership gets larger once an agent starts making decisions and taking actions independently. The pattern shows up clearly in two recent studies, one from inside engineering teams and one from the executives accountable for them.
What the Production Data Shows
LangChain ran its State of Agent Engineering survey from November 18 to December 2, 2025, collecting 1,340 responses from engineers, product managers, and business leaders. Technology workers made up 63 percent of respondents, with financial services at 10 percent, healthcare at 6 percent, and smaller shares from education, consumer goods, and manufacturing. Company size skewed toward smaller organizations: 49 percent had fewer than 100 employees, while only 9 percent worked at companies with 10,000 or more.
Adoption has moved past the pilot stage for most respondents. The survey found 57.3 percent already running agents in production, with another 30.4 percent actively building toward deployment. Pilots are no longer the dominant story. Production is.
Quality is the dominant problem inside the production reality, cited by 32 percent of respondents as the single biggest barrier, covering accuracy, relevance, consistency, tone, and adherence to policy. Latency trails close behind at 20 percent. The two numbers point to the same underlying issue: getting an agent to work reliably is harder than getting it to work once.
Observability has kept pace better than evaluation has. LangChain found 89 percent of organizations have implemented some form of agent observability, and 62 percent have detailed tracing covering individual steps and tool calls. Among teams already running agents in production specifically, the same figures climb to 94 percent observability and 71.5 percent full tracing. Evaluation lags noticeably: 52.4 percent run offline evaluations against test sets, only 37.3 percent run online evaluations in live traffic, and even among production teams the online-eval figure reaches just 44.8 percent. Human review remains the most common evaluation method at 59.8 percent, with LLM-as-judge close behind at 53.3 percent.
The pattern across the survey is consistent. Teams can see what their agents are doing far more easily than they can systematically judge whether the agent did the right thing.
The View From the Top Looks Worse
If engineers describe a quality and evaluation gap, the people accountable for the systems describe something closer to a control gap. IBM’s Institute for Business Value surveyed 2,000 C-level technology executives globally and published the results on June 8, 2026. Two-thirds of the surveyed CIOs and CTOs said they are accountable for AI systems they do not fully control. Seventy percent said their teams deploy technology faster than IT can track it. Seventy-seven percent said AI adoption is outpacing their organization’s governance capability. Only 11 percent said they feel completely prepared for the scale of AI agent deployment headed their way, even as the same executives expect a 38 percent increase in the number of deployed agents by 2027.
IBM CIO Matt Lyteson framed the shift directly in the company’s press release: “For CIOs and CTOs, the challenge now is scaling AI systems that operate continuously and autonomously.” The line captures the structural change agents introduce. A traditional application waits for a request and returns a response. An agent keeps running, keeps deciding, and keeps acting, well past the point where a human last checked in on it.
Why Demos Survive and Production Doesn’t
A demo environment removes nearly every condition breaking agents in the field. Inputs are clean rather than ambiguous. The tool set is small and well understood rather than sprawling across a dozen internal systems with inconsistent permissions. The user is friendly rather than adversarial or simply confused. Cost and rate limits rarely bind. Ownership of any failure is obvious, because one person is running the show.
Production removes all five protections at once. Ambiguous inputs arrive constantly. Stale data sits behind tools the agent calls without knowing the data is stale. Permission boundaries vary by system, user, and action. Retries and rate limits introduce timing problems a demo never faces. Audit and compliance requirements demand a record of what happened and why, not a correct-looking final answer alone.
Agentic systems raise the stakes further because they do more than answer questions. They choose tools, mutate state, and chain decisions together across multiple steps, so a single weak link early in a chain compounds into several downstream failures before anyone catches the first one.
A Taxonomy of Production Failure
Production failures in agentic systems tend to fall into a recognizable set of categories rather than appearing as one-off bugs.
Quality failures cover wrong, inconsistent, or off-policy outputs, the issue LangChain’s respondents named most frequently.
Latency failures show up when an agent’s multi-step reasoning and tool-calling chain takes too long for the workflow it serves, frustrating users even when the eventual answer is correct.
Integration failures occur where an agent meets an existing system never designed for autonomous callers, surfacing brittle APIs, inconsistent data formats, and undocumented edge cases all at once.
Permission failures appear when an agent’s access does not match its intended scope, either because it can reach more than it should or because overly tight restrictions cause it to fail tasks it was meant to complete.
Memory and context failures emerge across longer sessions, where an agent loses track of earlier decisions, repeats work, or contradicts itself within the same conversation.
Tool failures happen when an external system the agent depends on times out, returns malformed data, or behaves inconsistently, and the agent has no good fallback beyond retrying blindly.
Silent success claims are arguably the most dangerous category: an agent reports a task as complete when it only partially succeeded or failed outright, because nothing in the system challenges the agent’s self-report.
Governance failures sit above all the others, the IBM-style problem of nobody owning the full picture of what an agent can do, has done, and is currently doing across an organization.
A Practical Framework: Trace, Evaluate, Constrain, Recover
Consider a customer-refund agent as a worked example, since the failure modes above show up concretely in a workflow most engineering teams can picture.
Every run gets traced first. A complete trace captures the run identifier, user or session, prompt version, model version, tool schema versions, the identifiers of any retrieved context, the policy rules in force, every tool call made, latency, token usage, and the final response delivered to the customer.
Evaluation happens at three levels rather than one. Run-level evaluation checks whether the final answer was correct, on-tone, and policy-compliant. Trace-level evaluation checks whether the agent picked the right tool, called it with valid parameters, handled any errors gracefully, and cited the right source for its claims. Thread-level evaluation checks whether the agent stayed consistent across a multi-turn conversation rather than contradicting an earlier statement.
Circuit breakers sit on top of each level. A confidence score below a set threshold routes the conversation to a human rather than letting the agent guess. A refund amount above a set threshold requires human approval before it executes. A failed or inconsistent tool call blocks the agent from telling the customer the task is done, routing instead to a fallback path. A session exceeding a maximum number of tool calls or a cost budget stops and escalates rather than continuing indefinitely.
Failures then feed back into the eval set on a schedule. Production traces get sampled weekly, high-severity failures and emerging failure clusters get added to the offline evaluation set, and the full eval suite reruns before any prompt, model, or tool change ships.
The pattern across LangSmith, MLflow Tracing, Arize Phoenix’s OpenInference conventions, Galileo, and open-source options such as Langfuse is consistent even though the products differ. Each captures a run as a structured trace rather than a black-box transcript, breaking the trace into spans for model calls, retrieval steps, tool invocations, and guardrail checks. The direction of travel across agent tooling runs toward OpenTelemetry-compatible standards, so agent telemetry can connect to the observability systems engineering teams already operate rather than living in a separate AI-only dashboard nobody else checks.
The Counterargument Worth Taking Seriously
None of the above means agents are a bad bet. Plenty of agents perform well inside narrow, well-instrumented workflows where the tool surface stays small, inputs are typed, and policy boundaries are explicit. The winning pattern emerging from the LangChain and IBM data alike is constrained autonomy rather than unconstrained autonomy: a small tool surface, clear policy boundaries, real observability, real evaluation, and human escalation reserved for high-impact actions.
The Real Differentiator Going Forward
The data points in one direction. Agentic AI amplifies the engineering discipline a team already has, for better or worse. A team with strong tracing, real evaluation coverage, and clear escalation paths will see an agent extend the existing discipline into new workflows. A team lacking such guardrails will see an agent expose the gap faster and more visibly than a traditional application ever would.
The best agent teams emerging from the current period look less like prompt engineers chasing clever wording and more like mature SRE, security, and product teams who happen to be operating a new kind of system. Organizations betting on agentic AI without the operational foundation are not betting on the technology. They are betting nobody notices the gap until it is too late to matter.
The post Agentic AI Won’t Fix Bad Engineering, It Amplifies Whatever Is Already There appeared first on .
