Datos y fechas en conflicto

In a multi-agent research system, two subagents can return facts that flatly contradict each other. One source says a company has 8,000 employees; another says 12,000. The naive move is to silently pick one and report it as truth.

That is an anti-pattern. The architect-grade answer is to annotate the conflict and preserve both claims with their provenance, so a human (or a downstream model) can adjudicate. This lesson teaches how conflicting data is surfaced, and how dates often resolve apparent contradictions that look irreconcilable at first glance.

You cannot annotate a conflict you cannot trace. Provenance means keeping a claim → source mapping for every fact: the URL or document name, the exact quote, and crucially the publication date.

Without this mapping, a contradiction is just noise. With it, you can show the user precisely where each number came from and when it was published — the raw material for resolving disagreement.

The core rule: annotate conflicting stats rather than arbitrarily picking one. When sources disagree, the system should NOT collapse them into a single "winner" by coin-flip, recency-bias, or whichever subagent answered last.

Instead, render both claims side by side, each tagged with its source and date, and explicitly flag that they conflict. The model's job is to surface the disagreement with enough context that a human can decide — not to hide it.

Here is the key insight of this lesson: many "contradictions" are not contradictions at all — they are two correct snapshots from different points in time.

"Revenue is $4.2B" (FY2023) and "Revenue is $5.1B" (FY2025) do not conflict. They are both true, on their own dates. Once you attach publication and as-of dates to each claim, the apparent contradiction dissolves into a timeline. This is why the publication date is a first-class field in provenance.

To make conflict annotation reliable, force the model into a JSON Schema via tool_use. This eliminates syntax errors and enforces required fields. A conflict record should carry every claim with its value, source, and date — plus a resolution note.

Set tool_choice: "any" when you must guarantee structured output (the model must call some tool rather than reply with free text).

A subtle but exam-critical schema rule: mark a field required only if it is always present. If a source genuinely lacks a publication date, do NOT make published required — a required-but-absent field pushes the model to fabricate one, which silently destroys your date-based resolution.

In the conflict schema above, metric and claims are required; resolution and each claim's published date are optional. Better an honest null than a hallucinated date.

How you instruct the model matters. "Be careful with conflicting data" is vague and inconsistent. An explicit criterion is far stronger:

• "Flag two values as conflicting only when they describe the same metric for the same entity."
• "Before flagging, compare their as-of dates; if the dates differ, treat them as a time series, not a contradiction."

Explicit, testable criteria produce repeatable conflict detection. Vague adjectives do not.

Conflict-vs-timeline is exactly the kind of ambiguity where 2–4 targeted few-shot examples shine. The model generalizes from them — it doesn't just memorize the specific numbers.

Give one example of a genuine conflict (same date, different values → flag it) and one example of a date-resolved non-conflict (different dates → report as a timeline). The model learns the decision boundary and applies it to unseen metrics.

Long research runs get summarized to fit the context window — and progressive summarization makes numbers, percentages, and dates vague. "Published in early 2026" is useless when the whole resolution hinges on Q1 vs Q3.

The fix: pull transactional facts — exact values, sources, and dates — into a separate "case facts" block kept verbatim outside the summary. Summarize the prose; never summarize the dates you need to resolve conflicts.

To catch conflicts mechanically, have the model extract competing values explicitly rather than emitting a single blended figure. In extraction this is the calculated_total vs stated_total pattern; in research it is value-from-source-A vs value-from-source-B.

Once both are surfaced as distinct fields, a Pydantic-style validator can compare them, detect the mismatch, and trigger the conflict-annotation path — no silent averaging.

Once conflicts are annotated and dates reconciled, present the result so a human can adjudicate fast. Match the rendering to the content type:

• Tables for financials and competing numeric claims — one row per source, columns for value, source, and date.
• Prose for news and narrative context.
• Lists for technical findings.

A side-by-side table makes a same-date conflict jump out, and a date-ordered table reveals a timeline instantly — turning raw provenance into an oversight-ready view.

A research subagent returns: Source X says ARR is $40M (published Mar 2024); Source Y says ARR is $58M (published Feb 2026). Your aggregator must report this to the user. What is the correct architecture-grade behavior?

Key takeaways for conflicting data and provenance:

• Annotate, don't arbitrate — surface conflicting claims with sources; never silently pick one.
• Dates resolve apparent contradictions — different as-of dates mean a timeline, not a conflict.
• Provenance is mandatory — keep claim → source mappings with URL, quote, and publication date.
• Keep dates verbatim in a separate case-facts block; summarization makes dates vague.
• Don't require absent fields — an optional null date beats a fabricated one.
• Render by type — tables for numbers so conflicts and timelines are obvious to the human reviewer.