Enterprise AI Deployment Enters a New Stage of Fragmentation: After Agents Are Embedded into Software

The common signal released by Oracle, Trintech, and MYOB is that AI is entering organizations along enterprises' existing software systems: some of it enters the core layer of unified business suites, some enters the workbench layer of highly controlled professional processes, and some enters the product layer of everyday business software. This week's real enterprise AI deployment path can be understood according to the level of embedding.

The first model is suite-level embedding, represented by Oracle. Its path this time is highly complete: Fusion Agentic Applications are embedded directly into Oracle Fusion Cloud Applications, with multiple groups of specialized AI agents executing actions within unified enterprise data, workflows, policies, approval hierarchies, permissions, and transaction context, covering scenarios such as finance, supply chain, manufacturing, sales, service, and marketing. This deployment method is naturally suited to entering through core operating processes, because the data has already accumulated inside the suite, the processes have already been orchestrated by the system, and the control framework already exists. AI can therefore enter the execution layer along existing business chains. What enterprises obtain from this is often an improvement in cross-process efficiency, such as reduced manual follow-up, faster exception responses, shorter handoff waiting times, and more continuous customer and operational actions. When mapped to the open-source technology stack, this type of suite-level embedding is closer to a combination of "orchestration layer + model access layer + permission-control layer + observability layer," comparable to the coordinated deployment of capabilities such as LangGraph, LiteLLM, OpenFGA, and Langfuse or Phoenix.

The second model is process-level embedding, represented by Trintech. Its focus this time falls within the vertical workflow of financial close, bringing finance-native AI directly into key "record-to-report" steps, so that AI can continuously provide risk identification, next-step recommendations, task prioritization, document generation, and in-app guidance in journal-entry posting, reconciliations, transaction matching, and close management. The deployment logic here carries strong role-based and process-based characteristics: financial close cycles are short, control requirements are high, repetitive actions are intensive, and audit trails are explicit. As a result, AI can more easily enter daily operations by attaching itself to a specific workbench. The first direct value enterprises see is that the manual burden of journal preparation, reconciliation matching, exception investigation, and close scheduling will decline significantly, while the strength of control and transparency will rise at the same time. If mapped to the open-source technology stack, this type of process-level embedding is more like pressing LangGraph-style workflow orchestration, rules and scoring logic, and Langfuse- or Phoenix-style observability capabilities deeply into a professional workbench.

The third model is product-level embedding, represented by MYOB & Microsoft. The deployment cadence here is closer to everyday software distribution: through a five-year partnership, the two companies will continuously embed AI into MYOB's business management solutions, enabling small and medium-sized businesses and mid-market customers to gradually obtain capabilities such as cash-flow forecasting, a clearer understanding of business performance, reduction of manual work, and customer-facing agentic AI while continuing to use their existing products. At the same time, Microsoft will provide dedicated engineering support and use environments such as Foundry and Copilot Studio to support AI construction, deployment, and scaled rollout. This path is particularly suitable for small and medium-sized businesses, because it is closer to the way everyday business software is used. AI capabilities enter business actions continuously through product updates, and enterprises can gradually absorb intelligence within their existing workflows. The benefits enterprises obtain from this are concentrated in faster everyday business judgment, fewer manual operations, and business insights that are closer to specific work scenarios. When mapped to the open-source technology stack, this type of product-level embedding is closer to a combination of "lightweight agent application layer + batch deployment and governance layer," comparable to task-oriented agent frameworks such as LangGraph or CrewAI, supplemented by model access, permission control, and observability capabilities.

Looking at these three levels together, the reason enterprises accept them first is also clear. After AI enters enterprises through the three paths of suites, processes, and products, its value is very close to real business actions: Oracle covers cross-departmental operating chains, Trintech covers highly controlled professional processes, and MYOB covers high-frequency everyday business actions for small and medium-sized enterprises. Processing efficiency, exception identification, workflow speed, reduction of manual burden, and improved business insight can all be directly perceived by business departments within a relatively short time. This deployment method, which closely follows existing systems and existing roles, also makes it easier for enterprises to first see results in local scenarios before accepting the next round of expansion.

