Why AI agents hallucinate about businesses

An agent asked to verify a business will answer. Whether the answer is right depends far less on the model than on what the model was able to retrieve, and business identity is unusually hostile to retrieval.

Four properties make it hard. A business is fragmented across sources, its state changes continuously, the entity presented is often not the entity that carries the risk, and its name may not be unique.

A landscaping company incorporated as GTL Services LLC in Delaware may operate publicly as Green Thumb Landscaping. Both are real, both are correct, and neither is a key that joins to the other.

Personal identity has stable identifiers. Business identity does not — which is why matching, rather than lookup, is the fundamental operation.

Entities dissolve, change beneficial owners, move registered address, have licences suspended, appear on sanctions lists, and rebrand. An agent reading cached or aggregated data reports a historical state as though it were current.

This is the failure that reads best and is worst: the output is fluent, specific, and wrong.

An agent can confirm that GTL Services LLC exists and is in good standing while missing that its ultimate beneficial owner is connected to three dissolved entities. Nothing it reported was false. The material fact was one layer up.

Wrong-entity match: the application is matched to a different business with a similar name or address. The result looks clean, because the matched entity really is active and legitimate — just not the applicant.

Stale-state error: a dissolved entity is reported as active, or a newly added sanctions exposure is not flagged.

Ownership blindspot: the presented entity is verified accurately, while a parent in a high-risk jurisdiction, a beneficial owner listed under a different name, or a circular structure obscuring control goes unsurfaced.

A usable identity layer distinguishes what it knows from where it learned it. Three tiers, in descending order of authority:

Provenance is not a footnote. An answer that cannot say which tier it came from cannot be gated on.

Refreshing everything on one schedule is either wasteful or wrong. Volatility differs by field, and the cadence should follow it:

Freshness metadata should be surfaced to the agent, not just the value. An agent that cannot see how old a fact is cannot reason about whether to trust it.

Retrieve through tool calls rather than model weights. Pre-trained knowledge about a specific business is stale by construction.

Resolve the entity explicitly before retrieving facts about it, and attach a confidence score to that resolution.

Gate routing on confidence: high-confidence matches proceed automatically, low-confidence ones escalate to a person. Entity resolution is probabilistic, and a system that hides that forces a binary decision on an uncertain input.

Traverse ownership by default rather than on request, because the risk is frequently one layer above the entity presented.

What is the documented source hierarchy for each data type? What is the refresh cadence for entity status, ownership and officer data? Is freshness metadata exposed at field level?

Does the API return confidence scores for entity resolution? Does the data model support ownership traversal? What is the latency profile under concurrent agent workloads, and how are low-confidence results surfaced for escalation?