Your agent calls a CRM to check a customer's subscription status. The CRM says active. Then it calls your billing system to confirm the renewal date. The billing system says the account was suspended two weeks ago.
Both tools are authoritative. Both are returning real data. They contradict each other.
What does the agent do?
If you didn't build explicit conflict-resolution logic — and most teams don't — the agent picks one. Quietly. It doesn't surface the conflict. It doesn't flag the inconsistency to the user. It just continues reasoning from one of the two answers, and the other answer disappears from the output.
Which one does it pick? Usually the one that appeared most recently in context, or the one that fits the narrative direction of its current reasoning. Neither is a principled choice.
Why conflicts happen more than you think
Eventual consistency. Modern systems are distributed. Your CRM, your billing system, your warehouse, your cache — they're not the same database. They sync on a schedule. When something changes in one system, it takes time to propagate to the others.
During that propagation window, different systems hold different values for the same entity. An agent that calls three systems for data about a customer will sometimes get three consistent answers. And sometimes it will get answers that diverge because one system saw the update and the others haven't yet.
Stale data. Caches don't always invalidate properly. Batch syncs run on a schedule. An agent calling a cached endpoint for data that changed since the last sync will get stale data alongside fresh data from an uncached endpoint.
Conflicting sources of truth. Many organizations have multiple systems that should be in sync but aren't, for business reasons. The sales team uses a CRM with slightly different customer records than the finance team's billing system. Both are "correct" for their respective purposes. An agent that needs a unified view gets a fragmented one.
Race conditions. Two operations happen near-simultaneously. One agent session updates a record. Another agent session reads the record before the write propagates. The read returns the pre-update value. Both the "old" and "new" values are real data — they just reflect different moments in time.
The silent resolution
Here's what usually happens when an agent encounters conflicting tool outputs:
The agent gets response A from tool one. It continues reasoning. It gets response B from tool two, which contradicts A. The model processes both signals simultaneously and produces output that reflects one of them — typically the more recent one, or the one that creates a more coherent narrative, or the one that's consistent with any prior context that's been established.
It doesn't say "I got conflicting information from these two tools." It doesn't flag the inconsistency. It doesn't ask which source to trust. It just... picks one. And the user gets an answer that looks authoritative but is actually the product of an unacknowledged conflict.
If the wrong answer was picked, the user discovers this later. The agent had everything it needed to flag the problem. It just wasn't designed to.
What the agent should do
Surface conflicts explicitly. When two tool responses contradict each other on a significant data point, the agent should surface the conflict rather than silently resolve it. "I got conflicting information: the CRM shows the account as active, but the billing system shows it as suspended. Which system should I treat as authoritative?"
Use explicit precedence rules. For common conflict types, encode a resolution rule. Billing system wins over CRM on subscription status. Most recent write timestamp wins on record data. The rule should be explicit, in the system prompt or in a configuration the agent can reference, not something the model infers.
Reduce the surface area. Where possible, call a single authoritative system for each type of data rather than multiple systems. If there's one system that definitively owns subscription status, call that one, not three systems that might have it.
Treat conflicts as signals. A conflict between two authoritative systems is often a sign that something went wrong: a failed sync, a race condition, a data integrity problem. The conflict itself is valuable information. Surface it, don't suppress it.
Faultmap identifies the tool pairings in your agent's tool graph that are likely to return conflicting data. It maps which tools access overlapping data domains, simulates consistency gap scenarios, and checks whether your agent's conflict handling surfaces or silently resolves disagreements.
The agent that picks one answer and moves on isn't broken. It's doing what it was designed to do: produce an answer. The problem is that no one told it what to do when the tools disagree. That's a design gap. Fill it before users discover it.