Oracle Fusion Applications now include a growing portfolio of AI agents and Fusion Agentic Applications.Teams need to determine not only whether an existing capability can meet the need, but also when to extend it, when to compose multiple capabilities, and when a new capability is justified. The goal is to select the simplest path that delivers the required business outcome while preserving flexibility, control, and long-term maintainability.
This article provides a practical framework for making that choice.
Choosing your Oracle Fusion AI Path
Once the business problem is clear, there are three general paths to consider.
| Path | Best suited to |
|---|---|
| Reuse an existing capability | An Oracle-delivered or Marketplace capability already addresses most of the required business outcome |
| Extend existing capabilities | Existing capabilities provide a strong foundation, but additional functionality is required |
| Build a new capability | No suitable existing capability provides the required business outcome |
These paths are not mutually exclusive.
An organization may use an Oracle-delivered agent and add a tool. It may use a Marketplace capability together with an Oracle-delivered capability. An Agentic Application may combine several existing agents, workflows, and tools and add only the functionality specific to the business process.
The question is therefore not simply which path to choose. It is what can already be reused and what is still missing.
1. Start with the business outcome
Start with what the business wants to achieve, not with the agent you think you need.
For example:
Reduce the time service representatives spend reviewing incoming requests and determining the correct route.
This is more useful than:
Build a service triage agent.
Defining the outcome first allows different implementation options to be evaluated against the same requirement.
2. Review what already exists
Before building something new, review the capabilities already available for the relevant business process, user, and outcome.
Start with Oracle-delivered capabilities. Then review Marketplace capabilities that may address the same requirement.
Look at:
- What the capability does
- Which business process it supports
- Who uses it
- What information it uses
- What actions it can perform
- Where it fits in the workflow
- What would still need to be added
Do not evaluate an agent only by its name. Look at what it actually does. An agent with a similar name may solve a different problem. Conversely, a capability designed for a broader process may already include the function you need.
Oracle-delivered capabilities
Oracle provides AI agents and Fusion Agentic Applications designed for business processes across Fusion Applications.
A delivered capability can reduce the amount of custom design and implementation required. It can also reduce the amount of custom logic and ongoing maintenance that the organization needs to manage.
Using a delivered capability does not necessarily mean using it with zero configuration.
Customer-specific setup may still be required, such as:
- Organizational knowledge
- Instructions and configuration
- Access and security
- Data sources and tools
- Workflow or approval rules
- Additional business context
Before creating a new agent, determine whether an Oracle-delivered capability can provide the foundation.
Marketplace capabilities
The Oracle AI Agent Marketplace provides partner-developed AI capabilities that customers can evaluate and use as starting points.
A Marketplace capability may provide functionality that is not available in the Oracle-delivered options. It may also address a specific business or industry requirement.
Evaluate a Marketplace capability using the same questions used for an Oracle-delivered capability:
- What business outcome does it support?
- Who is it designed for?
- Where does it fit in the workflow?
- What data and context does it require?
- What tools and actions does it support?
- What would still need to be added?
- Does it meet security, access, governance, and approval requirements?
If the capability already covers most of the requirement, extending it may be more practical than starting again.
3. Measure functional fit
Once you have identified potential starting points, determine how closely each one matches the requirement.
A simple assessment can help:
| Functional fit | Suggested direction |
| High | Reuse the existing capability |
| Moderate | Reuse the capability and address the remaining gaps |
| Low | Evaluate other capabilities or build what is missing |
Do not base the decision only on the number of requirements covered.
A capability may cover most of the requirements and still be a poor fit if one important missing capability prevents it from delivering the required business outcome.
4. Identify and classify the gaps
Once a potential starting point has been identified, determine what is still missing. A sample gap analysis is shown below:
| Gap type | Example | Likely response |
|---|---|---|
| Configuration | Supported settings or preferences need to change | Configure |
| Knowledge | Organization policies or procedures are required | Add approved knowledge |
| Data | Additional Fusion or external data is required | Add or extend data access |
| Tool / API | Additional retrieval or business action is required | Add a tool or API |
| External capability | An external tool or service needs to be available to the agent | Connect through the supported integration or tool mechanism, including MCP where appropriate |
| Channel | Users need to access the capability through Microsoft Teams, Slack, or another supported client | Add the required channel integration |
| Workflow | Additional orchestration or business-process behavior is required | Extend or create the workflow |
| Human approval / review | A business action requires a person to review, approve, reject, or confirm before it proceeds | Add a human approval or review step |
| Agent | A specialized reasoning or task capability is required | Reuse or create an agent |
| Agentic Application Composition | The business outcome requires multiple agents, workflows, tools, data sources, or human steps to work together | Compose existing and new capabilities into an Agentic Application |
| Capability | Required functionality is not otherwise available | Build the missing capability |
This distinction is important.
Not every gap requires custom development. Some gaps can be addressed through configuration or customer-specific knowledge. Others require additional tools, integrations, workflow behavior, or new capabilities.
5. Decide what to reuse, extend, or build
Once the gaps are clear, decide how the complete solution should be assembled.
Start with what is already available. Depending on the requirement, this may include Oracle-delivered capabilities, Marketplace capabilities, existing agents, tools, workflows, or integrations.
Then add only what is needed to address the remaining gaps.
A solution does not have to be a single agent. An Agentic Application may bring together multiple agents, tools, workflows, data sources, external systems, and human approvals to support a broader business outcome.
For example, a process may use Fusion data and an Oracle-delivered agent, call an external service for additional information, send or receive information through email or a collaboration channel, and route a consequential action to a user for approval.
Each component should have a clear purpose. Adding more agents, tools, integrations, or channels also adds security, testing, monitoring, and maintenance requirements.
The objective is to reuse what already fits, add what is needed, and keep the overall solution as simple as possible while delivering the required business outcome.
6. Evaluate the complete solution
After the individual components have been identified, review the complete solution.
Consider:
- Functional and workflow fit
- Required Fusion and non-Fusion data and context
- Agents, tools, APIs, MCP servers, and other integrations
- Email, collaboration, or other interaction channels
- Security, access, and approval requirements
- Implementation and integration effort
- Testing and evaluation requirements
- Monitoring and support
- Impact of Fusion application updates
- Ownership and ongoing maintenance
- Time to measurable business value
The complete solution should be evaluated against the original business outcome, not just whether each individual component works. The goal is to deliver the required business outcome with the simplest solution that can be operated and evolved over time.
7. Make the decision explicit
Document what will be reused, what will be configured, what will be extended, and what needs to be built.
For example:
We will use the existing account capability as the foundation, add access to the required customer-specific data, and build only the additional functionality needed to address the remaining business requirement.
This gives the implementation team a clear boundary.
It also helps establish what needs to be configured, developed, tested, and owned before the capability moves into production.
Questions for an architecture review
The following questions can help during the review:
- Which Oracle-delivered capabilities were evaluated?
- Which Marketplace capabilities were evaluated?
- What parts of the required business outcome can be addressed by existing capabilities?
- What gaps remain?
- Which gaps can be addressed through configuration or customer-specific knowledge?
- Which gaps require additional data, tools, APIs, agents, or workflow behavior?
- What existing capabilities will be reused?
- What capabilities need to be extended or composed?
- What needs to be built?
- Which Fusion and non-Fusion data sources are required?
- What actions can the solution perform, and which require human approval?
- How will the solution be evaluated and monitored?
- Who owns the capability and its ongoing changes?
- How will Fusion application updates affect the solution?
- Can the solution be maintained as the business process and AI capabilities evolve?
The answers should make it clear why the selected approach is appropriate before development begins.
Sources and References
The following sources were consulted in the preparation of this blog post. For the most current information on Oracle Fusion AI Agents and agentic capabilities, always refer to the official Oracle documentation.
[1] Oracle Fusion AI Agents for Fusion Applications — Catalogue — Catalogue of seeded AI agents and agentic applications across Oracle Fusion Cloud ERP, HCM, SCM, Sales, Service, and Marketing. Always refer to this page for the current list of available agents.
[2] Oracle Fusion Cloud Applications — Overview — Oracle Fusion Cloud Applications product overview, including AI and agentic capabilities embedded across Finance, HR, Supply Chain, Sales, Service, and Marketing.
[3] Oracle Blogs: New Fusion Agentic Applications — Details and Demos — Oracle Fusion Insider blog post covering Fusion Agentic Applications, the shift from systems of record to systems of outcomes, and the role of specialised agents in coordinating business processes.
[4] Oracle Blogs: Agentic Application Builder — What It Is, How It Works — Oracle Fusion Insider blog post on the Oracle AI Agent Studio (Agentic Application Builder), describing how business users can compose agents from reusable components grounded in Fusion business objects, data, and role-based security.
[5] Oracle AI for Fusion Applications — How do I use AI Agent Studio? (26C) — Product documentation covering workflows, agentic applications, tools, MCP, human approval, testing, monitoring, and lifecycle capabilities.
[6] Build Agentic Applications Using App Builder — 26C Documentation for composing and publishing agentic applications.
Note: Oracle Fusion AI agent capabilities are subject to continuous development. Features, availability, and agent names may change. Always consult the official Oracle documentation and your Oracle account team for current capability information.