Agents within the Oracle domain are intended to create a “system of outcomes” on top of a system of record. At AI World 2026, the IT company discussed agentic actions that can be planned and orchestrated at a higher level than before. The result is a management layer that keeps the database central, with less room for external agents than elsewhere.
Oracle Fusion Claw, running on a variety of third-party LLMs, is the engine behind Oracle Fusion Agentic Applications. Within OCI, these applications must, above all, deliver defined business outcomes. Twenty-five pre-built Agentic Applications are now available within Oracle Fusion Cloud ERP, HCM, SCM, and CX. Examples include agentic apps for finding candidates, payroll management, scheduling deliveries, or measuring the quality of a company’s own customer service.
The templates are just a starting point; Oracle encourages others to build their own Agentic Applications for Fusion applications. Oracle states that every application comes equipped with observability, ROI metrics, and security controls out of the box.
Those who don’t want to figure out which agent or application to use can leave that to Oracle Fusion Companion. This layer translates a business objective into the appropriate transactions, workflows, approvals, agents, and Agentic Applications. Users access Companion via AI tools such as ChatGPT or through Oracle Fusion Agentic Home, the new AI-native launch environment within Fusion. Even when a request comes in via an external chatbot, Oracle states that execution and accountability remain within Fusion Applications.
Agents at work
The leap from idea to a working environment is a big one. Meaningfully translating a business process into a configuration sometimes requires more work. For this reason, Oracle has made the Fusion Setup and Configuration Registry (FSCR) available, a public Git repository that makes the setup and configuration of Fusion Cloud Applications machine-readable and executable by AI agents. AI assistants and coding agents from companies such as OpenAI can use this to translate business requirements, process documents, and existing configurations into implementation runbooks, execute the configuration directly in Fusion, and automatically test and validate the result. Experts review the final result before it goes into production. Partners such as Accenture Edge, Deloitte, and PwC can extend the registry with their own methodologies, accelerators, and industry-specific solutions.
One of the projects built on FSCR is the AI Success Navigator, formerly known as Oracle Cloud Success Navigator. It offers new agents for mapping IT environments, business processes, and potential risks, as well as application design, configurations, tests, integrations, and new innovations. According to early adopter Lexington Health, this approach reduced the workload by up to 80 percent for certain design and configuration tasks during implementation. More agents are on the way, according to Oracle.
The deeper layer for trust
So far, we’ve discussed Oracle’s iterative improvements, particularly those focused on Fusion applications. Where the company is taking a more ambitious approach at AI World is with its so-called Deep Trust AI Architecture. This area of development brings together the Oracle AI Database, the Autonomous AI Database, and the APEX AI Application Generator. The architecture is embedded in all these products and platforms, with controls for data usage, development, access management, and automatic updates.
It is a development alongside the existing Maximum Availability Architecture, which is designed to prevent downtime for Oracle applications and infrastructure. With Deep Trust, the emphasis is on eliminating arbitrary access and conventional paths that make agents a security risk. Whereas a typical employee can be trained on the proper use of sensitive infrastructure, an agent can potentially be misled or exploited in ways that would be much more difficult to achieve with human colleagues and are not scalable for attackers. Agents thus effectively constitute an “insider threat.” Oracle points out that access and business rules that exist solely in application code can be incorrectly implemented by AI-generated apps, whereas agents that operate directly on the database via an MCP server or natural language-to-SQL can completely bypass them.
That is why those rules must reside in the database itself. With Oracle Deep Data Security, organizations define access rules per end user in Oracle AI Database, which enforces them with every SQL request. The database verifies the user’s identity itself using a cryptographically signed token from the corporate directory. Deep Trust Data APIs also provide tightly controlled access to logical business objects such as purchase orders, rather than arbitrary SQL access. Oracle SQL Assertions enforce business rules within the database, ensuring, for example, that no expenses exceeding an employee’s spending limit can be approved, regardless of which application, user, or agent submits the request.
The APEX AI Application Generator is another example of a secure AI application. Coding agents do not write code themselves, but rather an application definition in APEXlang. The APEX runtime then executes this definition to prevent organizations from having to blindly trust large amounts of code.
Oracle autonomous AI lakehouse enhancements
Oracle Autonomous AI Lakehouse is also receiving updates that align with this trust-based approach. Oracle argues that simply granting AI access to business data is not enough. According to the company, agents must also understand the business context behind that data and operate within the organization’s rules and policies.
To that end, a Business Semantic Layer is being introduced, which enriches raw data with dimensions, metrics, hierarchies, and KPIs through annotations and AI-suggested analytic views. This should make NL2SQL, Select AI, and AI retrieval more accurate. A new AI Data Catalog links external catalogs, Oracle and non-Oracle databases, Iceberg tables, and object storage without duplicating data. Both features are expected to be released sometime within the next twelve months. A central management layer within the catalog will manage access at the object level. These controls apply to both users and agents. Additionally, customers will be able to create and modify Iceberg tables using SQL.
Conclusion: Trust in the foundation
Oracle leverages its position as the system of record for many organizations. The company embeds AI controls within existing platforms, data, and runtimes. The difference from the approach agents faced during the haphazard early days of AI adoption is that there is now the knowledge to contain these AI systems using proprietary APIs and restrictions that differ from conventional methods. New agents are subject to the same safeguards that existing systems already had in place.
What is not yet entirely clear is how organizations can verify, after the fact, what an agent has done. When Fusion Claw was introduced in September, Oracle still spoke of an “Outcome Receipt” per run, but in the announcements at AI World, the focus remains on observability and approval. Additionally, several Lakehouse features will not be available for another year.