Skip to main content

Talk · data2day 2026

Agentic Analytics: From Hype to Real Value

Fabian Biberger (Founding Engineer, Entropy Data) ·

Fabian Biberger’s talk at data2day 2026 in Cologne, held in German as Agentic Analytics: Wie aus Hype echter Mehrwert wird. It follows Entropy Data’s path from an MCP server to a governed chatbot, the context an agent needs to work reliably on data, and Apache Ossie for ontologies and semantic models.

Title slide: Agentic Analytics, Wie aus Hype echter Mehrwert wird, Fabian Biberger, data2day, 07.10.2026, next to a screenshot of the Entropy Data chatbot recommending the Orders data product

An edited summary of the talk, translated from German.

TL;DR

Five key points and lessons learned from the talk.

  1. Governance decides adoption. The MCP server impressed customers, but they could not use it: it combined data on a personal computer outside governance, and many companies had no approved chat client. The lesson was to bring the agent inside the governed marketplace, so Entropy Data built its own chatbot.

  2. Decide whose identity runs the query. With one service account, Databricks sees a single user and the audit log no longer shows who accessed what. Passing each identity through OIDC lets the platform check every access individually again.

  3. Context makes agents reliable. The talk names seven factors: silver-quality data, a documented data model, company structure, lineage, sample data, semantic models and ontologies. Start with the basics and add the boosts on top.

  4. Semantics close the gap. Data contracts, contract tests, lineage and teams already cover five factors, while semantic models and ontologies were still open. Apache Ossie anchors the ontology in the semantic models, and that link lets the agent build better queries.

  5. Agents need identity and purpose. Autonomous agents act either on behalf of a user or as a service with their own identity. Next comes purpose-based access, where the stated purpose is checked against the terms of use in the data contract and the semantics.

Starting point, what we do at Entropy Data: a marketplace for data products (data contracts, multi-platform, self-service), open metadata standards (portable metadata, metadata sync to Git, open-source tooling, ODCS, ODPS, Apache Ossie), and automation (automated contract tests, data quality scoring, AI-assisted governance, Data Contract CLI)

Where Entropy Data Starts From

  • Marketplace for data products with data contracts, multi-platform, and self-service.
  • Open standards: ODCS, ODPS, and Apache Ossie.
  • Automation: contract tests with the Data Contract CLI, data quality scoring, AI-assisted governance.
Motivation: 01 improve the search experience in the data marketplace, 02 enable analytical AI with governance, 03 create a playground for new data products, 04 enable agent-supported data product development

Four Reasons to Go Agentic

  1. Better search in the data marketplace.
  2. Analytical AI with governance.
  3. A playground for new data products.
  4. Agent-supported data product development.
MCP: an AI client with a question or agent task calls Entropy Data, which offers MCP tools such as Search, Fetch, and Execute Query behind a data governance layer, connected to the marketplace (metadata of the data products) and the data platform (the actual data). Various tools, with support for governance checks and access requests

Step One: An MCP Server

  • AI clients such as Claude or ChatGPT connect to the marketplace via MCP.
  • Tools: search data products, fetch data contracts, execute queries.
  • Governance checks and access requests sit in between.
Speech bubble over a blurred chat screenshot: Wow, that looks great. But we will never be able to use it.

“Wow, That Looks Great. But We’ll Never Be Able to Use It.”

  • Governance: MCP combines data on a personal computer, outside governance.
  • Availability: many companies have no approved chat client, or only Copilot.
  • Decision: build our own chatbot.
We are building a chatbot: the Entropy Intelligence chat inside the Entropy Data marketplace answers which data product to use for customer purchasing behavior and recommends Orders. A side panel shows progress, purpose, governance, data product, semantics, data model, connection, and SQL

So We Built a Chatbot

  • Entropy Intelligence lives inside the marketplace, under existing governance.
  • The system prompt can be adjusted to Entropy Data's use cases.
  • MCP tools are built in directly, and governance cannot be bypassed.
User interface, control over the interface: a side panel with the Customers data product and its four output ports with contracts, and twelve semantic concepts such as Order, Order ID, Customer ID, Customer Email, and Billing Address
The chatbot answers give me access to customers: it recommends the non-PII Databricks port based on the AI instructions of the data product owner, notes that the user does not have access yet, and shows a Request Access button with the note Access has been approved

"Neue Features lassen sich einfach kommunizieren": with control over the interface, new features are easy to communicate.

User Interface

  • Better traceability through the context sidebar: data product, output ports, semantic concepts, and purpose at a glance.
  • New features directly integrated, for example a Request Access button right in the conversation.
  • Reused interface elements, such as the chips and icons from the marketplace, help users find their way.
Connection to the data platform, one account per organization: JD (marketing), Turk (controlling), Elliot (sales), and Carla (data engineering) all go through Entropy Data and one service account entropy-data to Databricks, which sees only one user. The audit log shows entropy-data SELECT orders, customers, revenue

