Accelerating Enterprise Automation using Agentic AI in Oracle Integration by Biman Sarkar & Prakash Masand & Venkat Chowdhury
Introduction:
Enterprise automation is changing as AI becomes a core part of how systems and processes work together. Instead of depending only on fixed, rule-based workflows, organizations are using AI to make automation smarter, more flexible, and easier to scale. Oracle Integration addresses this transformation by integrating Agentic AI into its platform, embedding intelligence across design and development phases of the integration lifecycle to simplify and scale enterprise automation.
In this blog, we demonstrate how AI Agents transform a flight booking architecture by shifting it from manual or rigid, rule-based workflows to intelligent, adaptive orchestration where the business provides tools, human tasks, and a knowledge base. The AI agent then decides how to execute the task. Instead of following a predictable automation sequence, like “get flight → approval → booking” the AI agent understands user intent, evaluates travel policies, chooses the best flight options, determines whether approval is required, and adapts its next action based on outcomes such as rejection or budget constraints. By reasoning over context and invoking integrations such as flight search, approval workflows, and booking systems as tools, the AI agent enables faster bookings, consistent policy compliance, involve human approval and delivers a more personalized, conversational travel experience while keeping the underlying systems modular and reusable.
Powering the Employee Onboarding Experience with OIC AI Agent and Knowledge Base by Kishore Katta
Introduction
Employee onboarding is one of the most context-heavy moments in an employee’s lifecycle. A new hire on Day 1 needs a laptop, an understanding of leave policy, payroll bank details set up, and a personalized learning path, all while juggling forms, portals, and emails across HR, IT, Finance, and Learning & Development. Traditional onboarding workflows tackle this with a chain of rigid, rule-based integrations. They work, but they break the moment a question deviates from the script.
With the introduction of Agentic AI in Oracle Integration, we can rethink onboarding as an intent-driven conversation. Instead of forcing a new hire to navigate ten different systems, a single conversational AI agent, accessible through Slack, WhatsApp, or a web portal, understands what the employee wants, retrieves grounded answers from a corporate knowledge base, invokes the right backend systems as tools, and routes sensitive actions through human approvers when needed.
In this blog, we walk through an employee onboarding use case powered by OCI Generative AI and Oracle Integration Cloud (OIC) AI Agents, with the OIC Knowledge Base acting as the long-term memory that keeps every response grounded, accurate, and policy-aligned.
The Onboarding Challenge
Priya, a new hire is joining on Monday. Within her first week, she needs to:
1. Request a laptop and accessories suited to her role.
2. Understand HR policies such as leave entitlements, work-from-home rules, dress code, and code of conduct.
3. Update her bank details for payroll, and ask questions about salary structure or lease benefits.
How Equinix is Redefining Enterprise Integrations with Agentic AI in Oracle Integration Cloud by Pradyumna Kodgi
Enterprise users do not think in APIs, integrations, orchestration logic, or backend systems. They think in questions.
At Equinix, business teams needed a faster and more intuitive way to access invoice information from Oracle Fusion. The information was already available, but the experience of retrieving it was still shaped by traditional enterprise integration patterns: predefined inputs, structured requests, and logic-heavy flows maintained by IT.
The business expectation was simple: a user should be able to ask a question from Microsoft Teams and receive an accurate answer from Oracle Fusion. A request could be as straightforward as, “Show me the status of invoice 12345,” or more conversational, such as, “Need invoice details.” From there, the system should guide the user, understand the intent, retrieve the right data, and return a clear response.
With the Agentic AI capabilities in Oracle Integration Cloud (OIC), Equinix and Oracle explored a new approach: shifting from rigid orchestration to intelligent, context-aware integration
The Business Need: Ask Naturally, Get Accurate Answers
The use case started with invoice inquiry. Business users wanted to retrieve invoice status, invoice details, payment information, pending approvals, and overdue invoice information directly from Microsoft Teams.
In a traditional model, users often need to know exactly what to ask and how to ask it. They may be expected to follow a specific format, choose from a predefined menu, or provide data in a way the integration can understand. That format creates friction, especially when different users phrase the same request differently.
ReAct vs Plan & Execute: Choosing the Right Agent Thinking Pattern in Oracle Integration by Kishore Katta
When you create an agent in Oracle Integration (OIC), one of the first decisions you make is how it thinks. OIC exposes two distinct reasoning patterns — ReAct and Plan & Execute — each reflecting a fundamentally different philosophy about how an intelligent agent should approach a task.
This is not a cosmetic choice. The pattern you select shapes how the agent handles unexpected results, how many LLM tokens it consumes, how deterministic its behavior is, and ultimately how well it performs for a given class of problems.
Two Ways to Think
At their core, the two patterns answer one question differently: “Does the agent need to know the full plan before it starts?”
Pattern 01 — Adaptive ⚡ ReAct
Reason + Act — a tight loop where the agent thinks, takes one action, observes the result, then decides the next step. Every action is informed by what just happened. The agent never has a full plan. It navigates step-by-step, adapting its path in real time based on what tools return. “I don’t know exactly where this leads — I’ll figure it out as I go.”
Pattern 02 — Methodical Plan & Execute
Plan first, then execute — in OIC, this is implemented as two separate agents: a Planner agent that decomposes the goal into an ordered list of steps, and an Executor agent (itself a ReAct agent) that blindly runs those steps in sequence. The Planner never calls tools — it only thinks. The Executor never improvises — it only acts on what the Planner prescribed.
Process X12 HIPAA 837 Claim Files – Schema Preparation by Vernon Saldanha
X12 HIPAA 837 documents are standard electronic healthcare claim files used to send billing information from providers to payers. We can process these claims in OIC B2B using our out-of-the-box schemas. However, there is a little bit of preparation that is required to ensure all the variations of a claim file can be handled by our schema. So, let’s take a look at them.
Create a new schema
Under the B2B > Schemas section, create a new X12 HIPAA 837 schema.
Dynamic Connections for REST and SOAP Adapters in Oracle Integration Gen 3 — Part 1: Dynamic Connections by Lavanya Siliveri
How to build multi-tenant integrations in Oracle Integration Gen 3 using Dynamic Connections to switch invoke connections at runtime without code changes or redeployment. This is Part 1 of a 3-part series on dynamically switching connection details at runtime in Oracle Integration Gen 3.
Key Takeaways
• Oracle Integration Gen 3 supports Dynamic Connections — a native feature that lets a single integration switch between different invoke connections at runtime, eliminating per-tenant integration copies or complex switch-action routing.
• Connection switching is driven by a Lookup table or incoming request payload — adding a new tenant requires only a new connection and a Lookup row, with zero redeployment.
• Dynamic Connections support cross-policy switching — a connection using API Key auth at design-time can be overridden at runtime by one using OAuth.
• Currently available for REST and FTP adapters. For SOAP adapters and external credential management, see Parts 2 and 3.
Multi-Tenant Integrations in Oracle Integration Gen 3
Building integrations that work across multiple tenants, environments, or client systems is a common enterprise requirement. The logic stays the same, but connection details — credentials, endpoints, security policies — differ per target.
Just built an Enterprise-Grade Oracle Integration: Fusion ERP → APEX using OIC by Rashed Aldada
After weeks of design, testing, and refinement — here's the full architecture breakdown.
What does this integration do?
It extracts BI Report data from Oracle Fusion ERP via SOAP API, processes and validates it inside Oracle Integration Cloud, then loads it into Oracle APEX using RESTful APIs — with email notifications for every single outcome.
The flow in 6 phases:
- Extract → Invoke BI Report via SOAP runReport
- Process → Base64 Decode + Stage File Write/Read
- Validate & Decide → Switch on LOAD_TYPE parameter
- Load → Insert into APEX via RESTful API
- Notify → Email notification for every outcome
Oracle Integration much more than an integration engine by Gaurav Khaitan
Most Oracle Integration Cloud practitioners think of OIC as an integration engine. A pipeline between systems. That framing made sense in 2020. In 2026, it misses what OIC has actually become.
With the shift from Packages to Projects and the introduction of MCP server capability, OIC is now a governed AI tool catalog. Every integration you've built — every REST call to Fusion HCM, every FBDI automation, every third-party API — can be made discoverable and callable by any AI agent, in minutes, with governance and audit trails intact.
The architecture in plain terms
An OIC Project is the container. Inside it, any active integration can be registered as an Agentic AI Tool with three additions: a name, a plain-English description the LLM reads to decide whether to invoke it, and a definition of which parameters to expose.
Enable MCP Server on the Project, and it gets a unique URL. Any MCP-compatible agent — Oracle AI Agent Studio, OCI GenAI Agents, Claude, GPT-4 — can point to that URL, discover available tools, and invoke integrations. OAuth 2.0 handles auth. OIC handles orchestration, validation, error handling, and the full audit trail.
The governance principle that matters
AI agents don't get direct access to your Fusion applications or internal APIs. They call OIC tools. OIC calls the systems. Every invocation is logged. Every permission boundary you built into your existing integrations is respected.
How We Built an AI Agent on Top of Enterprise Systems by Harris Qureshi
The AI was the easy part. The integration layer is what made it enterprise-grade.
In Part 1 (The Enterprise AI Moment Nobody Is Talking About), I argued that the future of enterprise AI isn’t about replacing your systems of record. It’s about building an intelligence layer on top of them — one that lets every person in your organization access the data they need, in plain language, without navigating a maze of screens.
In this article, I want to get specific. I’ll walk through the architecture that makes this possible, explain the role of each layer, and share what we learned from a real implementation that brought this pattern to life.
The Implementation That Stopped Me Mid-Scroll
In a recent implementation, a global enterprise faced a problem that will sound familiar to anyone who’s worked inside a large organization.
|
