An agent connected over MCP does not fail the way a demo suggests it might. It rarely reasons its way to a wrong conclusion from correct inputs. It reads a field that means something other than what its tool description said, calls a tool whose name matched the request better than its behavior did, or acts on a definition that a system of record changed last quarter. Each of those is a schema failure. The reasoning was fine; the structure underneath it was not.
Three failures, one cause
The incidents an AI platform team logs against its MCP agents sort into three classes. Wrong tool: two tools expose overlapping data under different names, and the agent chooses by name. Wrong field: the same field name carries different meanings in the two systems that use it — a renewal date that is an anniversary in policy administration and a billed-to date in the partner feed. Stale definition: a definition changed at the source, and the copy the agent reads, or the tool description it was given, did not.
All three come from the same place. The enterprise authored its structure many times over — in the warehouse's tables, in the CRM's objects, in the API's contract, in a schema file a partner mandated, in an ontology someone started on the wiki — and no two of those authors agreed on what a customer, a product code or an open case is. Agents read across that landscape at speed and reproduce every disagreement in it.
Why a better model does not fix it
A model upgrade raises the ceiling on reasoning. It cannot tell that the warehouse's product grain is the plan and the policy system's is the rider; both readings are plausible, and the model has no way to know which one the request meant. A disagreement between two schemas is settled by a mapping — the owner of each side agreeing what maps to what — not by inference. Until that mapping exists somewhere the agent reads, every model reads the disagreement fresh and resolves it differently each time.
This is also why prompt fixes decay. A prompt that says 'renewal date means the anniversary' is a mapping stored in the wrong place: unversioned, unowned, and invisible to the next agent built on the same systems.
Schema drift is a supply-chain problem
Treat context as a supply chain rather than a prompt: sources, structure, semantics, validation, retrieval, agent operations, and the learning loop. Schema failures live in the second, third and fourth stages. Structure is whether the material has a machine-legible shape at all. Semantics is whether terms resolve to one definition across systems. Validation is whether anything checks a definition before an agent reads it. An MCP agent built on stages one and five to seven, with two to four left to chance, works in the demo and drifts in production, because production is where the schemas keep changing.
How to map it
The map is the first deliverable, and it costs nothing to draw except the time of the people who own the systems. Four questions produce it.
- Where is structure authored today, and which of those places do the agents actually read? List every system that holds a schema, a data model or a canonical definition — data and content platforms, the warehouse, APIs, ontologies, the wiki — with its format and its owner by role.
- What needs to plug in, and in which direction? For each agent workflow: when the agent does this, it needs that from this system, pulled or pushed.
- Where do two systems describe the same thing differently, and what is that costing? A register of the disagreements, each with the two systems, the disagreement in one line, the cost as the owners state it, and whether anyone owns resolving it.
- What would fix each one, and which fixes can be done in-house? Ranked by impact over effort, with the self-serve items marked.
Written down, the map tells an AI platform lead three things the incident log cannot: which disagreements produce the wrong-tool and wrong-field incidents, which of them have no owner, and whether the estate is ready for one governed model of the mappings between its schemas, or needs an ownership model first.
From the map to a governed model
The context that matters most is the structure your organization already authored: its schemas, data models and canonical definitions. CoreModels® holds the mappings and governed meaning between them. Ariesnet builds and operates the supply chain around it.
The mapping that settles a disagreement lives in the model, approved by the owner of each schema and recorded in a change log that says who changed what and when. Agents read the model through an MCP endpoint, so an answer traces to the model version it was read from, and a stale definition becomes a change-log entry instead of an incident.
Next step
Ariesnet draws the map in a thirty-minute interview about your schema landscape. The written map arrives within two business days and is yours whether or not you go further; a sample, for a fictional insurer, is published in these resources. Request an interview at ariesnet.com/interview.