Ask Where the Answer Came From: ShEx as an Agent's Source of Truth

Ask an AI agent what values the status field can hold, and it will answer. The interesting question is not whether the answer is right. It is where the answer came from.

Most agents work at the bottom of an evidence hierarchy. Weakest is the field name, a suggestion someone made on a Tuesday. Next is a sample of records, which supports claims about what did occur and none about what may occur. Above that sits a declared schema, which states requiredness and permitted values. At the top sits a governed model whose terms carry identifiers, so "this field means that concept" can be checked rather than believed.

An agent working from names and samples produces confident, plausible, unfalsifiable answers. It cannot tell an optional field from one that happened to be absent, a closed value set from the three values that showed up, or a name meaning a registered legal name from one meaning a display handle. The fix is consultation, not a better guesser.

A language whose plain text is already the answer

ShEx is excellent material to consult: Shape Expressions was designed to be read by human reviewers, and the qualities that make it review-friendly also make it good context for a language model.

Repetition is written, not implied: a bare constraint means exactly one, ? at most one, * and + repetition with and without a floor, {n,m} a stated range. Permitted values are enumerated inline as value sets. Specialization is one keyword, and a constraint pointing at another shape says so. Every predicate is an IRI, so the agent reads a global identifier rather than a local naming convention. In one screenful, a ShExC document answers the four questions an ungrounded agent invents answers to: what exists, what is required, what repeats, and what it means.

The hard part is supply — how does an agent get the current, governed shapes instead of a file attached to a ticket eight months ago?

Consultation over MCP

CoreModels serves that supply over the Model Context Protocol. Point an MCP-capable client at the /mcp endpoint on your host — https://coremodels.example.com/mcp — complete the OAuth flow, and the agent holds a read-only toolset scoped to the projects its user can see.

The grounding loop is short and dull. list_projects returns what the caller can reach; get_project_summary lists the types, elements, and taxonomies in one of them; export_shex returns that project's model as a ShExC document.

export_shex's arguments are the difference between grounding and context flooding. It takes the project id, optionally a space to scope to, and optionally a set of type node ids — so an agent chasing one question can request the two shapes that bear on it rather than an entire enterprise model. Cardinality markers are emitted by default, and what comes back is the model as governed right now. And validate_json checks an instance document against the project's stored JSON Schema.

Translation with no side effects, and fine print attached

Agents are constantly asked to convert schemas, not just read them. transform_schema does that statelessly, with ShEx available on either side: hand it a partner's shapes and ask for JSON Schema to reason over, or hand it a SQL definition and ask for shapes to submit. Arguments: project id, source format and schema, target format, and options — a target hint to map toward, a mapping kind, an authored guide, a SQL dialect. Nothing is written to any project.

What comes back is more than converted text: the executed mapping plan as a replayable artifact, and a lossiness ledger naming everything the translation could not preserve. An agent reporting "here is your DDL, and the governed value set became an unenforced text column because the target has no inline enum" is doing the job. Returning clean output without the fine print transfers a risk to a human who does not know they received it.

Matching by meaning, not by string similarity

The deepest advantage is the identifiers. Shapes imported into CoreModels have their predicates and shape names lifted into the model's cross-standard mappings automatically, and those mappings travel into every later export.

So when an agent faces the classic integration question — which field here corresponds to which field there — it is not reduced to string similarity, which cheerfully pairs name with name while missing that one names a person and the other a product. It can align by declared meaning: two elements pointing at the same vocabulary term correspond because both models said so, and an authored mapping guide can make pairing by declared mapping URI its backbone. A claim that cites the governed mapping is verified in seconds; a claim answered from inference can only be trusted.

The failure modes are built for agents too, because an agent that cannot get an answer will otherwise manufacture one. Ask for an inferred mapping with nothing to map toward and the call fails saying the resolver requires a target to match against. Misspell a key in an authored guide and it is rejected with the path and the list of keys that exist. Name an unregistered field transform and the gate refuses the plan. Each is a correctable error rather than a confident wrong answer.

Boundaries an agent cannot talk its way past

The /mcp endpoint serves read-only tools. Write tools live on a separate admin endpoint — and the enforced boundary is the per-project role check, not which endpoint a token came from. No amount of persuasive prompting mints an Editor or Admin membership that was never granted.

Every tool's protocol metadata declares whether it is read-only and whether it reaches outside the system. The AI-assisted mapping path sends schema content to an external model provider server-side, so it is declared open-world and gated to Editor or Admin. A model-proposed plan passes the same validation gate as a hand-authored one, with at most one repair attempt and no credit for self-reported confidence.

The same discipline governs meaning. An agent can search public ontology services for candidate terms, and the response states plainly that suggestions are advisory and nothing was written; binding a term is a separate, explicit act on the admin surface. Agents propose; people decide.

Humans govern the model, the model grounds the agent, and the agent stops guessing and starts citing. ShEx earns its place in that loop by being a schema language whose plain text already answers what an ungrounded agent would otherwise invent.

The MCP quickstart at https://coremodels.example.com covers the connection flow and the read-only toolset, export_shex and transform_schema included.