Why AI Agents Join Data That Should Never Connect (And How to Stop It)

Niels Zeilemaker, global CTO at Xebia, recently named the real reason enterprise AI agents fail, and it is not the model. Speaking to AI News, he warned that an agent "will join different fields together in your data which should never be connected," and that "these mistakes are not the fault of the agent. It’s the fault of your foundation."

The data backs him up. Xebia’s Data & AI Monitor 2025/26, a survey of more than 500 data and AI decision-makers across Europe, the US, the Middle East, and Africa, found that fewer than 20 percent of organizations rate their data foundation as "highly mature." While 82 percent accelerated AI experimentation in the past year, only 14 percent believe their data architecture is ready to support AI at scale.

Of all the ways a weak foundation breaks an agent, one is uniquely dangerous, and it is the one worth taking apart in detail: the silent join. Not the agent that fails loudly and returns an error. The agent that confidently fuses two unrelated things and hands you an answer that looks perfectly reasonable and is completely wrong.

The failure nobody catches

Most agent failures announce themselves. The agent times out, returns nothing, or says something obviously off. Those are cheap, because you can see them.

The silent join is expensive precisely because it is invisible. The agent retrieves real data, reasons over it correctly, and produces a fluent, plausible answer. The only problem is that two of the facts it combined describe different things in the real world. Nothing in the output signals the contamination. It passes review. It ships. It is wrong.

Here is the shape of it.

Imagine a company with two contracts both nicknamed "Helios" internally. One is a vendor agreement under a US subsidiary. The other is a client agreement under a EU entity, governed by different law, with different termination terms. To a human, these are obviously separate. To a vector retrieval layer, they are nearly identical: same nickname, same contract vocabulary, same semantic neighborhood.

An agent is asked: "What are the termination terms for Helios?"

The retriever returns its top matches by similarity. The termination passages from both contracts score high, because both are textually about "Helios" and "termination." The agent receives a mixed bag of passages, has no signal that they come from two different legal entities, and writes one coherent answer that blends a US clause with an EU clause.

The answer reads beautifully. It is also a contract summary that describes no real contract that exists.

Why vector retrieval cannot prevent this

This is not a tuning problem. It is structural.

A vector database stores meaning as proximity in an embedding space. It is built to answer "find me text similar to this," and it is excellent at that. What it has no concept of is identity. It does not know that Helios-the-vendor-agreement and Helios-the-client-agreement are two distinct entities that must never share a sentence. To the index, they are two nearby points, and "nearby" is exactly what it is designed to return together.

You can raise the similarity threshold, add re-ranking, or shrink the chunk size. None of it fixes the root cause, because the root cause is that the system has no model of which things are allowed to connect. Similarity is not identity, and an agent built only on similarity will keep stitching distinct entities together whenever they happen to look alike.

The structure that makes the bad join impossible

A knowledge graph stores meaning differently. It stores explicit, typed relationships between resolved entities. The connections an agent is permitted to make are the connections you declared, and nothing else.

In graph form, the two Helios contracts become two separate nodes with distinct identities. One node, Contract {id: "C-4471", alias: "Helios"}, links by an :UNDER edge to entity US-Sub. The other, Contract {id: "C-8830", alias: "Helios"}, links to EU-Sub. Each contract connects to its own termination clause through a :HAS_CLAUSE edge, so the two contracts own separate, non-overlapping clauses.

Now the same question runs as a traversal, not a similarity search. The alias "Helios" resolves to a set of candidate nodes, and the agent must commit to one identity before it can retrieve anything. The query matches a contract by its resolved id, follows only that single node’s :HAS_CLAUSE edges, and returns the termination clause for that one contract.

Because retrieval is scoped to a single resolved node, the termination clause of C-4471 can never be returned alongside the clause of C-8830. The blend is not unlikely. It is structurally impossible. If the alias is ambiguous, the graph forces the system to disambiguate or ask, which is the human fallback Zeilemaker says agents lack, rebuilt into the data layer itself.

The part the news report skips: this is not free

It would be dishonest to stop at "use a graph and you are safe." The hard problem just moves.

A knowledge graph is only as trustworthy as its entity resolution. If your graph construction wrongly merges the two Helios contracts into one node, you have not solved the silent join. You have hard-coded it. The failure shifts from query time to build time, where it is harder to spot and affects every query after.

This is why the real engineering work sits in the construction pipeline, not the query. You need entity resolution that knows C-4471 and C-8830 are distinct despite the shared alias, and a mislink-detection pass that catches bad merges after the fact. We covered that exact problem, disambiguating entities and then detecting mislinks after creation, in Gemini-Driven Entity Disambiguation With Post-Creation Mislink Detection.

It also means a graph is not always the answer. If your domain has a single entity type and no cross-entity joins to worry about, vector retrieval alone is simpler and fine. The graph earns its cost the moment you have multiple entities that can be confused for one another, relational questions, or compliance boundaries that must not be crossed. In most real systems the right answer is hybrid: vector search for recall, a graph constraint for identity. We walked through that combination in Hybrid Retrieval With Prefetch-Time Metadata Filtering.

How to find out if your agent is doing this right now

The silent join hides, so you have to go looking. A practical audit:

1. Build an ambiguity test set. List the entities in your domain that share names, codes, or aliases: duplicate customer names, reused contract numbers, project codenames that recur. These are your collision points.
2. Query each one and inspect the retrieved sources, not just the answer. The answer will look fine. Check whether the retrieved chunks all trace to a single real-world entity. If a single query pulls passages from two distinct entities, you have found a live silent join.
3. Log provenance on every retrieved chunk. If you cannot tell which source entity a passage came from, neither can your agent, and neither can you when you audit it.
4. Ground the output against a controlled identity, not just plausibility. Validating answers against a domain source at runtime catches contamination the model would otherwise smooth over, the approach in Anti-Hallucination via Runtime Grounding Against a Domain Vocabulary.

The headline from the Xebia research is correct: when your agents fail, look at the foundation first. We would add one line. The failures that cost the most are rarely the loud ones. They are the silent joins that read perfectly and connect two things your business never meant to connect. Fixing the model will never catch those. Only the structure of your data foundation can.

Cognilium AI has shipped 50+ projects and runs four production AI systems built on this foundation: graph-backed retrieval, entity resolution with mislink detection, and runtime grounding. If you suspect your agents are quietly fusing data that should stay separate, Talk to an Engineer, and we will run the ambiguity audit with you.