Do not make the analytics agent decide which customer is real

An analytics agent can have permission to query every relevant system and still lack the answer to a more basic question: which records describe the same customer, supplier or product? Ataccama’s September 23 architecture note argues that this identity problem should be resolved before an agent reasons over the data—not delegated to the model at query time.

Access is not identity

The post uses a common enterprise pattern: one supplier may have different identifiers and attributes in procurement and finance. Each record can be valid inside its source system while the collection still fails to establish one authoritative entity. Ataccama’s proposed boundary is clear: master-data management should match, link and reconcile those fragments into a governed master entity before an AI application uses them (source).

That distinction matters for text-to-SQL systems. Schema access can tell an agent where records live, but it cannot by itself establish whether two rows refer to the same real-world entity or which conflicting attribute should prevail. Ataccama argues that letting a model infer those relationships independently makes authoritative decisions harder to reproduce and audit, especially when downstream systems reuse the mastered record (source).

Use MCP as a delivery boundary

Ataccama positions the Model Context Protocol as a controlled retrieval mechanism rather than the source of truth. Its design exposes selected master-data capabilities as scoped tools, allowing an agent to request governed entity information without receiving broad database access. The returned context can include the mastered record alongside quality, governance, metadata and lineage information that explains why it should be trusted (source).

For implementers, that suggests a useful separation of responsibilities:

• resolve identity and conflicting source records in the mastering process;
• validate and cleanse records while the authoritative representation is constructed;
• expose only the required master-data operations to the agent through scoped tools;
• deliver provenance and quality context with the entity, rather than only its current values.

Those steps reflect Ataccama’s proposed architecture, not an independently measured deployment result. The post describes product capabilities and a design boundary, but it does not publish an accuracy comparison, latency measurement or production incident rate for the approach (source).

The practical takeaway is narrower than “add more context.” Before tuning prompts or widening warehouse access, teams should decide where entity identity becomes authoritative. If that decision is still being improvised inside the agent, the system is asking probabilistic reasoning to perform a governance function that the cited architecture deliberately keeps upstream.