An AI agent’s answer is only as good as what it reads. Every platform has built something for its agent to read, and each keeps it inside its own walls.

So meaning curated for one platform’s agent gets curated again for the next. Instead, write the business meaning down first, on no platform, and keep the cleaned silver tables in their sources’ shape. That approach is AIMS, short for AI-ready, Meaning-first Silver. The agent stays yours or your platform’s. AIMS designs what it reads.

One question touches six decisions a person already made

How many customer accounts in Australia had an order move to Cancelled last quarter, by sales owner? An agent that plans and runs a question’s steps itself, rather than returning a chat answer, makes a decision about meaning at every step. That’s agentic reporting.

In AIMS, each clause reads a decision a person already approved. Start with keys. Customer 123 in the order system and customer 123 in the sales system can be two different customers. A key only means something inside the system that issued it, its record source.

  • Customer accounts are Customer Account, one business thing with two business keys, one per record source.
  • An order moving to Cancelled is a new Sales Order version, one row per version. So the agent counts accounts, not rows, and reads C as Cancelled because a person mapped that code.
  • Last quarter falls on the source change time, not the load time.
  • Which account is the one that placed the order, the sold-to role.
  • In Australia is the trap. The AU in the order system’s key is a company code, and nothing a person approved says it’s a country.
  • By sales owner has nothing approved behind it. The only candidate, OwnerUser, carries no business meaning. It matters only to its source, so it’s marked source-only and classified internal.

Country lives only on the sales system’s account, and the two systems key the same customer differently. So the agent reaches it through a match that ties both systems’ keys to one shared key, made because this question needs it.

The agent answers the rest and declines the last clause. That refusal is the most useful line in the answer. A guess would have grouped the accounts by an internal user identifier and called it sales ownership.

What does an AI agent read in a data contract?

With nothing written down, an agent has to reconstruct meaning from column names. In AIMS it reads one document per table instead, and the catalog’s summary of each table is that table’s data contract. From the agent’s side it’s a briefing.

It says what one row is, which key is unique in which record source, which version and date to use, and how tables join without doubling a row. Each column’s mapping, with its code list, unit and currency, says what a value means. Lineage says where it came from. Last, it lists what’s missing, its known limitations.

Our first book put the rule in a heading: “The AI cannot see what was never captured.” That book’s contract is what any generator must be told. The data contract is that capture for one table, projected for the agent before anyone asks.

The known limitations keep an agent honest

That last field matters most. It lists every unmapped column and every unmapped code, so an agent can say “I cannot answer that part” instead of guessing. A source-only column, like OwnerUser, lets an agent decline too.

What if the order system starts sending a status code nobody has mapped? The contract lists the gap. So the agent says its count leaves out orders in that status, instead of dropping them silently. A refusal that names what’s missing tells a person what to map next. A confident guess never does.

Every platform builds its own semantic layer for AI agents

An agent left alone with raw tables guesses, so each platform gives it a curated layer of meaning over them, a semantic layer.

On Databricks, Genie reads its knowledge store and generates from a table’s comments and the primary and foreign keys declared on it. In Microsoft Fabric, a data agent’s lakehouse table descriptions are entered in the agent itself, in preview. Or they live in the reporting tool’s semantic model, where Copilot reads the first 200 characters of each. Snowflake’s semantic views page says “Currently, Cortex Agents reads the information captured in the semantic view definition and generates the SQL against the physical tables directly.”

None of them is wrong. But each annotates tables after the data landed, for one platform’s agent, so you’ll write the same meaning again on every platform you add.

In AIMS the meaning comes first. The business things, how each is identified and how they relate, make up your business model. Add the mappings that tie each silver column to it, and you have the meaning layer, written on no platform. Meaning written once still has to be rendered into each platform’s object, by a template that knows that platform’s limits. Once it is, an agent on Databricks, Snowflake or Microsoft Fabric reads the same contract. The templates differ, but the meaning doesn’t.

Find the clauses your agent would have to guess

Try this on your own estate.

  1. Pick one business question your team answers every month.
  2. List the decisions it touches: what one row is, which key from which system, which date and what each code means.
  3. Find where each decision is written today, in a semantic layer, a load script or one person’s head.
  4. Mark every clause an agent would have to guess, and name the person who approves that meaning.

Those marks are your first known limitations. A decision written nowhere is a guess your agent will make for you.

In DeltaVault, the AI does catalog work you then review, rather than answering questions about your data.