What an Agent Decides Before It Answers

Ask an AI agent connected to a bare warehouse what revenue was last week, and watch the decisions it makes before writing a line of SQL.

Which of these forty tables is the sales fact. Whether revenue sums a price column, and which one. Whether returns are in or out. The join key between sales and items. What "last week" means against a fiscal calendar it has never seen.

Every one is a coin flip weighted by naming conventions, and agents are exceptionally good at making coin flips sound settled. That is the failure mode: fluent, numeric, unverifiable output with no marker separating what was read from what was inferred. A well-grounded answer and a confidently invented one arrive in the same voice.

Apache Ossie matters here because it is the first schema format we have implemented whose authors clearly designed for this problem. It is also only half an answer: the other half is whether the description survives the trip intact, and whether the agent is told what did not.

Declarations instead of coin flips

An Ossie semantic model replaces each of those flips with a statement: which dataset corresponds to which physical source, which fields form the primary key, how datasets relate and on which columns they join, and what a metric's expression is — tagged by dialect, so the agent is not left translating syntax between engines.

Then ai_context adds the interpretive layer structure cannot express: instructions the data team wants respected, synonyms for the words humans actually use, worked examples of the questions the model is meant to answer. It attaches to the model, a dataset, a field, a relationship, or a metric, so guidance sits next to the thing it is about rather than in a preamble the agent may no longer have in context. This is a briefing written for a machine reader by the people who know the answers.

Grounding is a supply-chain problem

A briefing is only as good as the weakest hop between where it was written and where it is read. Most schema tooling treats descriptive content as decoration and sheds it at the first conversion — which is how a semantic model becomes a bare list of column names two systems downstream.

When CoreModels decodes an Ossie model, the machine-facing content is cargo, not commentary. Instructions, synonyms, and examples stay attached to the schema, dataset, field, relationship, or metric they were written for, and ride back out on export. Physical sources, unique keys, per-dialect expressions, join columns, and vendor extensions are preserved the same way — as are unknown keys, which a young ecosystem is full of.

Two structural conversions turn parsing work into lookup work. Primary-key fields arrive marked required, so "which columns identify a row" becomes a property rather than an inference from a naming convention. And each metric is linked to the datasets its expression names — a best-effort scan, reported in the ledger when nothing matched — so "total revenue touches web sales" is something to look up rather than to recover by reading SQL.

Consultation over MCP

Agents reach CoreModels through the Model Context Protocol. Our MCP endpoint is served at /mcp — https://coremodels.example.com/mcp for the placeholder deployment — protected by OAuth, and it serves read-only tools. An agent orients itself by listing the projects it can see, pulling a project summary of types, elements, and taxonomies, and searching nodes.

For Ossie work the tool is transform_schema, and it is stateless: the agent supplies a project id, a source format, the schema text, and a target format, and gets the converted schema back without anything being written anywhere. Both serializations are addressable — osi for the spec's YAML, osi-json for the JSON dbt ingests — and either is accepted on input. An agent holding warehouse DDL can produce a semantic-model skeleton; one handed an Ossie document can turn it into DDL or a data contract.

The response carries three things, the last two mattering as much as the first: the produced schema, the executed plan as a replayable artifact, and the complete lossiness ledger.

Optional arguments aim the conversion: a target hint schema to map toward, and a mapping kind of inferred, explicit, or AI-proposed. The AI path is deliberately fenced — it requires Editor or Admin membership and sends schema content to the Anthropic API server-side, which we state plainly because an agent working on someone's proprietary model should not learn that afterwards. Every proposal passes the same validation gate as a hand-authored one. The public read-only endpoint cannot write to a project at all; write tools live on a separate admin endpoint.

Knowing what you do not have

An agent that treats a converted schema as complete will state things the conversion never carried. That is what the ledger prevents.

It enumerates, with paths and plain explanations, everything a transformation could not preserve: that Ossie has no field type system, so types were approximated once for the whole schema; that a controlled value list had no representation on export and was left out rather than smuggled in; that a primary-key column matching no field was dropped, named explicitly. An agent reading the ledger knows not only what the schema says but what it no longer says — the boundary between a grounded answer and a fluent one. We would far rather an agent report that an allowed-value constraint did not survive than validate against a constraint that quietly disappeared.

The replayable plan serves a different virtue: the same plan against the same source produces the same output, turning a conversion an agent performed once into an artifact a human can re-run.

Failures are shaped for machines too. A document that is empty, is not valid YAML, is not a mapping at the top level, or contains no semantic model comes back as a failure with a path and a message the agent can act on — not a half-parsed model it might mistake for truth. Everything short of that is tolerated.

The point

The Ossie specification encodes in miniature what the industry is converging on: AI systems need meaning delivered as data, not divined from structure. A format with a section written for machines is half of that. The other half is infrastructure that preserves the section faithfully, serves it over a protocol agents already speak, and reports honestly on every translation.

Our aim is narrow and testable: an agent connected to CoreModels should never have to guess what your data means, and should always know when something was lost on the way.

To connect an agent, start with the MCP quickstart in the CoreModels documentation.