 In Part 1 of this blog series, I looked at why AI agents change the analytics conversation. The important shift is not simply that AI can answer questions, but that agents can keep working towards a goal, call tools, retrieve context and potentially act on analytical findings. That changes the risk profile. A wrong dashboard might mislead someone. A wrong agentic action can create consequences. This second part looks at the architecture question: what needs to be in place before agentic analytics can be trusted in the enterprise? Why Semantic Grounding Matters This is where semantic models and business definitions become central. If an analytics agent is asked why revenue has fallen, what definition of revenue should it use? Gross revenue, net revenue, recognised revenue or booked revenue? Which hierarchy should it apply? Which region mapping should it follow? Which filters are appropriate for the user asking the question? Without governed business meaning, an agent can produce an answer that sounds plausible but is analytically wrong. That is why semantic models matter even more as analytics becomes agentic. They give agents a governed structure to reason over. They help ensure that the agent is not simply interpreting table and column names, but working with business concepts that have been defined, tested and approved. In Oracle terms, this is where Oracle Analytics Cloud’s semantic model remains highly relevant. It provides a way to define measures, hierarchies, calculations, joins, aliases, descriptions and access rules that can ground AI-driven analytical experiences in trusted business meaning. Why Governance Must Reach the Data Layer Agentic analytics also raises another important question: where should governance be enforced? It is not enough for governance to exist only in the front-end experience. If AI agents, analytics platforms, notebooks, APIs and downstream services can all access data through different routes, governance needs to be durable across those access paths. This is why data-layer governance matters. Oracle’s direction with Deep Data Security in Oracle AI Database 26ai is relevant here. The idea of declarative, identity-aware access control closer to the database points towards a model where policies can be centralised at the data layer rather than being recreated separately in every consuming service. For agentic analytics, that matters because agents may become another class of downstream consumer. They may request data, retrieve context and invoke services in ways that need to remain governed, auditable and aligned with enterprise policy. Why Oracle’s Architecture Matters This is where Oracle’s broader platform direction becomes interesting. Agentic analytics needs several layers to work safely and effectively:
