Kubeflow Launches Semantic Operator to Give AI Agents Governed Data Access
Kubeflow has introduced Semantic Operator, a new subproject that aims to give AI agents trusted answers from business data. According to the project, the language model never writes the SQL: certified metrics are defined once, governance is applied, and deterministic software produces a single query.
- Semantic Operator is a new Kubeflow subproject that operationalizes Apache Ossie (incubating) semantic models on Kubernetes.
- AI agents request certified metrics through MCP, and the language model never writes the SQL.
- Governance rules run before query planning, and unauthorized requests fail before any SQL exists.
- Deterministic SQL is executed on StarRocks or Trino, with the model version and a request hash attached.
- The ossiectl command drafts a SemanticModel YAML file from existing metadata such as Apache Polaris and DataHub.
The problem: agents guessing at business meaning
The Kubeflow blog describes a common pattern in AI agents for analytics. A language model connects to a database, discovers tables and writes SQL based on the wording of a question. It sees schemas and column names, but often not the business meaning behind them.
The post gives examples. A table called subscriptions does not explain which statuses count as active. A column called revenue does not say whether it holds gross, recognized or recurring revenue. A different phrase can lead to a different table, join, filter or aggregation, and both queries may run successfully while only one matches the business definition.
Kubeflow frames this as a business context problem rather than only a query generation problem. A confident but incorrect number, it says, can affect pricing, investment, staffing and customer decisions.
How Semantic Operator works
Semantic Operator is a Kubernetes operator and semantic server that operationalizes Apache Ossie (incubating) models. Apache Ossie defines a vendor-neutral format for semantic models, covering datasets, fields, relationships, metrics and AI context. The operator accepts an Apache Ossie based SemanticModel Kubernetes resource, validates it and checks its physical schema bindings. A valid model is compiled into a versioned artifact.
The serving layer exposes certified concepts through MCP (Model Context Protocol), REST and governed SQL views. The process runs in three steps:
- Define metrics. Data teams describe certified metrics once in an Apache Ossie model, which is checked against the live database schema before publishing.
- Request metrics. Agents discover and request metrics through MCP and see only the metrics and dimensions they are allowed to use.
- Get deterministic SQL. Semantic Operator applies governance, creates one SQL statement, runs it on StarRocks or Trino and returns the results.
If a model update fails validation or schema checks, it is not published, and the last valid version stays available. According to Kubeflow, this keeps an invalid change from silently reaching every agent and application.
The same structured request, effective identity, model version and query engine dialect produce the same SQL, which the project says makes queries easier to review, test and audit. Generated statements also carry the model version and a request hash for traceability.
Governance and the ossiectl helper
Governance runs before query planning. Policies control which metrics and columns a role may use and can apply bounded row filters. An unauthorized request fails before SQL exists. Models can also name an external policy provider such as Open Policy Agent or Apache Ranger. That provider adds a second decision before any SQL is generated and cannot weaken the model's built-in governance.
To ease the work of writing a first model for a platform with many tables, the project includes the ossiectl command. It can inspect a query engine information schema, including tables exposed through an open catalog such as Apache Polaris, and enrich the result with business context from DataHub. It writes a draft SemanticModel YAML file with datasets and fields. Engineers then review it, add certified metrics and relationships, and apply it to Kubernetes. Kubeflow stresses that this is an authoring step and not part of the query path, and that the YAML remains normal source-controlled configuration.
What it means for data teams
Kubeflow argues that many organizations have built semantic formats tied to one query engine, catalog or business intelligence tool, which makes metrics hard to reuse across several databases or lakehouse engines. Semantic Operator is positioned as a way to keep the business contract portable while the query itself is specific to the selected engine.
According to the project, a notebook, dashboard, pipeline, application and agent can all use the same business contract. Semantic Operator is now a Kubeflow subproject. Its source code is in the Kubeflow Semantic Operator repository, and the documentation covers architecture, installation, model authoring and runnable examples.


