I keep seeing the same pattern in agentic AI conversations with enterprise teams. They start with “pick a model, wrap it in an agentic framework and point it at our data.” They treat model selection as a strategic decision and the integration work as somebody else’s problem.

I want to say this directly: If your agentic AI project is failing, your problem is almost certainly not the model, and it is probably not even the agent. Your problem is that you treated the integration work as somebody else’s problem to solve after the demo.

Current frontier models can do most of what enterprise problems require. The model is rarely the limiting factor. The limiting factor is the systems underneath, and whether they can accept the agent’s output back into the operational flow without breaking three other systems downstream.

Compliance: A Design Constraint, Not An Afterthought

The second pattern I see is teams treating compliance as something to add on top of a working system after the fact. The approach is to build the agent first and figure out governance afterward. This ordering is almost always wrong.

The version of agentic AI promoted most heavily in the last 18 months is the one that fully automates a process end-to-end. No humans in the loop, no review gates and decisions executed directly by the system. Regulated industries will not allow it, plus legal and compliance teams will not sign off on a system where an algorithm makes a binding operational decision without human review. Even in less regulated environments, one wrong automated decision multiplied by the volume an agent operates at costs more than skipping the review step.

Compliance is a set of architectural decisions: where the human gates sit, what the agent writes to its log, who can override a recommendation and under what conditions. Retrofitting these onto a system designed for full autonomy costs more than building for human-in-the-loop review from day one.

Treat the agent as a senior specialist, not a replacement for the team. It prepares a recommendation and flags what it is not confident about. A human reads it and makes the final decision. Accountability stays with the person, where it needs to be for legal reasons. This sounds like a limitation, but it is actually what makes deployment possible.

The real question inside a large enterprise is rarely whether the model can perform the task. The real question is whether you can get the system through legal review, compliance review, change management and whichever business unit is nervous about losing control. Human-in-the-loop architecture makes that sequence possible. Full autonomy, in 2026, does not.

What This Is Part Of And Why The Right Metric Matters

The work I am describing has a name. At my company, we call it pragmatic AI software engineering. The discipline that gets enterprise AI to production is an engineering discipline, not an AI discipline. Most of the failures the industry is currently calling AI failures are engineering failures with AI on top.

An enterprise deployment that I worked on helps to illustrate the difference. A fleet operator managing more than 80,000 vehicles and transporting millions of students each day already had a sophisticated optimization process in place. The bottleneck was not the mathematics. It was the work required to make the mathematics usable.

Each week, an operations analyst spent days pulling information from more than 20 disconnected enterprise systems, consolidating it into a single dataset that could be run through a mixed integer programming (MIP) model. The optimization itself required specialist expertise to configure and interpret, which meant the cycle from preparation to recommendation consumed most of the week. There was little capacity left to investigate additional opportunities or edge cases. That is the part of enterprise AI work that rarely appears in demos.

The deployment introduced an agent layer that could access the underlying systems, prepare inputs for the appropriate optimization approach, interpret outputs in plain language and surface recommendations through conversational and web interfaces. But the visible interface was not where most of the effort went.

The harder work is often underneath: creating unified access across systems that were never designed to interoperate, reconciling conflicting identifiers, engineering acceptable response times and creating enough logging and traceability for decisions to withstand audit and review.

After deployment, optimization time fell by 68%, but the more important outcome was a 29% increase in optimization savings. The first number suggests the same work happened faster. The second suggests that different work happened. Analysts who previously spent most of their time assembling data shifted toward reviewing recommendations and investigating higher-value cases that had previously gone untouched.

That distinction matters because it reflects how enterprise agentic AI actually succeeds. The value does not come from choosing a better model. It comes from designing the integration, governance and operational architecture that allows intelligence to become part of the workflow.

That is the version of agentic AI that gets deployed in regulated, complex, fragmented enterprise environments, and that stays deployed once it gets there. It is the version that treats agentic AI as an engineering problem.

The version that fails is the version that thinks the question is which model to use.

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?

Source link