Questions an AI-platform lead asks

Because the definitions the agent depends on disagree across the systems it reads. One system's 'customer' is another's 'policyholder'; a field carries a different grain in the warehouse than in the application that wrote it; a definition changed at the source and the copy the agent reads did not. The agent then calls the wrong tool, reads the wrong field, or acts on a stale definition, and produces a fluent answer that is wrong. A more capable model does not resolve a disagreement between two schemas. A mapping does, with an owner and a record of when it changed.

It is the path your content travels from the system that holds it to the answer an agent gives — sources, structure, semantics, validation, retrieval, agent operations, and the learning loop. Treating it as a supply chain rather than a search problem is what makes the failures locatable: a bad answer traces to a specific stage.

Because a stronger model reasons more capably over whatever it was handed. If retrieval returned a superseded policy document, a better model will argue for the superseded policy more persuasively. Model upgrades raise the ceiling on good context; they do not raise the floor on bad context.

Thirty minutes on your schema landscape — optional parts can extend it to forty-five — and within two business days a written map: the systems that hold structure and meaning today, the connectors your agents need, where two systems disagree and what that is costing, and remediation options ranked, with the parts you can do yourself marked as such. The map is yours whether or not you go further, and there is no rung to buy first. A non-disclosure agreement is available on request before the interview.

The interview, then a written fixed-scope fixed-fee proposal. We recommend starting at the Agent Context Cost & Failure Audit — it is approvable without a steering committee. Nothing requires you to enter at the bottom of the ladder — a Diagnostic Briefing within ten days of the interview is common when the funding decision is contested.

The disagreement is resolved as a mapping in the Core Model, approved by the owner of each schema, and recorded in the change log with who changed what and when. Agents read the model through the MCP endpoint, so an answer traces to the model version it was read from. Version history is a Team and Enterprise feature on coremodels.io; with it in place, yesterday's version is read back, and the answer with it.

The owner of each schema agrees the mapping in the Core Model; that agreement is the freeze, and the change log records who changed what and when. Until it exists, the behaviour at the boundary — whether an agent refuses the answer or returns it with a warning — is set by the conformance contract written into your engagement, not by the platform. The platform publishes no refuse-or-warn default; the engagement sets it. On Managed Operations, every refusal is logged and carried into the incident attribution an auditor receives. Refuse is the default; warn is enabled only for non-binding internal use, every warned answer is labelled non-authoritative, and that configuration is signed off by your named control owner — never by a vendor default and never by a merge.

The change log, showing who changed what and when. The exported conformance contract in force at the time. The mapping the answer depended on, and who approved it. And, on Managed Operations' Ops + Eval, the incident attribution: whether the failure was in the context, the model or the application.

Every refuse or warn decision is a record with named fields: who approved the mapping and when, the timestamped freeze record tied to the contested mapping id, who ran the check, the agent or workflow id that asked and a hash of the input it sent, the UTC timestamp, the Core Model project with its schema version and the element version in force, the ShEx shape and the mapping it failed, the check that fired and its reason code, and the answer that was refused or warned. Records are retained for the period set in your engagement letter, alongside your other audit artefacts. Your named control owner, and anyone they authorize, can export the pack as JSON at any time.

What is deterministic is the decision, not the prose: for a given contract version and mapping, the same input produces the same refuse or the same warn every time. Your evals assert that decision, not the prose. A generated answer is not reproducible word for word, which is why the boundary, not the model, is what you audit. The engagement maps each boundary check to a control in the framework you already report against — BCBS 239, Solvency II, IFRS 17 and 21 CFR Part 11 are the shapes it takes most often.

When an agent answer becomes a finding, that pack — the refuse or warn record, the approved mapping and the contract version in force — is what your auditors receive, and because the decision is deterministic they can re-run it without us in the room.

Access is limited to what the engagement requires. Data handling, retention, and return or destruction are defined in the engagement letter and any required data-processing addendum. Client systems are not modified beyond the agreed scope.