Golden Context vs Golden Record for AI Agents

What is a golden record, and why isn't it enough for an AI agent?

A golden record is the classic MDM output. Match the duplicate rows for "Jon Smith" and "Jonathan Smith," survive the best value for each field, and publish one clean row per entity. That row has served BI dashboards and case workers for twenty years. It answers one question well: what is true about this entity, right now.

An AI agent asks a harder question. Should I act on this? To answer that, a flat row is not enough. The agent needs to know how sure the match is, how fresh the data is, and whether it is even allowed to see the field it just read. CIO reported in June 2026 that a golden record can tell an agent a customer exists, where they live, and which account is theirs, but that alone will not let the agent make a sound decision. Reltio's Kevin Keenan put it directly in that piece: agents "need context about the enterprise they operate in," including which rules apply, how the record changed over time, and which actions are appropriate in the moment.

That gap has a name now.

What is golden context, and what does it add?

"Golden context" is the term a April 2026 Medium piece by Tahir Khan used to describe the shift from golden record to golden context for AI agent consumption. The pitch: a golden record is optimized for a human reading a screen. Golden context is optimized for a machine that has to reason and then act. An agent does not read a golden record, this framing argues. It reasons from it, so the record on its own is necessary but not sufficient.

Strip away the branding and golden context is four things bolted onto a golden record:

• Lineage. Which sources fed this value, and which one won.
• Quality axes. Not one quality score, several, because completeness and conformity fail for different reasons and an agent should know which one it is trusting.
• Consent basis. Whether anyone has the lawful right for this data to reach an agent at all, distinct from whether the data is merely accurate.
• Freshness. How old the record is relative to the decision the agent is about to make.

Hand an agent only the record and it can be confidently wrong. Hand it the record plus this context and it can tell you why it trusts an answer, or why it should not act yet.

How are Semarchy and Profisee answering the same problem?

Two MDM vendors are building toward the same idea, from different angles.

Semarchy's framing is a control plane. Its own post describes MCP and MDM together as "the governed layer that mediates between your AI agents and your enterprise data," arguing that MDM without MCP leaves trusted data unreachable by agents, and MCP without MDM gives agents fast access to data that may be wrong. Semarchy packages master data as "Intelligent Data Products": self-describing bundles that carry lineage, quality metrics and access controls alongside the record itself, queried through a semantic layer so an agent can ask for "the account status for customer X" in business terms rather than a schema name.

Profisee's framing is a wire. Its MCP Server gives Claude, Copilot and ChatGPT a governed bridge to matched, merged master data, with an audit trail on every call. The 2026.R2 press release extended that MCP surface across matching, connect and stewardship, and re-architected its Aisey agent as an orchestration layer over specialist agents.

Both are circling the same conclusion this piece and the golden context framing land on: a governed pipe to a clean record is not the same thing as proof the agent was allowed to see what came through it. That proof is the part worth building deliberately, not assuming.

The admission gate: how a record earns the right to become context

Ontology's answer is to stop treating "golden" as a permanent label and start treating it as a status a record has to re-earn every time an agent asks for it.

Every promoted golden carries a composite trust score across six named quality axes, with published weights and a per-axis floor, refreshed hourly. A record only reaches agent-ready status when the composite clears 0.70 and every individual axis clears its own floor, so one strong axis can't paper over one that's failing. That composite-plus-floor check and a fail-closed consent veto are enforced by one shared predicate, used by both the SQL path and the TypeScript path, so there is no second copy of the rule to drift out of sync. Consent itself runs on a lawful-basis substrate covering all six GDPR Article 6(1) bases across nine purposes, and the absence of a recorded basis is read as no, not yes.

None of that consent detail crosses into the agent's view, either. Only the derived consent score passes the masking boundary; the consent facts that produced it stay behind it. And golden reads for the AI paths come from versioned SQL views that mask personal data unconditionally, with the reader role holding no grant on the underlying table at all, so the mask can't be bypassed even from raw SQL. A release gate checks that the SQL views and the application read boundary mask byte-for-byte the same way, so there is one masking rule instead of two that might quietly diverge.

That is the mechanical difference between a golden record and golden context. The record is the same row it always was. What changed is that the row now carries its own passing grade, and nothing reaches the agent until it has one.

What an agent actually receives once a record clears the gate

Once a golden clears the gate, it reaches an agent through a small number of governed paths, not a raw table scan. golden_read returns the masked view plus a manifest of what got excluded and why, broken down by exclusion class, so the agent can tell a genuinely empty result from one that got filtered under its own consent or quality settings. The same masked golden joins against a Parquet or Postgres fact table in DuckDB, under a reader role that provably cannot select the base table underneath it, a claim checked by its own adversarial release gate. Grounding documents for retrieval are projected only from agent-ready goldens, rendered from the already-masked view, and a golden's chunks get hard-deleted the moment it drops back out of the gate.

The platform is candid about timing, too. Because the golden view is fed by a change stream, every mutating response discloses its own event lag, so an empty read right after a write reads as an expected gap in the pipe, not a lost update. An agent asking twice in quick succession can tell the difference between "nothing here" and "not landed yet," which is exactly the freshness signal the golden context framing says agents are missing today.

This is what "143 MCP commands for master data" is actually in service of: an agent can interview a business user, derive a spec, work a decision gate, generate a model, train it, run it through a battery, and promote it, end to end, with every one of those steps gated and reversible. The context is not a marketing wrapper glued onto the record afterward. It's produced by the same pipeline that built the record in the first place.

Related reading

Frequently asked questions