{"slug": "ai-agents-should-retrieve-facts-not-define-them", "title": "AI agents should retrieve facts, not define them", "summary": "AI agents that operate without human supervision should retrieve facts rather than define them, according to a first-person account of building an executive intelligence agent connected directly to a database, which produced untrustworthy numbers that drove up Jira ticket counts and missed adoption targets. The author describes a four-agent marketplace system that returned different answers to the same question across sessions because customer data lived in scattered, siloed APIs that disagreed; the fix was encoding reconciliation rules in business logic and loading one resolved value per field into a feature store before the agents saw the data. The account argues that human-in-the-loop verification is not an option for customer-facing agents whose recipients cannot check the answer, and that logic living in a prompt is subject to interpretation with no guarantee of repeatable outcomes.", "body_md": "I have made this mistake before. The goal was to create an executive intelligence agent: an artificial intelligence (AI) engine where C-suite executives could self-serve their analytics and pull trusted numbers for the board.\n\nThe promise was strong: personalized dashboards, ad hoc analyses, automated tasks and board decks, all from a single interface. Much faster than the status quo, and without a single new hire.\n\nSo, I did the reasonable thing and connected the AI directly to the database. It could query the data, build beautiful charts and refresh dashboards daily.\n\nIt was also useless, because the numbers it pulled could not be trusted. Analysts had to step in; Jira ticket counts went up rather than down and adoption never hit the target.\n\nAI agents reach into different systems to perform tasks in the real world. They query databases, call APIs and search documents. They resolve conflicts, interpret ambiguities and report a result. The most valuable agents do all this without human intervention.\n\nThat is also where the danger sits. Agents that work unsupervised must answer factual questions accurately. Whether in analytics, sales or customer service, facts are not subjective, and getting them right is where trust lives or dies.\n\nThis isn’t a hallucination problem. The agent isn’t fabricating an answer; it is making a decision about data that it never had the authority to make.\n\nHuman-in-the-loop (HIL) is when an AI agent’s output is verified by a human before it can be dispatched or act in the real world. HIL has become a standard framing for AI applications and a common [governance recommendation](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-14), particularly in regulated environments.\n\nHIL applications are often internal. They make teams more efficient, reduce cost and increase speed. Coding is a classic example, where engineers review, test and validate code before shipping it.\n\nBut there is a class of applications where HIL is not an option, and where trust matters most: a customer service agent answering questions about a customer’s account; an embedded analytics chatbot reporting ARR to a client; an executive intelligence agent putting a number in a board deck. The consequences of getting it wrong are real: a support ticket, a lost customer or a loss of credibility with the board.\n\nIn all three, the person receiving the answer cannot check it. And adding a human in the loop would undercut the value of the application in the first place.\n\nA supervised agent is allowed to be wrong because someone verifies the answer, corrects it and is accountable for it. An unsupervised agent is not.\n\nWe built a four-agent system that could act on behalf of a vendor and answer customer questions in a marketplace setting. The agents needed data about the vendor and customer to provide personalized answers. The system was unsupervised.\n\nBut the data came from scattered, siloed APIs. Something as simple as a customer’s address could live in several places, and those systems often disagreed.\n\nThe agents had to query multiple APIs and decide which value was correct. The result was unreliable: the same question could produce a different answer across sessions. Personalization was the entire value proposition, and it had become a liability.\n\nWhat fixed it was resolving the conflicts before the agents ever saw the data. We built business logic that reconciled the raw records and loaded the result into a feature store. The customer’s address, name and budget now had one value each. The agents stopped choosing, and the system became reliable.\n\nThat solution required real business decisions: reconciliation rules had to be encoded, and someone had to decide which system won for each field. No amount of prompting would have solved that. Logic that lives in a prompt is subject to interpretation, and there is no guarantee that the same inputs will produce the same outcome twice.\n\nFor a production system where trust matters, the answer has to be resolved once and reused, not regenerated on every request.\n\nThe same problem appeared in the unstructured data. Reviews and past customer conversations were stored in a vector database and retrieved through Retrieval-Augmented Generation or RAG. The data was rich and often contained what a customer needed, but multiple sources could disagree.\n\nSometimes the information was stale: venues move, parking information changes, transportation schedules do too. Other times what was right for one customer wasn’t right for another: instructions for someone arriving by plane are not the instructions for someone arriving by bus, and both are correct.\n\nAgain, the agent had to choose.\n\nSo, we built a retrieval tool that resolved the conflict before the agent saw the results. We ranked sources by whether the conversation was with the same customer, then the same region, then any customer, with recency weighted throughout.\n\nIt wasn’t sophisticated or guaranteed to be perfectly current or correct. It did something more fundamental: it removed unnecessary variability. The same question returned the same answer.\n\nThe agent stopped choosing.\n\nI ran an experiment to prove to myself I was right. The setup was simple: give LLMs increasingly complex business logic as context and see if they could accurately apply it to data. My hunch was that the more rules there were, the less likely they were to get it right.\n\nThe results were worse than I expected. Across nine models, from small to frontier LLMs, the top scores were 97% accuracy at five rules, 73% at fifteen and 43% at fifty. No single model dominated; bigger models did not always perform better, and the average was much lower than the top results.\n\nI was convinced: query generation would never be reliable enough in an unsupervised setting. Context cannot be [enforced](https://arxiv.org/abs/2606.03363); it is up for interpretation, and the bigger and more complex it becomes, the less likely the LLM is to follow it correctly.\n\nI needed a different approach. Rather than querying the database directly, the executive intelligence agent would query a semantic layer with clean, unambiguous definitions. The backend engine would then translate the metric query into SQL.\n\nWe added a Model Context Protocol (MCP) tool that constrained how the agent could query the metrics: metric names, dimensions, time frame and not much else. By constraining the retrieval, we removed the opportunity for the model to guess beyond what was defined.\n\nThis did the trick. Repeated questions about a metric returned the same result, and that result was the one the business had agreed on. The numbers could be trusted. Token consumption and latency were also much lower because answering a question no longer involved SQL generation.\n\nIt worked because the semantic layer did the resolution, not the agent. More correctly, a human resolved the metric definition and encoded it into the semantic layer, so the agent didn’t have to guess.\n\nWhen the data supports multiple answers, but only one of them is valid, the agent is forced to choose. That decision cannot be trusted: the agent does not have the authority to make it, it cannot be held accountable for it, and it cannot be audited afterward because its reasoning leaves no durable trace. Even a perfectly [deterministic LLM](https://thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference/) would produce a consistent answer that no one approved.\n\nThe easy answer is to supervise the agent with a human. This adds accountability, but also cost. Humans are slow and expensive, errors still pass through and the resolution logic remains in someone’s head rather than in the system. Worse, accountability often lands with the analyst, sales rep or revenue operator who reviewed the answer, rather than with the person who has the authority to define it.\n\nThe more durable answer is a resolution layer between the agent and the data that removes the need for a choice. A feature store reconciles conflicting systems into one value. A retrieval tool ranks sources according to rules someone wrote down. A semantic layer holds metric definitions behind a constrained set of tools the agent cannot route around.\n\nThe implementation varies. The principle does not: a human decides once, the system encodes the decision and the agent stops choosing.\n\nThis is hard not because of the infrastructure, but because it surfaces decisions someone with authority has to make. What counts as an active customer? Which system wins when two disagree? Which source takes precedence? Those answers belong to the business, not the agent.\n\nThere are decisions that can be safely delegated to an agent, others to a human and others that cannot be delegated at all. The skill is knowing which is which.", "url": "https://wpnews.pro/news/ai-agents-should-retrieve-facts-not-define-them", "canonical_source": "https://www.cio.com/article/4222914/ai-agents-should-retrieve-facts-not-define-them.html", "published_at": "2026-09-17 11:00:00+00:00", "updated_at": "2026-09-17 11:23:38.218975+00:00", "lang": "en", "topics": ["ai-agents", "artificial-intelligence", "ai-safety"], "entities": ["Jira"], "alternates": {"html": "https://wpnews.pro/news/ai-agents-should-retrieve-facts-not-define-them", "markdown": "https://wpnews.pro/news/ai-agents-should-retrieve-facts-not-define-them.md", "text": "https://wpnews.pro/news/ai-agents-should-retrieve-facts-not-define-them.txt", "jsonld": "https://wpnews.pro/news/ai-agents-should-retrieve-facts-not-define-them.jsonld"}}