Invoking Oracle Agents from External Agentic Platforms
Part 3 of 3: From AI Agents to a Digital Workforce
This is Part 3 of a three-part series on MCP and A2A in Oracle AI Agent Studio.
Part 1 — Understanding the Digital Workforce
Part 2 — Configuring A2A in Oracle AI Agent Studio
Part 3 — Invoking Oracle Agents from External Agentic Platforms (this article)
In Part 2, I walked through what it takes to configure A2A inside Oracle AI Agent Studio — the Agent Card, the four-step flow, authentication, and what Release 26C added to make the platform genuinely production-ready.
That was the inside view: Oracle as the host, setting the stage for agents to be discovered and invoked.
Part 3 is the outside view. What happens when the orchestrator isn't Oracle?
This is the scenario that matters most for large enterprise transformations: you have an IBM Consulting Advantage-powered orchestrator routing lead to cash workflows and AWS Bedrock AgentCore hosting bespoke finance agents — all of which need to reach into Oracle Fusion and invoke agents that live there. A2A is what makes that possible without building custom integrations for each connection.
Let's walk through how each platform approaches it.
The Shared Foundation
Before going platform-specific, it's worth being precise about the roles in play.
In a cross-platform A2A architecture, Oracle Fusion AI Agents are A2A servers — they publish Agent Cards, expose invocation endpoints, and manage task lifecycle. The external orchestration platform is the A2A client — it discovers agents, reads their cards, sends messages, and polls for results.
The A2A protocol (now governed by the Linux Foundation following Google's transfer in June 2025) defines the contract between them. As of Release 26C, Oracle Fusion Cloud Applications formally confirmed cross-platform A2A collaboration as generally available — published agents can be discovered and called by agents on any A2A-compliant platform using a standard request and response model with shared task lifecycle management.
That's the foundation everything below is built on.
Platform 1: IBM Consulting Advantage (ICA 2.0)
Of the platforms covered in this article, IBM Consulting Advantage is the one of with the deepest and most architecturally complete integration with Oracle Fusion — and the one most relevant to IBM Consulting-led enterprise transformation programs.
IBM Consulting Advantage (ICA 2.0) is IBM Consulting's proprietary AI powered delivery platform that embeds specialized digital workers for purpose-built agent orchestration and LLM inference across enterprise workflows. It pairs human experts with AI to accelerate business and IT operations to bring production-ready agentic solutions to clients faster and with the governance controls that enterprise programs require.
The Architecture
ICA 2.0 uses a multi-agent supervisor pattern built on the LangGraph ReAct framework, which handles multi-step reasoning and tool calling within the orchestration layer. The key components are:
The Orchestrator Agent acts as the intelligent router. It understands user intent from natural language, determines which specialist sub-agent is best positioned to handle the request, and delegates accordingly — without the user ever needing to know which system or agent is handling their task.
Specialist Sub-Agents each own one business capability in isolation. In a Lead-to-Cash context, that means a Lead Sub-Agent, an Opportunity Sub-Agent, an Order Creation Sub-Agent, and an Order Details Sub-Agent — each with a clean, isolated context window. This isolation is what prevents cross-capability hallucination and ensures responses are accurate and focused.
Oracle Integration Cloud (OIC) serves as the middleware layer between ICA 2.0 Agentic App Studio and Oracle Fusion applications. OIC exposes Oracle Fusion APIs as MCP tools that agents can discover and invoke. The ContextForge MCP Gateway within ICA handles authentication, request transformation, and response formatting — meaning the agents interact with Oracle Fusion through a standardized, governed API surface rather than raw REST calls.
The technology stack is clean and deliberate:
Lead-to-Cash in Practice
Beyond the conceptual architecture, this solution is built and delivered as well.
The Lead-to-Cash journey begins when a business user opens a conversational interface — no screens, no navigation, no field mapping. The user states the intent and the Orchestrator Agent handles the rest.
Step 1 — Lead Creation. The user shares the lead details conversationally and the Orchestrator routes to the Lead Sub-Agent, which collects Lead Name and Description in a single structured prompt, confirms with the user, then invokes the Sales Cloud Lead API via OIC. The Lead ID is returned and stored in session memory — it will be available for every subsequent step without re-entry.
Step 2 — Lead to Opportunity Conversion. The user says: "Convert this lead to an opportunity." The Opportunity Sub-Agent retrieves the Lead ID from session memory — no re-entry required — presents a confirmation, and invokes the Sales Cloud Oppty conversion API. The Opportunity ID is stored in session for order creation.
Step 3 — Quotation and Sales Order. The agent guides the user through a three-part sequence that would otherwise require navigation across three separate Oracle applications: a Quotation is created in Oracle CPQ; a Sales Order is submitted to Oracle Fusion SCM Order Management in a single API call; and the CPQ Quotation is automatically updated with the returned Order Number, establishing a traceable link between the Quotation and the Sales Order. Full Lead-to-Order traceability across Oracle CPQ and Oracle Fusion SCM — in one conversation. Note that the applications in themselves can be swapped out for others based on the usage in the enterprise landscape such as Zuora for quote-to-cash and the changes are minimal.
Get Dhinesh Rajagopalan’s stories in your inbox
Join Medium for free to get updates from this writer.
Step 4 — Order Status Retrieval. At any point: "Get order details for order 288." The Order Details Sub-Agent retrieves complete header and line details from Oracle Fusion SCM — status, contract dates, subscription profile — without the user logging into a single Oracle application.
Steps 5 through 8 — fulfillment execution, subscription creation, invoice generation, and order closure — are orchestrated natively within Oracle Fusion applications following standard Oracle SCM and Financials workflows. The agent hands off gracefully; the platform carries forward.
What Makes This Different
The most important architectural decision in the ICA 2.0 Lead-to-Cash solution is the separation of concerns between orchestration and integration. The agents handle reasoning, routing, and user interaction. Oracle Integration Cloud handles API security, transformation, and reliability. Neither layer bleeds into the other's responsibility.
Session memory preserves transaction identifiers — Lead ID, Opportunity ID, CPQ Transaction ID, Order Number — across conversation turns, enabling seamless chained operations within a single interaction. Users never experience the context loss that normally comes with switching between enterprise applications.
For implementation programs, the MCP-based integration pattern also means extensibility is structurally built in: new Oracle Fusion capabilities can be added as additional sub-agents without disrupting what's already in production. The architecture is additive by design.
Platform 2: AWS Bedrock AgentCore
AWS Bedrock AgentCore added A2A support at General Availability in October 2025, and it has since extended across the platform. For Oracle Fusion integrations specifically, two AgentCore services are most relevant.
AgentCore Runtime is the deployment environment for A2A servers. When you deploy an agent into AgentCore Runtime with A2A mode enabled, it runs as a stateless, streamable HTTP server on port 9000, with Agent Cards exposed at /.well-known/agent-card.json. AgentCore adds enterprise authentication (SigV4 and OAuth 2.0) and scalability on top, while preserving standard A2A protocol behaviour — JSON-RPC payloads pass through without modification.
The invocation pattern from an AgentCore-hosted agent into an Oracle Fusion A2A server follows the same four-step model from Part 2: discover via the Agent Catalog, retrieve the Agent Card, send a message via InvokeAgentRuntime, poll for results. The AgentCore runtime handles session isolation — each agent interaction runs in its own isolated environment, which matters for multi-tenant Fusion deployments where data boundary separation is non-negotiable.
AgentCore Gateway is equally important for this architecture. It now supports HTTP passthrough targets — routing traffic to any HTTP endpoint, including A2A agents and external APIs, without protocol translation. For Oracle Fusion A2A endpoints, this means you can front the Fusion agent endpoints through AgentCore Gateway, gaining unified authentication, policy enforcement, and observability across all agent-to-agent calls.
The monitoring story is worth noting for enterprise programs. AgentCore now publishes an ActiveSessionCount metric directly to CloudWatch under AWS/Bedrock-AgentCore, updated once per minute per service type. For a production Lead-to-Cash implementation where AWS-hosted agents are invoking Oracle Fusion agents, this gives real-time visibility into concurrent session load — and a clean basis for capacity alarms before scale events.
Bringing It Back to Lead-to-Cash
Three platforms. Three integration patterns. One business scenario.
Here is what the completed Digital Workforce looks like for Lead-to-Cash, with the full cross-platform picture in view.
IBM Consulting Advantage (ICA 2.0) handles the agent-orchestrated stages — Lead Creation, Opportunity Conversion, CPQ Quotation, Sales Order submission, and Order Status — through a supervisor pattern that routes naturally to the right specialist sub-agent via OIC's MCP-based middleware. Session memory preserves every transaction ID across the conversation. Users interact with a single chat interface; the Orchestrator handles everything behind it.
AWS Bedrock AgentCore hosts any bespoke finance agents that sit outside Oracle Fusion's native agent library — revenue analytics, multi-source consolidation, exception handling — with the Gateway providing a governed, observable endpoint into Oracle Fusion's A2A surface.
Oracle's own fulfillment, subscription, invoicing, and closure workflows (Steps 5–8) run natively within Oracle Fusion, triggered by the agent layer above and completing the lifecycle without additional agent intervention.
Each agent stays in its lane. Each hand-off is standardized. The orchestration layer is the intelligence; A2A is the language.
The Governance Question
None of this matters at enterprise scale without governance.
Cross-platform agent architectures introduce new accountability questions: when an ICA 2.0 orchestrator delegates to an Oracle Fusion agent that triggers a financial commitment, who is responsible for the outcome? How do you audit a decision that crossed three platforms and four agents?
A few principles that apply here:
Invoke as the end user, not the service. Every A2A call into Oracle Fusion should carry a token representing the actual business user — not the orchestration platform's service identity. This ensures Fusion's role-based data security applies correctly and that every action is attributable in the audit log.
Policy Models at the Fusion boundary. Oracle AI Agent Studio's deterministic Policy Node is the right place to enforce business rules before any downstream commitment — approval thresholds, credit limits, eligibility criteria. Keep probabilistic reasoning in the orchestration layer; keep deterministic rules at the Fusion boundary.
Trace the full chain. A shared correlation ID passed through each A2A invocation — from the ICA 2.0 orchestrator through OIC into Oracle Fusion and back — is what ties together a single business transaction across three platforms. Oracle AI Agent Studio's monitoring and evaluation capabilities, OIC's audit trail, and AgentCore's CloudWatch metrics each give you a view into their own layer. Stitching them together requires that correlation ID to be set up from day one. Retrofitting it is painful.
Closing the Series
Three articles. One consistent thread.
Part 1 made the case: isolated AI Agents are not a Digital Workforce. A Digital Workforce is a coordinated system of specialized agents that can discover each other, delegate work, and complete business processes end-to-end.
Part 2 showed what it takes to configure an Oracle AI Agent Studio agent to participate in that system — the Agent Card, the A2A flow, the 26C platform capabilities that make it production-ready.
Part 3 closed the loop: how IBM Consulting Advantage and AWS Bedrock AgentCore reach into Oracle Fusion over A2A to invoke those agents as part of cross-platform business workflows — with a delivered Lead-to-Cash implementation showing exactly what this looks like in practice.
The protocol is open. The platforms are ready. The implementations are live.
The Digital Workforce is not a roadmap item anymore. It's a delivery commitment.
