OceanBase DataPilot AIP: A Different Path to Ontology-Driven AI Capability Surfaces

The Problem: Questions Outgrew One-Shot NL2SQL

Since launching OceanBase DataPilot, user questions have grown increasingly complex.

Early on, people asked "What was GMV by channel last month?" — a single NL2SQL call was sufficient. Gradually, questions evolved: "Why did Category A's sales decline?" "Classify the reasons for delayed orders and output a weekly report." "Run this analysis automatically next week and push results to me."

These questions share a common trait: they're no longer a single query but a complete business process — involving data comprehension, metric alignment, analysis step orchestration, and potentially write-back and external integration.

Building these capabilities, we observed two failure modes recurring:

1. The Agent starts from scratch every time — ask the same question three times, get three different answers. Business users lose trust.
2. Every question becomes a pre-defined template — templates are never complete, and the product team drowns in maintenance before users even ask their questions.

Why We Studied Palantir AIP

Palantir is one of the companies that most thoroughly integrates AI with enterprise operational workflows, serving government, finance, and energy clients with extreme requirements for permissions, audit, and stability.

Its product stack has three parts: Foundry handles data operations, Apollo handles automated deployment, and AIP is the AI capability layer on top — embedding LLM capabilities within existing enterprise security, audit, and resource management frameworks.

We studied Palantir not to copy its product, but because it offers the most mature reference answer to the question of "enterprise-grade AI capability surfaces."

AIP's core isn't a chat window — it's an "AI operation layer that enters business workflows." It provides Agents with an Ontology-based capability surface: AI faces business objects like "Customer," "Order," and "Approval" rather than scattered tables and SQL.

The product chain: AIP Assist helps builders write code and understand data; Agent Studio defines what each Agent can see and invoke; AIP Threads is the business user's conversation entry point; AIP Logic orchestrates complex flows. Audit runs throughout.

The key insight worth borrowing: the abstraction of "capability surface." On the surface, it's the same "LLM + tool calling" as ordinary Function Calling. The difference is where governance lives. In standard Function Calling, each Agent privately owns a set of functions, and audit is bolted on after the fact. In AIP, Agents face shared Objects, Functions, and Actions from the Ontology — permissions, validation, and audit are built into the Action system itself.

This means enterprise AI capabilities gain a set of reusable semantic assets, rather than every Agent assembling its own.

The Real Difference: Build Order

The disagreement isn't "whether to use Ontology." We agree with Palantir: Agents should face Objects, Functions, and Actions in an Ontology, not raw tables. The real difference is the product construction sequence.

Palantir: top-down. Enterprises first build Foundry Ontology — modeling all objects, relationships, Functions, and Actions. Agent Studio then carves out a specific Agent's capability surface from this global Ontology. Users invoke controlled capabilities in Threads. The premise: Ontology is already mature.

OceanBase DataPilot: bottom-up. Our first wave of users rarely arrive with a complete business object model. The common starting state: a few core tables, an incomplete metric definition document, and analysis experience scattered across personal chat histories. Requiring them to build a full Ontology before enabling the Agent means the product never lands.

So DataPilot takes a different path. Users create subdomain Agents within a workspace — the workspace is a container holding all data, semantic assets, and Agents for a business domain; a subdomain Agent is a specialized analytical agent scoped to a business scenario (e.g., order fulfillment Agent, inventory analysis Agent, store replenishment Agent, business daily report Agent). A subdomain Agent doesn't need a complete Ontology to start — just its working tables, initial knowledge, and simple business constraints.

The real Ontology grows from usage. Users ask questions, Agents answer, users confirm or correct — after several rounds, certain objects, relationships, metrics, and terms get used repeatedly. Only then do they earn a place in the Ontology. Successful analyses that get called repeatedly earn promotion to Actions.

This isn't a static model drawn once by the product team — it's a dynamic asset co-produced by the workspace and its Agents. Agents don't just consume Ontology; they participate in producing it.

Functions vs. Actions

In DataPilot, Actions are not just "operations that modify data." The precise definition: an Action is a parameterized business process stored in the Ontology, callable by Agents. It can be read-only; it can be complex analytical SQL or a multi-step analysis DAG, exposing a set of input parameters, a description, and an output contract.

Functions answer "how to calculate" — delay rate, week-over-week change, inventory risk score, customer health index. These are metric assets, typically defined via MetricFlow semantic layer.

Actions answer "how to do" — look up delayed orders, perform week-over-week analysis, troubleshoot anomalies, write back to systems, trigger approvals. These are process assets. A single Action can invoke multiple Functions internally.

Three Governance Tiers for Actions

By governance intensity, we classify Actions into three tiers:

Query Actions — the lightest tier. Handle read-only retrieval like "find delayed orders for customer X." Governance focus: parameter validation, row/column-level permissions, SQL sandboxing.

Analysis Actions — handle multi-step reasoning like "identify why sales declined." Governance focus: intermediate steps are traceable, results are explainable and verifiable.