However, the follow-on effects jointly brought by these three paths also deserve separate attention. Suite-level embedding such as Oracle's will grow a powerful network of system-level agents inside core business systems; process-level embedding such as Trintech's will grow highly specialized process segments inside key workflows; product-level embedding such as MYOB's will, through continuous software use, steadily spread AI capabilities in scattered points across the surface of everyday enterprise operations. Efficiency in local enterprise links will therefore improve, but multiple agent nodes distributed across different levels and boundaries will also form at the same time. At this point, the issue enterprises must then address extends to "how these agents scattered across different systems operate together." The faster local benefits are realized, the more overall coordination complexity deserves to be planned in advance. This is precisely the most important point in this week's deployment patterns, and we will interpret it further in the later section, "Bottlenecks and Frictions."

The first category of scenarios that is closer to actual budget allocation this week has already landed in core business software itself. The reason is not complicated: when AI is written as an embedded capability into enterprise-level business suites such as Oracle, or into business management software such as MYOB, the way enterprises pay for it also changes accordingly. Enterprises no longer need to first set up a separate "AI project" and then prove whether this capability can be embedded back into existing systems. Instead, AI is entering enterprises through existing budgets for enterprise resource planning, business management software, and core operating systems. The budget originally came from system upgrades, process digitalization, product capability enhancement, and operating efficiency improvement; now AI gives these investments a more direct business explanation: it can be translated into improvements in cash collection efficiency, workflow speed, manual processing burden, quality of business judgment, and customer response efficiency. For enterprises, the key reason these projects can move more easily from concept to budget is that they serve the main operating processes in the first place, and their value can also be translated into familiar business language.

At the same time, budgets are beginning to spill over from single applications into the unified operation and identity-control layer. The logic of this change is more specific than simply saying that "enterprises are willing to spend money on governance." When enterprises procure software such as Oracle, MYOB, and Trintech, what they first purchase is embedded AI inside each respective system, and what they see in the short term is also efficiency gains in local links. But after these capabilities grow inside different software systems, enterprises will quickly encounter a more realistic problem: multiple agents are already acting in different systems. Who represents whom, who can call what, how cross-system actions should be authorized, when permissions should be revoked, and who leaves a trace and bears accountability when something goes wrong - none of these questions will disappear automatically just because a single application runs smoothly. At this point, the budget focus shifts from "whether the AI inside a certain software product is useful" to "whether these dispersed software AIs can be operated continuously, uniformly, and controllably." The mechanism through which this type of investment forms is also clear: local efficiency gains have already been realized, and new costs and risks will concentrate in the operating order itself. Enterprises therefore need to make formal budget investments to fill the gaps in unified identification, unified authorization, unified deployment, and continuous management.

Overall, what is truly beginning to be budgeted for this week can be condensed into two layers: the first layer is core business software, which explains why AI can enter enterprises more smoothly; the second layer is the unified operation and identity-control layer, which explains why, after seeing local gains, enterprises decide to continue pushing budgets toward deeper operating and control capabilities.

Suite-level embedding will bring system-boundary fragmentation - a network with limited scope. Take Oracle as an example: AI can already understand continuous data such as orders, inventory, procurement, finance, and customer service handling within its own business suite, and can autonomously advance actions along existing processes. Looking only at this suite, operating efficiency and continuity will both improve significantly; once it is placed back into the overall enterprise environment, however, the situation immediately becomes more complex. Real companies usually also use other software such as data platforms, customer-service systems, and regional finance systems at the same time. Agents inside Oracle do not naturally have visibility into the context outside these systems. The result is that actions can proceed continuously inside one system, but cross-system coordination can easily encounter information breaks, judgment misalignment, and inconsistent action sequencing. This is typical system-boundary fragmentation.

Process-level embedding will bring process-node fragmentation - lines that are difficult to connect. Take Trintech as an example: AI has already entered deeply into journal entries, reconciliations, matching, and close management in the financial close process. This segment of the process will therefore become faster, more stable, and easier to control. But the real enterprise work chain extends far beyond this one segment. Contracts, orders, revenue recognition, expense aggregation, and business analysis often remain distributed across other systems and teams. As a result, the close node becomes intelligent first, while the upstream and downstream links before and after it still operate at their own rhythms. Enterprises will soon see a realistic scenario: the middle segment already has strong automatic judgment and execution capabilities, but the connections before and after it still rely on manual confirmation, cross-team communication, and inter-system reconciliation. This is process-node fragmentation.

