Your Agent Retrieved The Wrong John Smith
Retrieval-augmented generation finds text that looks similar to the question. People and companies are not text: two customers can share a name, and one customer can appear under five spellings. So the agent pulls in a stranger’s records and misses some of the right customer’s.
The agent quotes a stranger’s order and never sees the one that belongs to this customer.
Similar Is Not The Same
A retrieval pipeline embeds the question, finds the nearest chunks and hands them to the model. That works for documents. It fails for entities, because nearness in embedding space is about wording, not identity. “John Smith in Portland” and “John Smith in Austin” are close. “Jon Smith” with the same email and address as “John Smith” may not be.
So the agent gets two kinds of wrong context. It mixes in records about a different person who happens to look similar, and it misses records about the right person that were written differently. Neither error is visible in the answer: the model writes fluently either way. In customer support that means quoting someone else’s order. In financial services or healthcare it means disclosing data about the wrong person.
Prompting cannot fix this, and neither can a bigger context window. The retrieval step needs to know which records belong to the same real-world entity before it searches.
Strangers In The Context
Records about a different customer with a similar name are retrieved and blended into the answer.
Half The History
Records about the right customer that use another spelling, email or address are never retrieved.
Confident And Wrong
The model has no way to tell. It answers fluently on the wrong facts, and the error looks like a correct answer.
Resolve Entities Before Retrieval
Make identity a step in the pipeline instead of a guess the model makes. Match the records about each person or company across your sources, give every entity one stable ID, and store that ID with every record and chunk you index.
At question time, resolve who the question is about first, then retrieve only what carries that ID. The context is complete, because every spelling is attached to the same entity, and clean, because nobody else’s records carry it.
The other John Smith, in Austin, keeps his own ZINGG_ID and never shows up in this answer.
Look Up The Entity First
Turn “J. Smith from Portland” into one entity before any search runs.
Key Everything By Entity
Every record, chunk and event carries the entity’s ID, whatever its spelling.
Scope What Agents See
Retrieval is filtered to one entity, so an agent cannot see another customer’s data by accident.
The Identity Layer Under AI & Data
Zingg runs as a workload inside your data platform and gives every entity one persistent ZINGG_ID. Everything above it reads the same resolved entities.
The same layer powersCustomer Analytics & MarketingFinancial Crime & RiskPrivacy & ComplianceSupply Chain & ProcurementProduct 360Master Data Management
Resolve First, Then Retrieve
One ZINGG_ID Per Entity
Zingg matches records across your systems and gives each person or company a persistent ZINGG_ID.
Retrieve By ID, Not By Name
Store the ZINGG_ID with every record and chunk. The agent looks up the ID once, then retrieves only what belongs to that entity.
Show Why Records Belong
Every link has evidence behind it, so you can audit what the agent was allowed to see. Explainability
Stay Current
As new records arrive, the incremental flow attaches them to the right ZINGG_ID without a full rerun.
Identity RAG Questions
What is identity RAG?
Retrieval-augmented generation that resolves people, companies and other entities before retrieving. Records are keyed by a persistent ZINGG_ID, so retrieval returns everything about the right entity and nothing about lookalikes.
Does Zingg replace my vector database?
No. Zingg resolves identities inside your data platform and adds a ZINGG_ID to your records. Your vector store, search index or graph keeps doing retrieval, now filtered or joined on that ID.
Why not let the LLM work out who is who?
The model only sees what retrieval hands it. If the context mixes two people, or misses records written differently, the model cannot recover what it never received.
Where does the matching run?
Inside your data platform: Databricks, Snowflake, Microsoft Fabric, Google Cloud or AWS. Your data does not leave your account.
Give Your Agents The Right Entity
Resolve identities in your own data platform and retrieve on one ZINGG_ID.