Who Is Actually Querying the Data?

  • One service account for the whole organization.
  • Databricks only sees one user: entropy-data.
  • The audit log no longer shows who accessed what.
One account per user with OIDC: the same four users go through Entropy Data, which gets their identity from an identity provider such as Entra ID, and each user connects to Databricks with their own credentials. Databricks sees and checks every user individually. The audit log shows jd, turk, elliot, and carla
  • OIDC: the identity provider, for example Entra ID, passes each identity to the platform.
  • Databricks checks every access individually, and the audit log is meaningful again.
  • Principle: first decide whose identity data access runs under.
The right context: What does an agent need to operate successfully on data?
The right context: seven factors feed AI analytics performance (reliability, quality, consistency): ontologies, semantic models (metrics and dimensions), documented data model, company structure, lineage, sample data, and data of at least silver quality

The Right Context: Seven Factors

  • Basics: data of at least silver quality and a documented data model.
  • Boosts: company structure, lineage, and sample data.
  • Semantics: semantic models (metrics, dimensions) and ontologies (shared concepts).
The same seven factors, now with the standards and tools that cover them: ODCS for the documented data model, the Data Contract CLI for silver quality, OpenLineage for lineage, Entropy Data for company structure and sample data. Ontologies and semantic models are marked with question marks

Five Covered, Two Open

  • Data model and silver quality: covered by data contracts and contract tests.
  • Lineage through data product links and OpenLineage, sample data stored partly in the data contracts, company structure as teams and domains.
  • Still open: semantic models and ontologies.
The right context: How do we represent ontologies and semantic models for agents?
Apache Ossie (incubating), the universal standard for semantic data: an industry-wide specification effort to standardize how semantic metadata is exchanged across analytics, AI, and BI platforms, previously known as Open Semantic Interchange. 100% vendor neutral, YAML configuration, Apache 2.0, AI ready

Apache Ossie

  • Formerly Open Semantic Interchange (OSI), now Apache Ossie.
  • An incubating Apache project for semantic models and ontologies.
  • Entropy Data supports it as its format for semantics.
Ontology and semantic model: the ontology covers business concepts, relationships, and rules; the semantic model covers dimensions, metrics, and aggregations
Ontology, concepts and relationships: a graph with Order, Line Item, Article, Product, Shipment, Shipping Address, Billing Address, Postal Address, and B2B Customer, connected by relationships such as places, contains, ships_to, bills_to, fulfilled_by, references, has_variant, is a, and subsidiary_of

Ontology and Semantic Model

  • Ontology: concepts such as Order, with properties.
  • Relationships carry meaning: an order ships to a shipping address.
  • More meaning gives the agent more context.
Semantic models, metrics, dimensions, aggregations: semantic models from dbt, Power BI, Tableau, Looker, and others feed one semantic model
  • Semantic model: metrics, dimensions, and aggregations over the data.
  • Known from dbt MetricFlow, Power BI, Tableau, and Looker.
  • Calculation logic, such as the order value, is defined in one place.
Ontology mapping: business concepts are anchored in the semantic layer by a mapping from the ontology to the semantic model
  • Ossie anchors the ontology in the semantic models.
  • A mapping layer links each concept to where it appears.
  • With that link, the agent builds better queries.
The right context, complete: all seven factors are now covered, with Apache Ossie for ontologies and semantic models

Where to Start

  • Start with the basics: a documented data model and silver-quality data.
  • Company structure, lineage, and sample data are boosts on top.
  • Semantic models and ontologies add better results and traceability.
Agent identity: on behalf of the user, the identity comes from the user's context and the agent acts on behalf of the user. Agent as a service: the agent gets its own identity, and additional metadata is required

The Agents Are Coming

  • Autonomous agents need an identity too.
  • On behalf of the user: the identity comes from the user, as in the chatbot today.
  • Agent as a service: an own identity, plus metadata such as the operator.
Outlook, purpose-based access: an analyst or agent asks for access. Purpose-based access control asks why, for which purpose. The agent states the purpose direct marketing. PBAC compares the stated purpose with the terms of use in the data contract and the semantics, and only then grants access to the data

Outlook: Purpose-Based Access

  • Analysts and agents must state why they need the data.
  • The purpose is checked against the terms of use in the data contract and the semantics.
  • An idea from the Q&A: limit access in time, for example to the agent's session.
Thank you! Questions? Come by our booth, we're happy to show you everything live. Write to fabian.biberger@entropy-data.com. Try Entropy Intelligence: start the 1-click demo on www.entropy-data.com

Try It Yourself

Related articles

A Data Marketplace is What Your Agent Needs

Why AI agents need a data marketplace to read data through governed tools and to build new data products, with two live demos.

What is Apache Ossie?

The open standard for ontologies and semantic models, formerly known as Open Semantic Interchange.

What is Purpose-based Access Control?

AI agents decide at runtime which data they need. Purpose-based access control checks every query against the terms of use in the data contract.