Product-level embedding will bring entry-point fragmentation - points scattered everywhere. The characteristic of paths such as MYOB's is that AI will continue to enter everyday business software through product updates. Cash-flow forecasting, business insights, automated processing, and customer-related intelligence capabilities will continue to appear in the software interfaces enterprises use daily. Looking only at MYOB itself, these capabilities are still concentrated within the same product system; when placed back into the enterprise as a whole, however, the problem shifts into another form. Enterprises usually do not use only MYOB. A mature company typically has enterprise resource planning, financial control tools, CRM, data platforms, and various regional systems at the same time. As each software vendor embeds AI into its own products, the number of intelligent entry points inside the enterprise will continue to increase. The final situation is that many software products become smarter, and many interfaces can provide recommendations, trigger actions, and advance tasks, yet the enterprise as a whole lacks a unified coordination mechanism. This is entry-point fragmentation.

Looking at these three layers together, the frictions enterprises face afterward will rise rapidly. What enterprises ultimately bear is already an operating environment in which three layers of fragmentation coexist at the same time: there are boundaries between systems, breaks between process nodes, and a continuing increase in software entry points. Such an environment naturally pushes multi-agent coordination into an enterprise-level challenge.

The second core friction comes from enterprises' real choices about their software landscape. Many mature workflows have their own long-formed software preferences. For example, finance teams may be more willing to hand close and controls to tools such as Trintech, because it fits the cadence and audit requirements of the finance function; operations and supply-chain teams often rely more on suites such as Oracle, because they are suited to cross-departmental execution; regional subsidiaries or small business units are more willing to retain business management software such as MYOB, because its deployment threshold is lower and its usage habits fit local teams better. For companies, this coexistence of multiple software products does not represent chaos. It is more like a long-formed division of business responsibilities. Replacing everything with the full product suite of a single vendor often means process reconstruction, team retraining, migration of historical configurations, and internal coordination. The implementation cost is high, and organizational willingness is usually limited.

Risk considerations also make this issue clearer in a structural way. If an enterprise tries to compress its key business processes into a single vendor's full set of AI applications, agent coordination will be more unified in the short term, and procurement will appear simpler; in the long term, however, risks will rise significantly. Once this vendor experiences a system outage, API failure, permission-configuration error, regional service interruption, or key product adjustment, what is affected will not be just one tool, but potentially the entire business chain. If orders, customer handling, collections, close, and business judgment are all entrusted to the same AI-enabled software suite, any major abnormality could evolve into organization-level paralysis. For enterprises that truly depend on continuous operation, retaining multiple software systems in parallel is itself a business arrangement for spreading risk. The issue then turns into another, more realistic requirement: what enterprises need is not to entrust all business to one vendor, but to make the software and agents that will coexist anyway work together under the enterprise's own rules.

Looking at these two types of friction together, the answer is already clear. The issue enterprises face today centers on how to reorganize a bounded network, several separately strengthened line segments, and a growing number of intelligent points scattered across the business surface into an operating system suitable for their own company. What needs to be done first is workflow-level judgment: which links are worth connecting across systems, which links should preserve existing software preferences, which actions are suitable for automatic advancement, and which actions still need to remain under human control. Only after that does system-level construction begin: task orchestration, model access, identity authorization, permission governance, traceability and observability, exception rollback, and cost control. The first part determines the sequence of coordination; the second determines the quality of operation. Together, they constitute the enterprise's own multi-agent workflow.

This is also where NextAI+ Praxis can step in. As unpacked above, suite-level, process-level, and product-level embedding correspond to capability modules at different levels, and all can be mapped to a relatively mature set of open-source technology stacks: workflow orchestration can draw on frameworks such as LangGraph; unified model access and routing can correspond to LiteLLM; identity and permission control can refer to OpenFGA; operational observability and evaluation can be implemented through Langfuse or Phoenix; and lightweight task-oriented agents can be combined with frameworks such as CrewAI. Although Okta has proposed introducing the AI Identity Architect role to govern the problem of multi-agent fragmentation, the value of NextAI+ Praxis lies in providing and executing a strategic and technical solution that addresses the problem at its root. We can help enterprises design and build customized AI workflows around their real business while preserving their existing software landscape, reintegrating intelligent capabilities that already exist across different systems, processes, and entry points, so that bounded networks, process lines, and dispersed intelligent entry points can form a more controllable operating effect within the enterprise's own coordination framework. In this way, the advantages of mature software in their respective links can continue to be retained, and the coordination costs brought by multi-agent fragmentation can have the opportunity to decline further.