Cursor shipped auto-review as the default for all new users. Not as an opt-in feature, not as a pro upgrade, but as the baseline experience: a classifier subagent that reviews every action in context before deciding whether to allow, block, or ask for approval. According to Cursor's own evaluations, it achieves 97% accuracy, with most misses near ambiguous edges.
This is the clearest signal yet that agentic AI has crossed the threshold from research curiosity to production infrastructure. The milestone isn't that agents work in demos—they've worked in demos for years. The milestone is that companies are willing to ship them as the default experience to every user, betting that the value of automated review outweighs the cost of the 3% error rate.
The bet appears justified by deployment data. Research conducted in collaboration with Harvard on Perplexity's Computer agent shows workers finishing tasks in 87% less time at 94% lower cost compared to search alone, with higher satisfaction scores. These aren't toy tasks or synthetic benchmarks—this is sustained real-world usage across months, the kind of duration where novelty effects fade and friction surfaces. The time and cost reductions held. Perplexity integrated Deep Research as a native skill inside Computer, built on what they call "Search as Code" architecture where the model writes code that assembles search itself, running thousands of retrieval steps in parallel. They've made Claude Fable 5 available to Pro and Max users as the orchestrator model for long-running agentic workflows, positioning Computer not as a chat interface with extra steps but as a fundamentally different substrate for knowledge work.
The production maturity is real. The question is what happens when you scale beyond early adopters who understand the failure modes and can route around them. And here the 97% accuracy figure starts to look less reassuring.
A 3% error rate sounds acceptable until you realize errors compound across multi-step workflows. The longer the workflow, the more likely something breaks silently.
A 3% error rate sounds acceptable until you realize errors compound across multi-step workflows. The longer the workflow, the more likely something breaks silently—and "silently" is the operative word, because the failure mode isn't that the agent crashes or returns an error message.
Cursor's framing of the auto-review feature reveals they're already treating this as a tool design problem, not a model capability problem. The "classifier subagent" isn't a concession to weak reasoning—it's an architectural choice to create a decision boundary between the agent's actions and their execution. The agent proposes, the classifier reviews, and only then does the action proceed. This is tool boundary engineering: wrapping the dangerous parts of an agentic workflow in guardrails that reduce the blast radius of mistakes.
It's also an implicit acknowledgment that the bottleneck has shifted. The limiting factor for agentic AI in production is no longer whether models can plan or reason through multi-step tasks. The limiting factor is whether we can build tools that models can reliably invoke without silent errors, overlapping schemas, and compounding mistakes.
MIT and Microsoft research on agentic workflow optimization makes the scale of the tool design problem visible. Their system, Murakkab, used only about 35% of the computation required by other methods and consumed only about 27% as much energy, for less than 25% of the cost of traditional approaches—not by making models smarter, but by intelligently configuring which models and tools to use, how to allocate hardware resources, and how to balance tradeoffs like speed versus accuracy. The researchers note that "the space of possible configurations is so large" that developers can't optimize manually. An agentic workflow is a system composed of several autonomous AI agents that collaboratively use various models and tools—databases, Python programs, APIs—to dynamically complete multi-step tasks. Each component has its own configuration options, often offered by different companies, and the combinatorial explosion makes manual optimization impractical.
But configuration complexity is only part of the tool design problem. The deeper issue is that most tools exposed to agents weren't designed with agents in mind. They were designed for human developers who understand context, can disambiguate edge cases, and notice when something looks wrong. Agents don't have that situational awareness. They take the API surface at face value.
The Model Context Protocol documentation surfaces where this breaks. An MCP server sits between the model and an external system—a database, a file system, a third-party API. It registers its capabilities, receives structured tool calls from the client, executes them, and returns results in a format the model can work with. The abstraction is clean until you trace a real request. Say a model needs to query a database. It calls the database_query tool with parameters. The server runs the query and returns results. But what happens if the query is malformed? What if the database is temporarily unavailable? What if the query succeeds but returns an empty result set that could mean either "no matching records" or "the search criteria were too narrow"?
The server has to make decisions about error handling and response formatting that cascade into the model's next decision. If the server returns a generic error message, the model may retry with identical parameters. If it returns an empty result without context, the model may confidently report "no data found" when the correct action was to broaden the search. If it returns partial results without signaling truncation, the model may proceed as if it has complete information.
These aren't hypothetical failure modes. Research on agent evaluation suggests that agent failures often trace to the action layer—tool call verification, argument validation, outcome verification—not the reasoning layer. An agent can reason correctly about what to do and then call the right tool with malformed arguments. It can call the tool correctly and misinterpret the response. It can interpret the response correctly and fail to update state properly before the next step. Each of these is a tool boundary problem: a mismatch between what the model expects the tool to do and what it actually does.
The gap exists because we don't yet have a software engineering discipline for designing tools that models can use without breaking. Human-facing APIs assume the caller will read documentation, handle errors intelligently, and notice when behavior deviates from expectations. Agent-facing tools need something different: unambiguous success signals, argument validation that fails fast rather than proceeding with coerced types, response formats that make truncation and partiality explicit, and error messages that distinguish between retryable failures and structural problems.
Cursor's classifier subagent is one design pattern for managing this: a dedicated component that reviews tool calls before execution and decides whether they're safe.
Perplexity's architecture suggests another approach: rather than exposing raw external APIs to models, build higher-level abstractions specifically designed for agent invocation. Their "Search as Code" model writes code that assembles retrieval primitives, rather than calling a monolithic search API. This pushes complexity into a layer where it can be validated and optimized programmatically, rather than relying on the model to get every detail right. But it only works because Perplexity controls the full stack. Most agent deployments are integrating tools they didn't build and can't redesign.
The differentiator is whether you've built tool boundaries that fail gracefully, signal clearly, and compose reliably.
This is the unglamorous work that determines whether agentic AI stays confined to narrow domains with well-defined tool surfaces or expands to the messy, ambiguous workflows where most knowledge work actually happens. Cursor shipping auto-review as the default is proof that agents work well enough to deploy at scale. The 3% error rate is proof that tool design, not model capability, is now the binding constraint.
Even as the broader conversation about AI reliability correctly emphasizes that models will always be unreliable—that hallucination is structural, not a bug to be fixed—the immediate deployment bottleneck is different. For teams shipping agents today, tool boundary engineering is the more actionable problem. You can't make models perfectly trustworthy, but you can design tools that degrade gracefully when models misuse them. The gap between those two problems is where production agentic AI currently lives: capable enough to be useful, unreliable enough that the infrastructure around the model matters more than the model itself.