Removing Oracle Integration Cloud: giving AI agents a native path into Oracle ERP.
Enterprise integration has followed the same pattern for years. A company adopts an ERP, then builds a layer of workflows around it using tools such as Oracle Integration Cloud, Workato, or Boomi.
These platforms solved a real problem. They connect systems that spoke different protocols, transformed payloads, scheduled jobs, and moved data between applications.
The trouble begins when every business process becomes its own permanent integration. A supplier upload gets one flow. Period close gets another. Journal import gets another. Each variation adds mappings, credentials, deployment steps, monitoring, and specialist knowledge. After several years, the integration platform holds a second version of the company's business logic.
The result is brittle. It is expensive to change and understood by too few people.
We replaced that model with an agentic architecture. The agent connects to a governed library of native enterprise APIs and builds the required execution plan at runtime. Oracle Integration Cloud no longer stands between the agent and Oracle ERP.
Integration work has become a scarce skill
Traditional integration programs depend on specialists.
Within one delivery network we worked with, only two engineers had the depth of Oracle Integration Cloud experience needed to build and troubleshoot the most complex workflows. An experienced specialist can move quickly because they have solved similar mappings before. Scarcity also raises the rate, often to twice the cost of a general application engineer. This creates a queue around a small group of people.
In one engagement with a large logistics company, the application managed services team carried a six-to-eight-month backlog for new integrations. The business could describe what it needed in a day. The request still had to wait months for someone with the right platform knowledge to design, build, test, and deploy it.
The delay has little to do with the complexity of every request. Many integrations perform familiar work:
- Call an API
- Translate a few fields
- Resolve a business name to a system ID
- Submit a scheduled process
- Poll for completion
- Return the result
The scarce resource is the person who knows where all those steps live inside the integration platform.
The hidden cost often appears after the contract is signed
Integrations and data conversions are frequently under-scoped during large implementations. A proposal may describe a $10 million ERP program while leaving dozens of required system connections vague. Once delivery begins, the missing work surfaces. The project grows to $12 million because the business still needs payroll, procurement, banking, expense, logistics, and reporting systems connected before the ERP can operate.
Commercial pressure encourages optimistic scoping. A lower opening number is easier to approve. The integration bill arrives later, when the customer has less room to change direction.
the estimated cost to connect Coupa to an ERP system from scratch — even though other companies had already solved much of the same problem.
This pattern repeats because conventional integrations are built for one customer, one environment, and one fixed workflow. Knowledge gained on the previous project rarely becomes a reusable execution capability.
A governed API library changes the economics
Our agentic architecture gives the AI agent a library of approved operations for each enterprise system.
For Oracle Fusion, that library includes:
- Enterprise Scheduling Service jobs through SOAP
- Oracle REST resources and lists of values
- BI Publisher reports and catalog services
- FBDI file generation and UCM upload
- Job-status polling and execution-log retrieval
For SAP, the same pattern can use approved OData services, REST and SOAP APIs, and controlled BAPI or RFC operations. For Workday, the library can expose REST APIs, SOAP services, reports-as-a-service, and authenticated business-process operations.
This migration is an Oracle case study. The same governed-tool pattern can extend to SAP and Workday through their native APIs, but those systems fall outside the scope of this post.
The agent receives a business objective, determines which approved operations are required, resolves the parameters, and executes the sequence. It observes each response and adjusts the next step when the system returns new information.
The execution plan is assembled for the task rather than deployed as a separate integration. Its execution state — completed actions, external job IDs, checkpoints — is persisted so an interrupted workflow can resume safely without repeating work. We no longer need a separately deployed integration for every small variation of a workflow.
This is what "creating integrations on the fly" means in practice. The agent composes approved capabilities at runtime. Credentials remain in the application layer. Policies still control which operations the user may run. Every call can be logged and audited.
Replacing OIC in Oracle finance workflows
Our Oracle migration began with the workflows already running through OIC. Most of them eventually called an Oracle Enterprise Scheduling Service job. The OIC flow transformed parameters, submitted the job, waited for completion, and returned a response. We moved those responsibilities into a reusable Oracle client.
The client can:
- Submit any approved ESS job
- Poll the Oracle request
- Download its execution log
- Upload FBDI files to Oracle UCM
- Return the Oracle request ID, status, phase, and result
We also built a configuration-driven mapping engine. Each process declares its Oracle job, ordered parameters, static values, user inputs, date rules, conditional mappings, and lookup requirements.
Some workflows need more than a scheduled job. The runtime can call Oracle REST endpoints to resolve IDs, use BI Publisher reports when no suitable REST lookup exists, and run validation logic directly in code.
Journal import is a good example. The new workflow builds the FBDI archive, uploads it to UCM, loads the file into GL_INTERFACE, starts Journal Import, and returns Oracle's execution details.
We migrated approximately 100 legacy integrations across the wider integration estate. Within the Oracle month-end process registry, 39 workflows now run through native capabilities:
The agent now has a native path to the ERP
The old execution path crossed several systems:
The AI model never receives an ERP password. It cannot open an arbitrary network connection. Our backend resolves the user's identity, applies policy, injects credentials, validates the operation, and records the result.
The agent gains a direct operational link to the ERP through governed code. The ERP remains the final authority. Oracle, SAP, or Workday can reject an operation when the user lacks permission or a business prerequisite has not been met.
Failures become easier to diagnose
A static integration often hides the most useful error behind several layers of transformation. When an Oracle job failed through OIC, the agent might receive a generic failure response. An engineer then had to trace the request through the agent, application logs, OIC monitoring, and Oracle.
Native execution returns the Oracle request ID and job log. The agent can inspect the evidence and determine whether:
- A period is closed
- An upstream process has not completed
- A ledger or business unit is invalid
- Interface rows were rejected
- The Oracle job completed with a warning
- A required setup value is missing
The agent can explain the cause and propose the next action. Support moves from platform archaeology to evidence-based diagnosis.
The measurable savings
The first saving is platform cost. Oracle's public metered pricing lists OIC Standard at approximately $0.8456 per hour for a 5,000-message pack and Enterprise at approximately $1.6911 per hour. A continuously provisioned message pack costs roughly:
| Environments | Standard | Enterprise |
|---|---|---|
| One | $7,400 / yr | $14,800 / yr |
| Two | $14,800 / yr | $29,600 / yr |
| Three | $22,200 / yr | $44,400 / yr |
These figures use public list pricing before contract discounts. Actual savings depend on edition, consumption model, capacity, and environment count.
The larger saving comes from labor. Two integration specialists billed at roughly $100 per hour represent:
| One week | $8,000 |
| One month | $32,000 |
| One year, full-time capacity | $416,000 |
Deprecating approximately 100 integrations does not automatically remove the full $416,000 annual cost — it removes a large maintenance surface from that cost base. If the two engineers previously spent half their time maintaining existing integrations, the recoverable capacity is about $208,000 per year. Their time can move to higher-value platform work.
+ maintenance hours eliminated × engineering rate
+ new integration hours avoided × engineering rate
+ incident diagnosis hours avoided × engineering rate
+ value of delivering workflows months earlier
The final term often matters most. A six-to-eight-month backlog can delay a close improvement, automation project, or customer launch. Removing that wait creates value long before it appears as a lower software invoice.
Reuse replaces reinvention
A conventional integration becomes an asset for one workflow. An agentic API capability becomes an asset for every workflow that follows.
Once the platform knows how to resolve an Oracle ledger, submit an ESS job, run a BI Publisher report, call a Workday business process, or invoke an SAP service, the agent can reuse that capability in new combinations.
The hundredth workflow should be cheaper than the first. Under the old model, it was often another project.
We removed the integration layer so the agent could work closer to the enterprise system, through controlled code that our engineers already know how to review, test, and extend. The backlog shrinks. The specialist bottleneck loosens. New capabilities become software changes instead of new infrastructure projects.
See it running against a real ERP.
Visit Dayos to see how governed AI agents can execute and diagnose enterprise finance workflows through native ERP APIs.
Visit Dayos↗