At Oracle AI World, which opened Monday at The Venetian Resort in Las Vegas, Oracle unveiled two platform additions that together constitute its architectural answer to the central problem blocking enterprise AI adoption at scale: AI agents that query the right database but reason from the wrong definition of what the data means.
The company announced the Business Simulation Engine — integrating Oracle Essbase into its Autonomous AI Lakehouse — and the Business Semantic Layer, both due within the next 12 months. A third update, expanded SQL support for Apache Iceberg tables, rounds out a set of moves aimed at making enterprise AI agents more reliable and less prone to producing results that send data teams scrambling to figure out which version of “revenue” the agent used.
Oracle announced the new Lakehouse capabilities at the conference’s opening day, adding features aimed at data governance, business context for AI agents, and expanded support for Apache Iceberg data formats. Oracle AI World Las Vegas 2026 runs through October 29 at The Venetian Resort.
Every Enterprise Has Its Own Vocabulary — and AI Agents Don’t Speak It
Walk into the finance team and ask what “revenue” means. Walk into sales. Walk into accounting. You will get three different answers — net revenue, gross bookings, and recognized revenue under GAAP — all simultaneously correct, all legitimately in use, and often stored in different systems with different column names. Today’s AI agents, however sophisticated the underlying models, can easily query the wrong table, apply the wrong formula, or conflate those definitions entirely.
Oracle’s Business Semantic Layer is designed to solve that directly. Built into the Autonomous AI Lakehouse, the layer gives AI agents and analytics applications a consistent, shared understanding of enterprise metrics, hierarchies, and KPIs, grounding them in a company’s own data definitions rather than in general knowledge.
The layer is built from three input sources: catalog annotations already attached to data assets in Oracle’s AI Data Catalog; SQL annotations imported from Oracle AI Database, which store column-level and table-level business descriptions alongside the schema itself; and AI-suggested analytic views, where Oracle’s own AI proposes semantic models based on observed query patterns. Those inputs are combined into reusable models that encode dimensions, measures, hierarchies, calculations, and KPIs — defining, for instance, that “churn rate” in this company means active users who did not log in for 30 consecutive days, divided by total active users at the start of that period.
Once defined, those models are available to Oracle’s Select AI natural-language SQL interface and to other Oracle analytics and data retrieval tools, so that any AI agent querying data through Oracle’s ecosystem references the same governed definition — not its own inference about what the metric should mean.
“The ability to ground AI agents in business context will help data professionals and developers build more reliable AI-driven analytics and applications by using approved business metrics and definitions, reducing the time spent investigating and reconciling inconsistent results,” said Amit Kumar Jena, AI development head at IT consulting firm Kanerika.
Jena’s team ran a comparable semantic implementation — not on Oracle, but on Microsoft Fabric — for a global pharmaceutical company, standardizing more than 85 KPIs and modeling more than 40 data entities before AI agents went live. The result: roughly a 70% reduction in investigation and reconciliation time after agents were deployed. The figure comes from a competing platform implementation, but it establishes the order-of-magnitude payoff when the grounding problem is solved before deployment rather than debugged after.
What Is Oracle Doing, Technically, That Competitors Are Not?
The semantic layer concept itself is not new to the market. Microsoft has embedded semantic modeling into Fabric; Databricks and Snowflake have layered similar capabilities into their platforms. Third-party tools — dbt metrics layer, Cube.dev, AtScale — offer semantic layers that work across multiple platforms simultaneously. The contested question in enterprise AI architecture right now is not whether to have a semantic layer, but where it should live and who should own the source of truth for metric definitions.
Oracle’s bet is that the semantic layer belongs inside the managed database environment, alongside the data itself and the AI agents that query it — not as a separate tool layered on top. The practical implication: when an analyst or AI agent issues a natural-language query through Select AI, the semantic layer’s metric definitions are already present as persistent metadata, not injected at runtime from a retrieval step. There is no additional call to a separate service, no prompt-stuffing of business definitions, no version mismatch if the semantic layer tool was updated last week and the agent’s prompt was not.
That integration also enables a feature set that pure BI-oriented semantic layers do not typically support: write-back, the ability to push user-modified scenario data back into the planning model. This is what separates Oracle’s Business Simulation Engine from a more conventional semantic layer.
Business Simulation Engine: Three Decades of Financial Modeling, Now Inside the Lakehouse
The Business Simulation Engine, announced today with general availability expected within the next 12 months, integrates Oracle Essbase — Oracle’s multidimensional OLAP (Online Analytical Processing) engine that has been in commercial use since 1992 — directly into the Autonomous AI Lakehouse. Rather than treating the planning layer as a separate product that receives data from the analytics platform, Oracle is collapsing both into a single managed environment.
Essbase does not store data in rows and columns the way relational databases do. It stores data in multidimensional “cubes” — think of a spreadsheet that can be sliced along any combination of time, geography, product line, cost center, and scenario simultaneously — and aggregates across those dimensions at very high speed. That architecture is what makes financial consolidation and what-if modeling tractable at enterprise scale, and it is what distinguishes Essbase from general-purpose BI tools that query relational data.
The Business Simulation Engine brings that cube-based engine into the AI Lakehouse with the full set of capabilities that enterprise finance and planning teams have historically required dedicated EPM platforms to access: write-back (users can push scenario data back into the planning model, enabling true collaborative budgeting); dynamic hierarchy rollups (automatic aggregation across organizational hierarchies that change as a company restructures); advanced calculations (Oracle cites more than 100 pre-built mathematical functions); allocations (distributing totals down to sub-entities, such as spreading a divisional cost budget across individual departments); and scenario sandboxing (running multiple what-if scenarios in isolated environments without overwriting plan-of-record data).
Users can interact with the engine through Oracle’s Select AI natural-language interface, generate simulation reports in the platform, or use the traditional Excel-based Essbase interface that finance professionals have worked with for years.
“For CIOs, that could simplify data architecture and accelerate decisions,” said Pareekh Jain, principal analyst at Pareekh Consulting, “while developers could spend less time building integrations between analytics and planning tools and more time developing applications that turn business insights into actionable workflows.”
The competitive context here matters. Dedicated EPM platforms — Anaplan (taken private by Thoma Bravo in 2022), OneStream, SAP Analytics Cloud, and Workday Adaptive Planning — have deep footholds in enterprise finance departments, often as purpose-built systems of record for planning data, separate from the analytics platform entirely. Oracle’s Simulation Engine is a direct move to make that separation unnecessary for Oracle Lakehouse customers, consolidating historical analytics and forward-looking planning into the same managed environment. Enterprises that adopt it would have Oracle as both their analytics platform and their planning system of record — a structural change in how their data stack is organized, and one that makes the Oracle layer harder to replace incrementally.
Apache Iceberg: What Does “Write SQL Against Open Data” Actually Mean?
The third announcement is narrower in scope but consequential for data engineers managing multi-platform architectures. Oracle expanded its SQL support for Apache Iceberg open table format, which has become the de facto standard for large-scale enterprise analytics data.
The update lets Oracle customers create, populate, update, and delete Iceberg tables using standard SQL — the same syntax they use for any other Oracle table — rather than requiring separate tooling or Apache Spark jobs to manage Iceberg-specific operations. Oracle also improved performance when accessing Iceberg data through external catalogs: AWS Glue, Databricks Unity Catalog, Snowflake Polaris, and Apache Gravitino.
The practical payoff is what analysts call eliminating the “copy tax.” In multi-platform environments, organizations frequently maintain separate copies of the same data formatted for each query engine: one copy in Snowflake’s native format, another in a Delta Lake table for Databricks, perhaps a third materialized for Oracle. Storage and compute costs multiply accordingly. Iceberg’s architecture allows a single copy of data to be read and written by multiple query engines simultaneously — Spark, Snowflake, Databricks, Oracle, Trino — using a shared metadata standard.
“For data engineers specifically, the change means being able to work with a single copy of data using SQL while retaining the flexibility to use Oracle alongside platforms such as Apache Spark, Snowflake, or Databricks on the same tables,” said Manoj Chandra Jha, principal analyst at Nord-IQ Research. “That reduced data duplication could lower storage and processing costs for CIOs while giving greater flexibility to work across different data platforms,” he told InfoWorld’s Anirban Ghoshal.
What Enterprise Architects Should Weigh Before Committing
The three announcements carry implementation and competitive challenges that analysts were direct about addressing.
The Business Semantic Layer’s value is proportional to the quality of the work put into it upfront. Enterprises must define and maintain their business metrics, relationships, and rules before AI agents benefit from them — and keep those definitions current as the business changes. If the models are incomplete or outdated, AI-generated insights will still be inconsistent or misleading, Jena cautioned. Expanding the layer across an organization’s full range of business functions could require sustained effort from data teams to model and validate new metrics across dozens of KPIs. The 70% reconciliation time reduction achieved in the Kanerika pharma implementation required upfront investment in building a rigorous semantic model before agents went live — not after.
The Business Simulation Engine will face scrutiny in finance departments over integration with existing workflows. Anaplan, OneStream, and SAP Analytics Cloud have years of established user workflows, vendor support relationships, and organizational processes built around them. Moving to an Essbase-based planning engine inside Oracle’s Lakehouse is not a drop-in replacement; it is an architectural shift in where planning data lives and who manages it, Jain noted.
On openness: while Iceberg support does improve portability for the underlying data, enterprises that adopt Oracle’s semantic layer and catalog architecture for governing and interpreting that data introduce a new proprietary dependency. A data engineer can move Iceberg files from Oracle to Databricks without loss. But the business metric definitions encoded in Oracle’s semantic layer are Oracle-specific artifacts — moving them requires rebuilding that governance layer in another platform’s tooling. That dynamic is worth weighing against the convenience of an integrated stack, Jha noted.
Oracle has not specified pricing or general availability timelines for the Business Simulation Engine or the Business Semantic Layer beyond the 12-month window. Oracle has not specified general availability timing for the Iceberg SQL expansion.
One Year Into Oracle’s AI Lakehouse Platform Build
Today’s announcements follow a deliberate acceleration that began at Oracle AI World 2025, where Oracle launched the Autonomous AI Lakehouse alongside Oracle AI Database 26ai. That platform combined Oracle’s managed database infrastructure with Apache Iceberg, native AI vector search, Model Context Protocol server support, and a framework for building and deploying AI agents inside the database itself.
The Business Simulation Engine and Business Semantic Layer are the next architectural layer on that foundation: moving from infrastructure for running AI agents to infrastructure for ensuring those agents reason correctly over business-specific context. The sequence — build the lakehouse, add the agent framework, then add the grounding and planning layers — reflects a coherent infrastructure-first strategy. Whether Oracle’s integrated-platform approach proves more compelling than the modular alternatives offered by Databricks, Snowflake, and Microsoft Fabric will be a defining question for enterprise AI architecture decisions over the next 18 months.
Enterprise architects evaluating the platform have a decision timeline emerging from today’s announcements: both the Business Simulation Engine and Business Semantic Layer are targeted for availability within the next 12 months. The architectural trade-off — Oracle’s integrated stack with its deeper planning capabilities and governance layer, versus the flexibility of modular alternatives — is the question that will determine how aggressively organizations commit.
Frequently Asked Questions
What is Oracle’s Business Semantic Layer, and how is it different from what competitors offer?
Oracle’s Business Semantic Layer is a metadata layer built into the Autonomous AI Lakehouse that standardizes how AI agents and analytics tools interpret enterprise metrics like revenue, churn rate, and gross margin. Rather than letting each agent infer what a metric means from column names and table structures, the semantic layer codifies those definitions once — drawing from catalog annotations, SQL annotations, and AI-suggested analytic views — and makes them available across Oracle’s Select AI interface and other tools automatically. Microsoft Fabric, Databricks, and Snowflake offer comparable semantic modeling capabilities, but as layers added to their platforms. Oracle’s version is integrated directly into the managed database environment and works in conjunction with the Essbase-backed planning capabilities of the Business Simulation Engine, creating a tighter coupling between planning and analytics than any competitor currently offers in a single product.
How does Oracle’s Business Simulation Engine differ from a business intelligence tool?
Standard BI tools — Tableau, Power BI, Looker — are designed for reading and visualizing data that already exists. They can show you what happened. The Business Simulation Engine, built on Oracle Essbase, adds write-back: users can push modified scenario data back into the planning model, enabling genuine what-if analysis where a user adjusts an assumption (say, a 10% price increase in one product line) and immediately sees the cascading effect on margin, headcount requirements, and cash flow. Combined with dynamic hierarchy rollups, allocation logic, and scenario sandboxing, this is the capability set that has historically required a dedicated enterprise performance management (EPM) platform — Anaplan, OneStream, SAP Analytics Cloud — separate from the analytics stack entirely. Oracle is building it into the lakehouse itself.
What does the Apache Iceberg SQL expansion actually change for a data engineer?
Before this update, managing Apache Iceberg tables in Oracle required working outside standard SQL — using Spark jobs or Iceberg-specific tooling — for create, update, and delete operations. The expanded SQL support means a data engineer who works SQL-first can manage Iceberg tables with the same syntax they use everywhere else in Oracle, without adopting separate tooling or Spark expertise. More practically, Iceberg’s open format already allows a single copy of data to be read by Snowflake, Databricks, and Oracle simultaneously. The performance improvements to external catalog access — for AWS Glue, Databricks Unity Catalog, Snowflake Polaris, and Apache Gravitino — reduce the latency overhead of that cross-platform access, making the “single copy, multiple engines” workflow faster in practice.
Will adopting Oracle’s semantic layer create vendor lock-in?
For the underlying data, no: Iceberg tables are a portable open format, and data stored in them can be accessed by other platforms. For the governance layer itself, yes. Business metric definitions, KPI models, hierarchy structures, and calculation logic that are encoded in Oracle’s semantic layer are Oracle-specific artifacts. Moving them to another platform’s semantic or governance tool — dbt metrics layer, Cube.dev, Microsoft Fabric’s semantic model — requires rebuilding that work in the target platform’s tooling. The practical lock-in is proportional to how deeply an organization builds out its semantic models within Oracle: a company that standardizes 200 KPIs across 10 business units inside Oracle’s semantic layer faces real switching costs if it ever decides to move to a different analytics platform. That trade-off — integration convenience now versus reduced flexibility later — is the central question for enterprise architects evaluating this stack.
ⓒ 2026 TECHTIMES.com All rights reserved. Do not reproduce without permission.
