Writing

A Schema Registry for AI Agents on the Lakehouse

I keep coming back to the schema registry when people ask how to ground AI agents on a lakehouse. In event-driven architectures, a schema registry is what keeps producers and consumers honest. Raw Kafka topics carry bytes. Consumers rely on a versioned contract to interpret fields like customer_id and event_time. Without it, every consumer guesses. They may parse a few bytes correctly, but when the producer adds a field or changes an encoding, the guesses break. The registry makes the contract explicit and versioned, so change becomes a managed event instead of a surprise.

Oracle's Business Semantic Layer plays that same role for AI agents sitting on a lakehouse. Raw Iceberg tables have columns and types, but no shared business meaning. A column named amount might be gross, net, or something else entirely. A semantic layer gives agents a queryable contract: revenue means recognized net revenue, not bookings; region maps explicitly to a geography hierarchy. The agent does not have to infer what a business term means from column names or sample data. It resolves the term against a definition that someone has already reviewed. That kind of precision matters when a downstream report or financial result gets questioned. An agent that skips this layer is like a consumer parsing a topic without the .proto file: it may return a number, but not one you can defend in an audit.

The expanded Iceberg support is the other half. A semantic layer is only useful if the definitions are not locked to one execution engine. Iceberg is an open table format, which means the same table can be read by multiple engines without a proprietary gateway. If the semantic definitions sit on top of an open format, they inherit that portability. SQL-based management keeps the whole thing boring and interoperable. You define terms, map them to physical columns, and version them. You do not need a special client or a new query language. That is the point.

That is the right grounding pattern for agentic applications: not afterthought context injection, but a contract in front of the data. Many agent designs try to fix weak grounding by appending more context to a prompt or retrieving a few sample rows. That can work for simple questions, but it does not scale when the question has to stand up to scrutiny. Context injection may help a model sound more informed, but it does not create a source of truth. A contract in front of the data means every agent query has to go through the same semantic definitions. A number returned by an agent is only as good as the definition it resolved against. If that definition is versioned and shared, the answer is defensible. If it is not, the answer is a guess.

This is not a new idea. Event-driven teams learned it when they adopted schema registries. The names are different, but the discipline is the same: make the contract explicit, version it, and put it in front of every consumer. For AI agents on a lakehouse, the Business Semantic Layer is that contract. Iceberg support keeps the contract from being an Oracle-only artifact. That combination is what I would want under any agent that is supposed to answer business questions reliably.

Originally covered at oracle.com ↗