Oracle is increasingly assembling many of these layers across Oracle Analytics, Oracle AI Data Platform, Autonomous AI Lakehouse and agent platform capabilities. Oracle Analytics provides the analytical interaction layer and semantic modelling foundation. Oracle AI Data Platform provides the broader environment for catalog, data engineering, notebooks, governed discovery, agent tooling and access to structured and unstructured data. Autonomous AI Lakehouse helps provide part of the governed data foundation. Agent Studio, Agent Hub and Agent Registry point towards a more explicit agent platform layer. Deep Data Security points towards governance being enforced closer to where the data is served. The value is not that any single product solves the whole problem. The value is that these layers begin to form a more coherent enterprise architecture for agentic analytics.  From Insight to Action Requires Accountability As analytics moves closer to action, accountability becomes central. If an agent recommends a price change, triggers a supplier review, escalates a customer issue, updates a forecast or starts a workflow, the organisation needs to understand what data was used, which business definitions were applied, what context was retrieved, which tools were invoked, what permissions were evaluated, who approved or delegated the action, and what audit trail was created. This is the difference between a clever demo and an enterprise-ready capability. Agentic analytics should not simply be measured by whether it can produce an answer. It should be measured by whether the answer, recommendation or action is trusted, explainable, governed and accountable. Conclusion The Hannah Fry video was a useful reminder that AI agents change the conversation because they can act. That is exciting, but it is also why agentic analytics needs more than intelligence. It needs architecture. If analytics agents are going to interpret intent, retrieve context, explain findings, recommend next steps and potentially execute actions, then they need to operate within clear boundaries. They need governed data, semantic grounding, policy enforcement, observability, auditability and accountability. For me, this is where Oracle’s platform direction becomes important. Oracle Analytics, Oracle AI Data Platform, Autonomous AI Lakehouse, agent platform capabilities and database-level governance all contribute to the foundations needed for agentic analytics to become enterprise-ready.  The question is not simply whether agents can act. The more important question is whether they can act within an architecture that makes those actions trusted, governed, explainable and accountable.
0 Comments
 I recently watched Hannah Fry’s YouTube video exploring what happens when AI agents are given the ability to act in the real world. The video followed an experiment with an AI agent that could operate a computer, send emails, browse websites and attempt to complete tasks on behalf of its users. What stood out to me was not simply that the agent could answer questions. It was that it could keep acting towards a goal. It could search, decide what to do next, click, type, email, spend money and continue the loop until it believed the task was complete. That is the point where the conversation about AI changes. The risk does not begin when AI can answer questions. The risk begins when AI can act. That has direct relevance to the way I have been thinking about agentic analytics. If analytics agents are going to move beyond explaining dashboards and start recommending actions, triggering workflows, calling tools or coordinating with other agents, then the architecture underneath them becomes much more important. It also connects strongly with a blog series by my friend Chris Buckel, Databases in the Age of AI, where he explores how AI agents change the way systems of record are accessed, queried and used. Chris makes an important point: AI does not just place more demand on data platforms; it changes who or what is consuming the data. In his framing, inference is becoming a first-class database workload, and databases are becoming part of the reasoning path itself. That is exactly why this matters for analytics. If analytics agents are going to move beyond explaining dashboards and start recommending actions, triggering workflows, calling tools or coordinating with other agents, then the architecture underneath them becomes much more important. Agentic analytics is not just about better answers. It is about what happens when analytical systems can begin to act on those answers.  From Chatbots to Agents A chatbot responds to a prompt. An agent works towards a goal. That distinction matters. In the video, the agent followed a loop: look, ask, act, then repeat. It reviewed what was on screen, asked a model what to do next, acted through the keyboard and mouse, and continued until the task progressed. In simple situations, that can look useful. An agent can make a complaint, search for the best price, draft messages or attempt to complete administrative work that a human might not have the time or patience to do. But the same persistence that makes agents useful also makes them risky. Once an agent can keep acting, it can also keep acting incorrectly, expensively, inappropriately or beyond the user’s original intention. That is why the shift from chatbots to agents is not just a technical enhancement. It changes the risk profile. Why This Matters for Analytics Traditional analytics has usually stopped at insight. A report shows what happened. A dashboard helps users explore why it happened. A self-service tool allows a user to ask new questions. Augmented analytics may surface patterns, explain anomalies or suggest visualisations. Agentic analytics goes further. It begins to move from insight towards recommendation, orchestration and action. An analytics agent might not just explain why revenue fell in a region. It might retrieve supporting context, compare past trends, identify contributing factors, recommend follow-up actions and trigger a workflow for someone to investigate. That is powerful, but it also changes the governance challenge. A wrong chart can mislead a user. A wrong agentic action can trigger consequences. The New Risk Profile of Agentic Analytics Once analytics agents can act, several risks become more important:
