Our wiki says one thing and the code does another. Which does an AI agent believe?

An AI agent believes whichever version of the story reached its context window, and when your wiki and your code conflict, plain retrieval usually hands it the wiki. A page written in sentences matches a question written in sentences. A function body does not. The code is the fact of what runs today. The wiki is the record of what someone intended when they wrote it. A context engine is a service that indexes code, pull requests, chat, tickets and docs together, works out which source is current when they disagree, and returns an answer with its sources attached. It should show the conflict with dates and authors, prefer the newer reviewed source, and tell the engineer which one it used.

Why retrieval hands the agent the wiki#

Retrieval is the step that picks which documents go into the agent's context window before it answers, and it ranks by resemblance to the question. A wiki page resembles a question far better than source code does. A July 2026 benchmark of code search across 5,264 scientific repositories makes the gap concrete. The best embedding model reached a mean reciprocal rank of .76 when the query was a function's docstring and .18 when the query was the function's identifier (arXiv). In that experiment your wiki is the docstring and your config file is the identifier.

Once the page is in the window, the agent has no reason to doubt it. Anthropic's platform docs put it plainly: "more context isn't automatically better. As token count grows, accuracy and recall degrade" (Claude Platform Docs). A March 2026 study that padded question-answering prompts with irrelevant context found accuracy fell consistently as the context grew, and questions that need two facts joined together lost nearly twice as much as single-passage lookups (arXiv). "Which of these two is current" is a two-fact question, and an agent treats every retrieved chunk as true until something upstream rules otherwise.

A worked example: the timeout that moved#

We analyzed the questions buyers asked on our sales calls from May to October 2026, and seven companies asked some version of this one. Let's say the wiki page for your payments client reads "requests time out after 30 seconds". The engineer who built the client wrote it in 2024, and it was right. In June a latency incident led to a pull request that dropped the timeout to 8 seconds and added one retry. Two people reviewed it and it merged. Nobody edited the page.

Ask an agent "what is the payments client timeout" and three things can happen.

• Over the wiki alone it says 30 seconds.
• Over the repo alone it says 8 seconds and has no idea the page exists.
• With both in the window it may say either, or blend them into a sentence that is wrong in a new way.

None of the three tells you there was a disagreement.

What you want back is this: "The code sets 8 seconds with one retry (PR #4123, merged June 14, two reviewers). The wiki page says 30 seconds and was last edited in 2024. The code is current and the page is stale."

Recency and authorship are the tiebreakers#

When two sources disagree, the newer one with the stronger review trail wins, and the agent should say so. Recency alone is not enough, because a fresh page can be a wrong guess from someone who joined last month. Review is the tiebreaker on top of recency: a change two people approved and shipped outranks a page one person wrote.

The research is heading the same way. A paper at ACL 2026 names "outdated-document interference" as a cause of temporal hallucination. It adds a "Conflict-Aware Recency Filter" that arbitrates between factual versions and suppresses the obsolete ones, lifting generation accuracy by an average of 9.7% over the strongest baselines (ACL Anthology). In my experience that check lives in one tenured person's head, which is the problem I took apart in who decides what is true for AI agents.

Deprecate the stale page and keep it findable#

The old page is still evidence of what the team believed and when they stopped believing it. Delete it and the next agent that reads a 2024 Slack thread mentioning "the 30-second timeout" has nothing to reconcile against. Mark it superseded instead: a line at the top naming the PR that changed the behaviour, then archive the page so it drops out of everyday search. Confluence's archive, for example, "does not fully delete your content, it just changes access to the item", keeps archived pages out of quick search, and lets you restore them later (Atlassian Support). Then close the loop from the other end: a sentence in the PR description saying "supersedes the Payments client page" means the winning record points at the losing one. The tools that help here, such as verification badges and docs generated from code, are compared in tools that stop agents acting on stale documentation.

Show the source that won#

Every answer about behaviour should name its source and date. In the Stack Overflow 2026 survey, 93% of respondents called source attribution at least somewhat important when deciding whether to trust an AI-generated answer (Stack Overflow). An answer that says "8 seconds" with no link sends the engineer back to grep. An answer that says "8 seconds, per the merge on June 14, and the wiki disagrees" is finished.

Conflict detection is the answer-time check that two retrieved sources disagree about the same fact, with each one's date and author shown. Unblocked's documentation says it "reconciles information across sources, including sources that contradict each other". When an answer draws on a specific file or page, it lists that resource at the bottom, linked into the system it came from (Unblocked docs). In the timeout example that list carries both the pull request and the page, so the engineer sees which one the answer rested on. Pablo Vallejo, an engineering manager at Clio, put it this way. "LLMs are only as good as their context, and code alone gives them a narrow view — the codebase is always behind where the team wants to go. When I plugged Unblocked into our context-gathering and PR review steps, it brought in the Slack conversations where real architectural decisions get made. We went from three rounds of PR review to one before the code was production-ready."

So the agent believes whoever got to it first. Your job is to make sure that is the source that shipped, with the intended one beside it, labelled. Six tools that do and do not resolve conflicting information between docs, code and Slack are compared separately.