Most AI agent failures look like model problems but are actually architectural mistakes. A new research paper proposes a framework for understanding and fixing the real culprit: the boundary between what an AI system proposes and what actually gets executed in the real world.

Why Are AI Agents Failing in Production?

When an AI agent goes wrong in a real business setting, the blame often lands on the language model itself. But researchers have discovered something surprising: the model is rarely the problem. A review of 21 published AI agent failure post-mortems found that 71% of failures actually trace back to weaknesses in how the system is architecturally designed, not to the AI's reasoning ability. One example from the research illustrates this perfectly: a customer receives a 90% discount not because the AI made a bad decision, but because no policy gate existed between the AI's proposal and the actual write to the database.

This distinction matters enormously for teams building AI agents. As language models improve with each generation, their per-call accuracy increases and their error rate shrinks. But this improvement alone does not guarantee better agent performance in production. The real load-bearing surface of a production agent system is the architecture surrounding the model: how state is preserved across pauses, how work is split and recombined, and critically, who stops a hallucinated write before it ships to customers.

What Is the Stochastic-Deterministic Boundary?

Researchers have named the critical architectural primitive at the center of every production AI agent system: the stochastic-deterministic boundary, or SDB. Think of it as a four-part contract that governs how an AI's proposal becomes a real system action. The four parts are the proposer (the language model itself), a verifier (a deterministic check on what the model proposed), a commit step (the durable write that happens after verification passes), and a reject signal (the typed response sent back to the AI when verification fails).

This boundary is not new in practice. An audit of five widely-used open-source agent frameworks found that 19 of 21 LLM-to-action call sites already include explicit verifier-and-commit logic. What is new is naming it explicitly and understanding it as a design primitive. By naming the boundary, practitioners can now design around it intentionally rather than rediscover it through failure.

How to Design Stronger AI Agent Architectures

• Implement explicit verification: Add a deterministic check between the AI's proposal and any system action. This verifier should validate that the proposal meets business rules, policy constraints, and safety thresholds before any write occurs.
• Separate proposal from commitment: Ensure the AI proposes an action, the system verifies it, and only then does a durable write happen. This three-step process prevents hallucinated outputs from reaching customers or databases.
• Design reject signals carefully: When verification fails, send a typed response back to the AI that explains why the proposal was rejected. This feedback loop helps the AI learn the boundaries of what is acceptable.
• Choose patterns based on workload: Different types of agent tasks (conversational, autonomous, long-horizon) require different architectural patterns. Select the pattern that matches your specific runtime class and use case.

The research identifies six distinct patterns that compose the boundary differently depending on the runtime class and workload. Each pattern traces its lineage to a specific result from distributed systems engineering, including the actor model, sagas, workflow nets, and the log. The key insight is that when the worker is stochastic (unpredictable, like an AI), not all distributed-systems patterns transfer directly. The research maps out what does and does not work.

The Reliability Equation That Changes Everything

The researchers propose a simple but powerful way to think about long-run agent reliability. They model it as y(t) = μt + σξ(t), where y(t) is observed reliability over time, σ represents per-call variance from the AI's stochastic nature, and μ represents architectural momentum set by pattern choice and SDB strength. Here is what makes this equation transformative: as language models improve with each generation, σ shrinks. But μ, the architectural momentum, does not change on its own just because the model got better. It is determined by the architecture you build.

This means that as models compress their per-call variance, the dominant lever on long-run reliability shifts from model quality to architectural design. In other words, picking the right architecture and strengthening the boundary becomes more important than upgrading to a newer, more capable model. This is a fundamental reshift in where teams should focus their engineering effort.

The research also names a specific failure mode that the boundary makes legible: replay divergence. This occurs when an AI-based system consuming a deterministic event log produces different downstream outputs when the model version changes. Understanding this failure mode helps teams design systems that are robust to model updates.

What Does This Mean for Teams Building AI Agents?

The paper provides a five-step selection methodology with decision predicates and a diagnostic procedure that maps observed production failures to specific architectural patterns. Teams can use this methodology to make explicit architecture decisions, document them in an architecture decision record, and then diagnose failures by matching their symptoms to a failure-signature catalog.

One concrete example from the research demonstrates the methodology applied end-to-end to five different workloads spanning conversational, autonomous, and long-horizon runtimes. One workload was built out as a runnable reference implementation using the public IBM Telco Customer Churn dataset, showing that the methodology is not purely theoretical but can be applied to real business problems.

The implications are significant. As AI agent adoption accelerates across enterprises, teams that understand and design the stochastic-deterministic boundary explicitly will build more reliable systems. Teams that treat agent failures as model problems and respond by upgrading to the latest language model will continue to miss the real issue. The architecture is the load-bearing surface, and naming it is the first step toward designing it intentionally.