This is why agentic analytics cannot be treated simply as a new interface for existing dashboards. If an agent is going to interpret business intent, query data, retrieve documents, call tools and recommend or execute actions, then the enterprise needs to understand how that behaviour is governed. The Lethal Trifecta in Enterprise Terms One of the strongest ideas in the video was the reference to what is sometimes described as the Lethal Trifecta:
In a consumer setting, that might mean an agent with access to personal accounts, passwords, email and websites. In an enterprise analytics setting, the equivalent could be even more serious. An agent may have access to sensitive business data, internal documents, customer information, operational workflows, SaaS applications and external services. If that agent can also receive untrusted instructions through prompts, documents, web pages or user inputs, then governance becomes essential. The issue is not that agents are inherently bad. The issue is that powerful agents need boundaries.  This is why agentic analytics cannot simply be treated as the next user interface for dashboards. Once analytics systems can interpret intent, retrieve context, call tools and recommend or trigger actions, the architecture underneath them becomes just as important as the intelligence of the model itself.
In the second part of this series, I will look at what that architecture needs to include: governed semantic meaning, data-layer security, trusted retrieval, observability, auditability and why Oracle’s broader platform direction across Oracle Analytics, Oracle AI Data Platform, Autonomous AI Lakehouse and database-level governance is relevant to this shift.  Introduction In my previous post, I looked at how agentic analytics is the natural progression of augmented analytics. If augmented analytics introduced AI assistance into the analytics experience, agentic analytics extends that further through business context, governed definitions, runtime knowledge retrieval, chained tasks, conversational explanation and action-oriented outcomes. The next question, then, is what this looks like in practice. For me, Oracle is increasingly assembling many of the building blocks needed to enable agentic analytics. Not through a single feature, but through the combination of Oracle Analytics, Oracle AI Data Platform, Autonomous AI Lakehouse, agent platform capabilities and database-level governance to name a few. That does not mean the journey is finished. But it does suggest that Oracle is putting in place the architecture needed to move analytics beyond static reporting and even AI-assisted insight discovery into something more contextual, guided and potentially action-oriented. Agentic Analytics Needs More Than a Chatbot If agentic analytics is to be more than a chatbot placed in front of dashboards, it needs a wider set of capabilities underneath. It needs:
This is why agentic analytics is not simply a user interface story. It is an architectural one.  Oracle Analytics Provides the Interaction Layer Oracle Analytics already provides several of the capabilities that form part of this picture. It brings together governed metrics, semantic models, dashboards, self-service exploration and AI-driven user experiences. Semantic models remain especially important here because they provide the governed definitions and business context that make analytics trustworthy. The Oracle Analytics Cloud semantic modeller is central to this. It allows organisations to define logical business models, measures, hierarchies, joins, calculations, aliases, descriptions and access rules in a way that business users can consume consistently. That matters because AI features in OAC need more than access to tables and columns. They need business meaning. As Oracle Analytics becomes more conversational and assistant-driven, those foundations become even more important. If analytics is going to interpret business intent and explain results in a meaningful way, it needs a stable semantic layer underneath. A well-designed semantic model can therefore improve the quality of AI-driven experiences by giving the platform clearer definitions, better context and a more reliable analytical structure to reason over. In that sense, Oracle Analytics provides much of the user-facing interaction layer for agentic analytics. Oracle AI Data Platform Provides the Broader Platform Layer Oracle AI Data Platform extends that picture into the wider enterprise data and AI landscape. It brings together structured and unstructured data, catalog capabilities, governed discovery, AI tooling, notebooks and an emerging agent platform story. That matters because agentic analytics needs access not only to trusted analytical data, but also to the documents, knowledge sources and broader platform services that can help ground and enrich results. Oracle AI Data Platform is also positioned as a platform that unifies structured, unstructured, batch and real-time data across the enterprise. That broader platform view is important because agentic analytics depends on more than just curated dashboards. It depends on a governed data estate that AI-driven analytics can draw from more intelligently. The March 2026 AIDP roadmap also makes the agentic AI direction much more explicit. In the current roadmap view, Oracle calls out agents supported by OCI Generative AI models, tool types such as RAG, SQL and prompt, low-code agent flow creation, deployment to AI compute, a testing playground, observability and guardrails. These already point towards a more complete agent development and runtime experience within AIDP. The upcoming roadmap extends this further with multi-agent support, MCP client, server and tools, custom code tools, high-code agent development, MLOps and A2A. For agentic analytics, those capabilities are important because they begin to cover the practical requirements of:
It is also worth noting that these are roadmap items, so timing and delivery remain subject to Oracle’s usual forward-looking safe harbour caveats. Autonomous AI Lakehouse Helps Provide the Data Foundation Within that broader story, Autonomous AI Lakehouse helps provide part of the underlying data foundation. It adds a governed data and storage layer that can support both analytics and AI workloads, helping make enterprise data more accessible in a way that fits with the wider Oracle AI Data Platform architecture. This matters because agentic analytics depends on more than interface-level intelligence. It also depends on having the right data foundation beneath it, one that can support trusted structured and unstructured data access at scale. Agent Platform Capabilities Begin to Matter The emergence of agentic analytics also depends on more explicit agent platform capabilities. This is where the Oracle AI Data Platform Partner Summit was especially interesting. Oracle discussed Agent Studio, Agent Hub and Agent Registry as part of a broader direction towards building, exposing, orchestrating and governing AI agents. That matters because agentic analytics is not just about generating a response. It increasingly involves chaining tasks together, retrieving the right context, invoking tools, coordinating actions and potentially handing work across systems or agents. The more analytics becomes agentic, the more these platform capabilities begin to matter. Governance Needs to Reach the Data Layer One of the most important requirements for agentic analytics is governance. If AI-driven analytics is going to interpret intent, retrieve knowledge, explain findings and support actions, then governance cannot be treated as an afterthought. It needs to remain enforceable all the way down to the data layer. This is where Oracle’s broader governance story becomes relevant, including the emerging role of Deep Data Security in Oracle AI Database 26ai. Deep Data Security is described by Oracle as a declarative, identity-aware access control system designed to simplify and modernise fine-grained authorisation directly in the database. That makes it particularly relevant to agentic AI because it points towards a model in which downstream services and AI-driven access paths can still be governed by centralised database-level policies. For me, that is an important part of the story. Agentic analytics will only be credible in the enterprise if governance remains durable, auditable and enforceable beyond the front-end experience. Bringing the Layers Together Taken together, Oracle’s approach begins to look like this:
Why This Matters
The value of this is not simply that Oracle has AI features across multiple products. The more important point is that these components can start to work together. Agentic analytics needs more than dashboards, and more than a natural language front end. It needs semantics, data foundations, retrieval, orchestration, tools and governance. Oracle’s current platform direction suggests that it is increasingly thinking about that fuller picture. Conclusion If agentic analytics is the next evolution of augmented analytics, then the enabling question becomes whether platforms can support that shift in a governed and enterprise-ready way. For me, Oracle is increasingly showing that it can. Not because one product alone solves the whole problem, but because Oracle Analytics, Oracle AI Data Platform, Autonomous AI Lakehouse, agent platform capabilities and database-level governance are beginning to form a more coherent foundation for analytics that is not just descriptive or exploratory, but more contextual, guided and action-oriented.  In the previous post, we traced how Fusion Data Intelligence (FDI) evolved from OBIA. In this second instalment of our FDI‑introductory series, you’ll explore the underlying technology and architecture that power FDI’s cloud-native analytics platform. 2. The FDI Architecture Ecosystem (The “Big Picture”) At its core, Fusion Data Intelligence (FDI) is a fully managed, cloud-native analytics platform running on Oracle Cloud Infrastructure (OCI). It stitches together your Fusion Cloud Applications, Oracle-managed data pipelines, Autonomous Data Warehouse (ADW), and Oracle Analytics Cloud (OAC) into a seamless, scalable end-to-end analytics solution - one that Oracle deploys, operates, and continuously evolves for you (there is some configuration that administrators need to carry out). First, Fusion Cloud SaaS applications - including ERP, HCM, SCM and CX pillars - serve as the transactional data sources. Oracle provides prebuilt ingestion pipelines tailored to each functional Pillar, handling everything from data extraction and change data capture (CDC) to transformation and consistent mapping into analytics-ready format . These pipelines write data directly into an OCI-hosted Autonomous Data Warehouse, which transform and load the Fusion data into a unified star-schema data model covering multiple functional domains. The schema is:
Once data arrives in the Autonomous Data Warehouse (ADW), Oracle Analytics Cloud takes over for semantic modelling and visualisation. A prebuilt semantic layer wraps the raw star schema into business-friendly subject-area views - covering finance, human resources, supply chain and customer experience - complete with standardised key metrics and dashboards . Through OAC, FDI delivers not just dashboards but intelligent, action-driven analytics, featuring natural-language querying, ML-based forecasting and anomaly detection to name just a few. 🔗 Summary Flow
This end-to-end ecosystem is fully managed by Oracle - covering provisioning, upgrades, performance tuning, and integration with Fusion App releases - offering a friction-free, scalable approach to enterprise analytics (there is some configuration that needs to be done by administrators).  3. Data Movement & Integration FDI’s data movement layer is built around Oracle-managed, prebuilt pipelines that automate ELT and Change Data Capture (CDC) for Fusion Applications (ERP, HCM, SCM, CX). These pipelines are configured and controlled through the intuitive FDI Console, making it easy for administrators to activate, modify or schedule updates with minimal effort. You don’t need to build complex ETL processes - Oracle handles the heavy lifting, while you focus on business relevance and reporting needs . By default, data pipelines are incremental with zero downtime, keeping analytics up-to-date without interrupting service. You also have the flexibility to perform on-demand full reloads, useful for data corrections or model updates - all managed with just a few clicks in the Console . Crucially, the architecture supports extensibility in two key ways:
All pipelines and augmentations are managed through the FDI Console. As an administrator, you can configure initial parameters - such as extract start dates, currency preferences, and schedule frequency - directly in the console interface. Any subsequent edits to pipelines, functional areas, or augmentations are seamless, with Oracle handling deployment and execution behind the scenes  ✅ Summary: Core Benefits of FDI Pipelines
4. Lakehouse & Warehousing Foundation At the heart of Fusion Data Intelligence lies a star-schema model deployed on Oracle’s Autonomous Data Warehouse (ADW) - a cloud-native, self-tuning database that underpins fast, enterprise-grade reporting and analytics. Here’s how it’s structured and why it matters: ⚙️ Prebuilt Star Schema in ADW When FDI is provisioned, Oracle automatically creates a prebuilt star schema in ADW. This schema includes fact tables and a network of conformed dimensions - shared across multiple functional areas - that serve as the glue for cross-pillar analytics. Common dimensions include:
These shared dimensions enable users to analyse, for example, how procurement spend (SCM) impacts cash flow (finance), or how HR-driven workforce changes correlate with sales performance - a cross-functional insight made possible by a common semantic backbone. 🏗️ Support for External Data & Custom Schemas FDI doesn’t just ingest Fusion source data - it enables easy integration of external datasets into the same ADW environment. Whether it’s non-Oracle systems, legacy data, purchased data feeds, or even weather information, FDI supports loading external tables into custom schemas that can extend the star schema and semantic model. This extensibility is key to bridging out-of-the-box analytics with bespoke business insights - enhancing customer segmentation, supplying additional cost drivers to per-product profitability, or blending external KPIs directly alongside Fusion metrics. 🔍 Benefits of the Lakehouse Foundation
Under the hood, FDI’s star-schema in ADW provides a robust, extensible greenfield analytics foundation. Built on conformed dimensions and a scalable data warehouse, it enables seamless mash-ups of Fusion data with external sources, supporting rich, multi-domain analytics that truly span the enterprise.  5. Semantic Layer & Pre‑Built Metrics FDI abstracts hundreds of physical tables into logical business subject areas - finance (GL profitability, AP ageing, AR revenue, Trial Balance), HCM (talent acquisition, workforce core), procurement (spend, POs), and CX (campaign ROI, opportunity pipeline) - all underpinned by conformed dimensions. It includes a KPI library with over 2,000 standard metrics, accessible via Oracle Analytics Cloud’s intuitive key-metric editor and drag‑and‑drop visualisations. In essence, this semantic layer creates a unified business vocabulary that simplifies reporting and ensures consistency across the enterprise . 🔐 Complimenting Fusion-Defined Security FDI leverages Fusion’s built-in role-based security model, so the semantic layer inherits data roles, duty roles, and row/object-level filters defined in Fusion Cloud Applications. Access control is enforced through the Oracle Identity and Access Management (IAM) Service and the FDI Console, ensuring that users only see data they’re authorised to view. This unified approach simplifies administration and compliance by avoiding double entry of security definitions . 🧩 Hiding Complexity Through Logical Abstraction Rather than exposing raw tables, FDI offers a logical semantic layer that shields users from underlying complexity. Here’s what it achieves:
✅ Summary: User Experience & Governance Wins
 6. Visualisation and Intelligent Dashboards
 7. Governance, Security & Lineage Fusion Data Intelligence isn’t just about delivering insights - it’s built on a robust foundation of security governance and data lineage that brings trust, safety, and compliance to the analytics lifecycle. 🔐 Security Inherited from Fusion & Managed via OCI IAM FDI inherits its security framework directly from Fusion Cloud Applications. Role-based access, including data roles and duty roles configured in Fusion, are seamlessly enforced within the FDI semantic layer and Autonomous Data Warehouse (ADW). This ensures that users can access only the data they are authorised to see - without duplicating access definitions in multiple systems. User and group management within FDI is handled through OCI’s Identity and Access Management Service (IAM). You can sync your Fusion App users and roles into OCI IAM or manage them natively via OCI, and then assign access through system and job-specific groups tailored to FDI. This 1:1 mapping ensures governance is inherited and consistent across both transactional and analytics layers. Oracle also manages infrastructure-level security - covering upgrades, patching, encryption, IAM policy enforcement, key management, and auditing - helping to maintain compliance and relieve the operational burden on your team. 🧭 Data Lineage & Quality Built-In Trusted analytics demand transparency - and FDI delivers that through built-in data lineage and validation mechanisms. The system tracks the flow of data from source tables in Fusion Apps, through ingestion pipelines, into curated star schemas, and finally into Semantic Layer metrics and dashboards. Fusion SCM Analytics documentation provides end‑to‑end lineage spreadsheets that detail column‑ and table-level mappings, making it easy to trace every KPI back to its source fields. You can also monitor pipeline activity in the FDI Console, which records execution timestamps, row counts, and error logs - providing a clear audit trail of data loads and transformations. Further, FDI includes validation metrics that reconcile data loaded into ADW against transactional data in Fusion. These can be scheduled or run on‑demand, with reports surfaced directly in OAC - making it easy to identify data drift or discrepancies and swiftly pinpoint areas for correction ✅ Summary: Trust, Safety, and Compliance
 8. Why This Architecture Matters for Organisations 🚀 Fusion Data Intelligence goes far beyond traditional BI. It sits at the heart of Oracle’s broader Data Intelligence Platform, delivering a unified, 360° view across all enterprise data—transactional, analytical, structured, and unstructured . 🌟 A Unified Data-Intelligence Ecosystem Unlike legacy stacks - OBIA, ODI, siloed data centres - FDI is built on Oracle’s next-generation Data Intelligence Platform. It blends data lakes, Autonomous Data Warehouse, Oracle Analytics Cloud, OCI AI services, and GoldenGate streaming into a seamless, managed ecosystem . This means organisations can now handle batch and real-time data, include external sources and apply AI/ML—all within one secure environment. This is Oracle's vision as Data Intelligence Platform has been announced but is not yet generally available. 🔄 Consistent Insights Across Pillars FDI’s architecture supports conformed dimensions and shared semantic models spanning finance, HR, SCM, and CX. This allows for unified KPIs and analytics, enabling stakeholders to ask and answer cross-domain questions like:
