The challenges of deploying agentic AI in enterprise systems

Enterprise software teams are being pushed into a contradiction: they are expected to embrace agentic AI quickly, even as the technology remains too unreliable for many of the environments where it is being deployed. Gartner has predicted that more than 40% of agentic AI projects will be cancelled by the end of 2027, while business surveys continue to show that executives see AI as central to competitiveness. The tension is especially visible inside ERP, finance, supply chain, HR and ...

The underlying problem is not that AI has no value. It is that general-purpose models are being placed into systems that depend on context, configuration and control. In enterprise software, a recommendation that sounds sensible is not enough. What matters is whether it remains correct once it touches downstream approvals, accounting rules, compliance checks and integration logic.

That is why so many projects stumble after the demo stage. A model may produce a persuasive summary, propose a plausible change or suggest a workflow, but still fail to understand how one action affects another. In a finance system, a small adjustment can disturb reconciliations and period-end close. In procurement, an approval change can bypass validation rules that were meant to protect invoice processing. In HR, a process update can accidentally skip a compliance checkpoint. These are not language problems. They are systems problems.

The term “agentic AI” has also become too broad to be useful on its own. It now covers everything from simple automation scripts to complex multi-agent orchestration, which obscures the real question: can the system operate safely inside a live business process? Some tools generate answers. Others execute actions. Enterprise systems need something more demanding, namely an understanding of how tasks interact across modules, permissions and controls.

In practice, genuine agentic behaviour requires more than planning and execution. A system must observe the current state of the application, understand what that state means in business terms, act across multiple steps and adapt when outcomes change. Even then, it still needs domain knowledge: terminology, dependencies, constraints and failure modes. Without that, the system is effectively guessing.

That is where general-purpose AI breaks down. Large language models are good at summarisation, question answering and broad reasoning over text. Enterprise environments are different. They are built on configuration-driven processes, interlocking permissions and workflows that often extend across several systems. Oracle Fusion is a useful example because a seemingly local change in one module can create unexpected effects elsewhere.

In Oracle Fusion Financials, for instance, a cost accounting adjustment that appears limited in scope can alter subledger entries, affect fixed asset depreciation and disrupt intercompany eliminations during consolidation. In Oracle Fusion Procurement, a change to an approval rule can interfere with three-way match controls and allow invoices to move ahead without the expected goods receipt validation. In Oracle Fusion HCM, a modification to a compensation workflow can unintentionally skip a compliance step tied to restricted roles. A general model may describe each change neatly, but without tenant-specific knowledge it cannot reliably predict what will fail.

That is why inference accuracy matters so much in enterprise AI. Benchmarks that look impressive in the abstract do not necessarily reflect how a model behaves when it has to analyse configuration impact, verify integrations or reconcile financial logic. A system can generate text that sounds correct while still being operationally wrong. In enterprise software, those are very different outcomes.

Domain-specific AI is one response to that gap. It usually combines several elements: models trained or fine-tuned on relevant data, retrieval systems grounded in enterprise knowledge, orchestration layers that understand workflow behaviour and policy enforcement that embeds business rules and compliance constraints. The aim is not simply to answer questions, but to improve decisions and actions within a defined operational context.

Specialisation often matters more than size. Smaller models built for a narrow task can reduce ambiguity, improve reliability and respond faster than larger general-purpose systems. They are also easier to deploy in private or on-premise environments, which matters when sensitive financial, compensation or supplier data must remain tightly controlled. In enterprise settings, speed is useful, but trust is essential.

That trust becomes even more important as AI moves from advisory use cases to autonomous action. Black-box decision-making creates obvious risks: errors can cascade across dependent processes, teams may not understand why a system acted as it did and governance gaps can emerge when sensitive data is used without enough oversight. Adoption also slows when operators cannot inspect or control the system.

For that reason, responsible implementations usually include detailed logging, explainability layers, role-based approval and human review for higher-risk actions. IDC has said that most critical AI-driven decisions still require some form of human oversight, even if that adds friction. In regulated environments, that friction is often the price of accountability.

The companies that are making progress are generally taking a staged approach rather than attempting broad deployment from the outset. A typical path begins with low-risk pilot use cases such as integration checks or configuration validation, then expands into regression testing and patch validation, before adding dependency analysis and broader workflow awareness. Only later do organisations begin to scale automation more widely, and only where they can measure the impact clearly.

The lesson for developers is straightforward. Enterprise AI should be treated as part of the system architecture, not as a bolt-on intelligence layer. Success will come less from chasing the newest model name and more from designing for reliability, observability and control. In complex software environments, every action has consequences. The teams most likely to succeed will be the ones that understand precisely where AI fails, and build around those limits.

Source: Noah Wire Services