Execution Actions — handle side-effect operations like "push work order" or "trigger approval." Heaviest governance: strict publish/invoke permissions, explicit side-effect declarations, mandatory human confirmation, idempotent design, full audit trail, rollback support where needed.

Execution Actions mark the boundary between "analytical system" and "action system." We intend to guard this boundary tightly — until read-only governance is stable, prematurely opening write operations is not advisable.

How Actions Are Born: Bottom-Up Crystallization

Palantir's Actions are primarily designed by architects during the Ontology construction phase. DataPilot preserves that traditional path but must also walk another: Actions crystallize from validated successful analyses.

The typical flow:

1. User asks a real business question
2. Agent completes the analysis using available data, metrics, and SQL capabilities
3. User confirms or corrects the result
4. Agent evaluates whether the analysis meets four criteria: high-frequency, stable, clear parameters, verifiable results
5. If yes, Agent proposes saving it as an Action — extracting description, parameters, process, output format, and test cases
6. User confirms permissions and governance policies
7. Published to subdomain or workspace

The significance: one-time answers become reusable capabilities. Business know-how is no longer locked in personal chat records or ad-hoc SQL — it becomes governed workspace assets.

Subdomain Agents and Workspace Graphs

We don't plan to build a standalone Agent Studio product, but we absorb its core idea: configure capability surfaces around business subdomains.

In a supply chain workspace, multiple subdomain Agents coexist — order fulfillment, inventory analysis, store replenishment, business daily report. Each has clear boundaries: data scope (which tables/views/sources), Ontology scope (which Objects, Links, Functions), Action scope (which query/analysis/execution Actions), knowledge scope (documents, SOPs, metric definitions), and behavioral constraints (read-only by default vs. executable, when human confirmation is required).

The relationship between subdomains and workspace graph is bidirectional. Subdomain Agents crystallize objects, metrics, and Actions from real problems; once stable, these assets enter the workspace-level semantic graph; the graph then becomes the shared semantic layer for new Agents, enabling immediate reuse and continued expansion. Ontology is therefore a continuously growing workspace asset, not a static model drawn once.

When to Use Actions vs. Free-Form Generation

Our strategy: "prefer reuse, allow fallback."

When the Agent receives user input, it first identifies intent, objects, metrics, and parameters, then searches available Actions in the current subdomain and workspace. If match confidence is high enough — invoke the Action. If parameters are missing — ask the user. If no Action matches, coverage is incomplete, or risk level is elevated — fall back to free-form analysis. When free-form analysis produces a stable, reusable solution, the Agent proactively asks whether to crystallize it as a new Action.

Matching cannot rely on name similarity alone. We also evaluate permissions, object scope, whether parameters can be reliably extracted from context, whether the Action has passed test cases, and whether it involves write operations. Any uncertainty biases toward free-form fallback rather than forcing a partial match.

Layered Governance

With free-form generation preserved, governance cannot rely solely on Actions — because much analysis happens in the free-form layer. Our approach: defense in depth.

• Free-form layer: Read-only by default. Generated SQL runs sandboxed, respects table/field/row permissions, enforces hard limits on result rows, execution time, and resource consumption. Full query logs and user confirmation traces.
• Read-only Action layer: Strong input validation, bound to explicit object and metric scopes. SQL/execution body validated at save time; test cases and regression tests supported.
• Execution Action layer: Strictest governance — elevated publish/invoke permissions, explicit side-effect declarations, mandatory pre-execution human confirmation, idempotent design, full audit, rollback when necessary.

These three layers coexist — the Agent selects the appropriate path based on question type and risk level.

The Final Architecture

OceanBase DataPilot AIP's target form has two capability layers:

Platform built-in layer (maintained by the product team): NL2SQL, metric computation, charts, reports, Workflow, knowledge retrieval, semantic modeling. Shared across all workspaces, invariant to business domain.

Workspace customization layer (co-produced by users and Agents through usage): objects, metrics, terms, analysis flows, Actions, templates, subdomain Agent configurations. This layer is the true carrier of business know-how — different for every workspace, and rightfully so.

Between "always use pre-defined Actions" and "always free-form" lies the growable middle layer DataPilot is building: new questions start with free exploration, stable solutions crystallize into Actions, subdomain Actions aggregate into workspace Ontology, new Agents reuse the workspace graph, write operations and external integrations open gradually as governance matures.

What's Next

Short-term: Push Action crystallization automation further. Currently, identifying high-frequency stable solutions still relies partly on manual judgment — we want the Agent to more proactively recognize crystallization opportunities from conversation history. Workspace graph visualization and search need to ship soon.

Mid-term: Connect DataPilot with more OceanBase unified capabilities — especially solidifying write-back channels and external system integration for execution Actions. This is the critical step from "analytical system" to "action system."

Open question: How do we govern conflicts and merges when different users and subdomains each crystallize their own Ontology fragments? This is the hardest part of the bottom-up path, and the problem we're focused on solving next.