The result is enterprise-wide analytics based on a single source of truth . 💡 Full Extensibility with Governed Access As part of Oracle’s Data Intelligence Platform, FDI offers extensive extensibility. Users can bring in external datasets, extend semantic models, build custom analytics, and consume OCI AI services - all within Oracle’s security framework. Governed self-service means broad analytical freedom without compromising data integrity . 🛠 Evergreen Platform, Zero Infrastructure Burden The platform is fully managed and evergreen. Oracle handles everything - from provisioning, patching, tuning, and upgrades to integrating the latest AI services. Teams can focus on driving value rather than wrestling with infrastructure .  🎯 Summary: Strategic Differentiators
As you’ve seen, Fusion Data Intelligence delivers a fully managed, cloud-native analytics ecosystem - bringing together Fusion SaaS, Oracle’s Autonomous Data Warehouse, and Analytics Cloud under one secure, AI-enhanced platform. It unifies data across domains, embeds intelligent insights and governance, and eliminates legacy complexity - truly delivering on Oracle’s vision of a Data Intelligence Platform. Now it’s your turn: take a moment to reflect on how FDI could accelerate insight‑driven transformation in your organisation.
|
AuthorA bit about me. I am an Oracle ACE Pro, Oracle Cloud Infrastructure 2023 Enterprise Analytics Professional, Oracle Cloud Fusion Analytics Warehouse 2023 Certified Implementation Professional, Oracle Cloud Platform Enterprise Analytics 2022 Certified Professional, Oracle Cloud Platform Enterprise Analytics 2019 Certified Associate and a certified OBIEE 11g implementation specialist. Archives
March 2026
Categories
All
|
RSS Feed
