Oracle brings governed AI agents to Fusion Applications

• Oracle lets enterprises run AI agents within Fusion controls.
• Oracle says AI agents should be judged by business results, not task volume.

Oracle has introduced a builder experience that allows customers and partners to create and run agentic applications within Oracle Fusion Cloud Applications.

Announced last week, the update brings natural-language, no-code, low-code, and pro-code development into a shared Fusion framework. The applications are deployed within the Fusion runtime rather than through a separate orchestration layer.

Kaushal Kurapati, group vice president of applications development at Oracle, said the applications are designed around defined business objectives, such as shortening the financial close, reducing sourcing delays, improving collections, and resolving service cases sooner.

An agentic application can monitor business signals, identify priorities, coordinate agents and workflows, and carry out authorised actions. Employees remain involved when a process requires judgment, an exception decision, or formal approval.

Kurapati said suitable processes should have a clear objective, measurable results, trusted data, and defined operating boundaries. Enterprises also need to establish decision rights, approval thresholds, exception paths, and audit requirements before deploying agents.

He identified financial-close readiness, sourcing, service resolution, collections, and supply-chain execution as examples of processes suited to this model.

“AI agents are most valuable where contextual reasoning is needed, while deterministic controls and human oversight can govern consequential decisions,” Kurapati said.

Embedding governance into workflows

Oracle said AI applications built outside enterprise systems require organisations to manage identity, data access, approvals, audit trails, observability, governance, and lifecycle controls separately.

Oracle’s approach places agents inside Oracle Fusion Cloud Applications. Kurapati said the agents inherit role-based authorisation, business-object permissions, approval processes, and enterprise security controls from the application.

The system can determine which policies apply, confirm whether a user or agent has authority to perform an action, route the task for approval, validate the completed transaction, and retain an execution record.

Actions performed through the application can also be traced during an audit or investigation. The record can show who initiated the process, which agent completed each step, what data and tools were used, which policies applied, and what business transaction resulted.

“The important shift is to governed autonomy: hands-off execution where risk is low, with deterministic controls and human oversight where business impact is high,” Kurapati said.

External agents and models can participate in a Fusion workflow while remaining hosted in their original environments. Fusion determines which enterprise data can be shared, which tools can be used, which permissions apply, and whether approval is required.

Kurapati said this structure does not provide full visibility into an external provider’s internal processing. Instead, it governs activity conducted when an external system accesses Fusion data or executes an action through a Fusion workflow.

Sanchit Vir Gogia, chief analyst at Greyhound Research, said competition in the enterprise agent market is increasingly centred on the environment in which agents operate.

“The contest is no longer over who builds the smartest one, but over who owns the governed runtime in which agents are permitted to act,” Gogia said.

Building and testing agentic applications

Kurapati said enterprises need a shared development and operating model to prevent duplicated agents, inconsistent security controls, and separate monitoring systems.

That model should include a catalogue of published agents, reusable components, defined ownership, and lifecycle controls. Teams should also be able to identify existing agents and workflows before creating new ones.

Oracle provides a shared application model for no-code, low-code, and pro-code development within Fusion. Teams can reuse templates, connectors, policies, and workflows before publishing applications through a governed process.

The recent update also introduced an AI Studio Skill for development through Visual Studio Code, command-line tools, Git-based workflows, and supported AI coding assistants. Oracle said a public GitHub repository would provide templates, starter projects, sample applications, reusable assets, and reference architectures.

Business users and functional specialists can begin with natural-language or no-code tools. Developers can inspect generated components, add integrations, test changes, and review execution paths using established development tools.

“The key is that these are not separate platforms producing incompatible outputs,” Kurapati said. “They are different interfaces into the same application framework.”

The completed application is deployed within the Fusion runtime with its agents, workflows, policies, approvals, tests, and deployment settings.

Testing each model or agent separately does not account for failures arising from interactions among agents, tools, workflows, and approval rules. Kurapati said enterprises need to test the complete application as a composed system.

Oracle’s ATLAS testing capabilities use source-controlled regression tests and replay data to examine workflow behaviour and output quality. Tests can cover required execution paths, skipped branches, policy decisions, fallback behaviour, and responses based on retrieved enterprise data.

The system can also generate scenario data for rare conditions and exception paths that are difficult to reproduce. Teams can compare models, prompts, and orchestration methods using measures such as output quality, latency, token usage, and cost.

Production monitoring remains necessary because pre-deployment tests cannot cover every possible interaction. Oracle’s runtime records prompts, model versions, retrieved context, tool calls, policy outcomes, approvals, and resulting actions.

Developers can replay previous runs using the original inputs, identify where an execution path changed, and add the scenario to future regression tests.

“Reliability therefore comes from continuous system-level testing, production observability, and closed-loop improvement—not from evaluating each agent in isolation,” Kurapati said.

Measuring business outcomes

Enterprises should assess agentic applications against the business process they were designed to improve rather than relying only on usage or task-automation rates.

Financial-close applications can be measured using close duration, manual journal work, rework, unresolved exceptions, and control failures. Sourcing applications can be evaluated through request-for-quotation cycle times, approval times, negotiated savings, supplier-risk resolution, and policy compliance.

Service applications can be measured using resolution times, service-level agreement breaches, escalation rates, and first-contact resolution. These measures should be tracked alongside action accuracy, policy compliance, approval and override rates, incomplete actions, latency, availability, and operating costs.

Kurapati said organisations should establish a pre-deployment baseline or use a control group where possible. Results should also be linked to specific transactions and workflows so operating costs can be compared with process improvements.

“The real test is not, ‘Did the application automate more tasks?’” Kurapati said. “It is, ‘Did it improve the business-process outcome while maintaining the required level of control—and did the net value justify the cost?’”

Want to learn more about AI and big data from industry leaders? Check out AI & Big Data Expo taking place in Amsterdam, California, and London. The comprehensive event is part of TechEx and is co-located with other leading technology events, click here for more information.