One of the most memorable moments at the AHTD Association for High Technology Distribution Spring Meeting last week came during Dan Chuparkoff's session on AI and the future of automation distribution. The slide on the screen read: "When are we going to fix AI's hallucination bug?" But Chuparkoff was not framing it as a criticism of AI vendors and models. He was making a more important point: hallucinations are not a bug. They are a feature. And until our industry truly internalizes that, we are going to keep making the wrong bets on AI implementation.
What is actually happening inside an LLM
Large language models do not retrieve facts the way a search engine does. They generate responses by predicting the most statistically probable next word, given everything that came before it in the conversation. They are optimized for fluency and coherence, and they are extraordinarily good at both. The problem is that fluency and factual accuracy are two different things, and LLMs are fundamentally built around the former.
Language models are not built to be encyclopedias or databases of facts. Instead, they are designed to model the way humans use language. When it comes to factual accuracy, these models can only work when likelihood and truth align. If there is a gap in their knowledge, they will fill it in with whatever is most likely, regardless of whether it is true.
This is not a temporary limitation waiting to be patched in the next model release. A formal analysis published in 2024 and updated in early 2025 demonstrates mathematically that LLMs cannot learn all computable functions and will therefore inevitably hallucinate if used as general problem solvers. A letter published in Nature in March 2025 echoed the same conclusion, arguing that AI confabulations are integral to how these models work: a feature, not a bug. Even OpenAI, in its own published research, acknowledges that hallucinations remain a fundamental challenge for all large language models, and that current evaluation methods set the wrong incentives by encouraging guessing rather than honesty about uncertainty.
So the question is not when we are going to fix it. The question is: how do we build around it?
Why this matters so much in industrial distribution
In a general consumer context, a hallucination is an inconvenience. You ask a chatbot about a hotel and it gives you slightly wrong hours. You verify. You move on.
In industrial distribution, the stakes are different. Ask an AI assistant to recommend a drive configuration for a specific motor load and environmental rating, and it will give you a confident, technically fluent answer. It will use the right terminology. It will reference real product families. And it may still give you the wrong configuration; not because it is broken, but because it is doing exactly what it was designed to do: generate the most plausible response based on patterns from its training data.
Think about what that means in practice. Fieldbus module compatibility that depends on specific firmware revision numbers. Motor protection relays where two nearly identical part numbers determine whether a machine shuts down safely or does not. Drive parameter sets that change based on installation environment in ways that are not obvious from the product name alone. These are not edge cases. They are the daily reality of technical sales in our industry. A wrong recommendation does not just create a bad customer experience. It erodes trust with an engineer who will remember it, delays a project that someone is accountable for, and in some cases creates real downstream consequences on the plant floor.
"Just throw everything into a RAG" is not the answer
A common response in the industry right now is: "We have Copilot in our company. I'll connect the LLM to our product catalog and datasheets using RAG." RAG stands for Retrieval-Augmented Generation, and the basic idea is sound: instead of relying on what the model was trained on, you retrieve relevant documents from your own data sources and feed them to the model before it generates an answer. It is an "open book" approach. The model reads before it writes.
But naive RAG is not a solution. It is a starting point that quickly reveals its own limits when applied to the complexity of real industrial product data.
The first problem is how RAG actually retrieves information. Standard implementations convert your documents into numerical vectors and retrieve whichever chunks are closest to the incoming query. This is great for finding concepts but catastrophic for finding specifics. A standard vector search might return the wrong data entirely because the semantic distance between similar terms is negligible to an embedding model, even when that difference is the difference between a correct answer and a hallucination.
For industrial product data, this is a serious problem. A query about a gateway module with a specific protocol variant will semantically resemble dozens of other gateway datasheets from the same manufacturer. The model retrieves the closest matches, which may be the right product family but the wrong configuration. It then generates a response that sounds authoritative and is built on the wrong foundation.
The second problem is the nature of industrial product knowledge itself. Standard RAG frameworks may misinterpret or hallucinate meanings for specialized terms not present in their training data. Industrial catalogs are not written for AI consumption. They contain tables, part number matrices, conditional compatibility rules, dimensional drawings, revision histories, and cross-references across dozens of product families. Splitting that content into text chunks and embedding it into a vector database destroys the relational structure that makes the information meaningful in the first place.
The third problem is that the LLM is still generating the final answer. Even with retrieved context, hallucinations emerge when the model assigns higher probability to an incorrect or ungrounded generation sequence compared to a factually grounded alternative. Feeding a model better documents reduces hallucination. It does not eliminate it, especially when the query requires reasoning across multiple constraints simultaneously.
Research published through 2024 and 2025 identified at least seven distinct failure points in RAG systems spanning retrieval quality, chunking strategy, context length, reranking, and the model's own tendency to confabulate when retrieved content is ambiguous or incomplete. Enterprise AI teams have spent significant resources discovering these failure points the hard way.
"But AI agents are already writing complex code reliably, won't that solve this too?"
It is a fair question, and if you have used Claude Code or similar tools recently, you have probably asked some version of it. Claude Code is now authoring roughly 4% of all commits on GitHub, and in a February 2026 survey of 15,000 developers it was rated the most loved developer tool at 46%. The capability is real. So why would the same trajectory of progress not eventually solve the hallucination problem in industrial product knowledge?
The answer comes down to one word: verifiability.
When an AI agent writes code, there is an immediate, deterministic ground truth check available. The code either compiles or it does not. The tests either pass or they do not. Claude Code runs tests and iterates on failures automatically. When tests fail, it reads the errors, fixes the code, and runs the suite again until everything passes. The feedback loop is tight, automated, and unambiguous. Hallucinations in code get caught and corrected within the same session, often before a human ever sees them.
Industrial product knowledge has no equivalent feedback loop. If an AI agent recommends the wrong drive configuration, there is no compiler to catch it. The error surfaces weeks later when a part arrives at a facility and is incompatible, or it never surfaces at all because the engineer trusted the confident answer and moved on. The stakes and the verification structure are fundamentally different.
And here is the irony worth noting: even in software, where the feedback loop is as clean as it gets, the best AI coding agents in early 2026 resolve real-world engineering tasks at around 80% accuracy on verified benchmarks. Independent analysis shows that success rates drop sharply for multi-step tasks, with failure rates often in the 60% to 80% range for execution-heavy scenarios. This is the state of the art in a domain purpose-built for automated verification. The hallucination problem has not been solved for code. It has been managed through feedback loops. Industrial distribution does not have those feedback loops built in.
There is a second, equally important distinction. Coding agents work well because programming languages are universal and public. The reasoning Claude Code applies to a Python repository in San Francisco generalizes to a Python repository in Tokyo. But no frontier model will ever be trained on the compatibility workarounds your applications engineers have learned the hard way across hundreds of customer installs, the configuration logic that lives in the heads of your top two technical sales reps and nowhere else, or the product relationships and exceptions buried across thousands of datasheets that no one has ever fully mapped. That knowledge is proprietary, relational and constantly updated.
What actually works: structured knowledge grounding
The answer is not to give up on AI in industrial distribution. The answer is to stop treating the LLM as the source of truth and start treating it as a reasoning engine that needs a proper knowledge substrate beneath it, and a purpose-built tool harness that connects it to that knowledge reliably.
This means building a layer that represents your product knowledge not as flat text chunks but as structured, relational knowledge: part numbers with explicit attributes, compatibility rules encoded as relationships, configuration logic that mirrors how your technical experts actually think, and version-aware data that knows the difference between two nearly identical part numbers that behave completely differently in the field. Practitioners building serious agentic systems increasingly recognize that the quality of what an agent can do is bounded by the quality of the tools it has access to. A general LLM with no harness is a conversation engine. An agent with a well-engineered harness built on a purpose-built knowledge layer is an expert system. The harness is not just an API connection. It is a set of stable, pre-constructed interfaces that the agent can call to traverse relationships, validate compatibility, find alternatives, check specifications, and retrieve live inventory.
Critically, that knowledge layer needs to be constructed at build time, not assembled on the fly when a customer asks a question. The difference matters enormously. A system that scrambles to retrieve and interpret documentation at query time is inherently fragile and imprecise. A system that pre-constructs a verified, structured knowledge layer and exposes it to the AI through a purpose-built tool harness is stable, reliable, and fast.
When an AI agent draws from that kind of knowledge layer through a properly engineered harness, accuracy improves dramatically. Not because the LLM became smarter, but because it is no longer guessing. It is reasoning over verified, structured facts with the right tools to do so reliably every time.
What this looks like in practice
At ReshapeX, this is exactly the architecture we build. Rather than connecting an LLM directly to a flat document store, we construct a knowledge grounding layer using a graph-based structure that maps the relationships between products, configurations, specs, and compatibility rules the way a seasoned applications engineer would understand them. The grounding layer operates through a purpose-built tool harness generated directly from what we call the Knowledge Construction System. Rather than maintaining fragile direct integrations to brand APIs or relying on stale text chunks parsed from PDFs, the harness gives the grounding layer stable, reliable tools: traversing the knowledge graph for compatibility relationships and replacement chains, querying structured relational data for what official manufacturer sources explicitly declare, using semantic search for vague or exploratory queries, validating whether components work together, finding alternatives for discontinued parts, and retrieving live inventory and pricing.
The knowledge layer is not a one-time build. A continuous sync mechanism keeps it current as manufacturer APIs update, new catalogs arrive, and products change their lifecycle status. The harness tools remain stable even as the underlying knowledge evolves, because the construction happens at build time, not at the moment a customer asks a question.
That architectural difference is what takes accuracy from the roughly 80% ceiling you get with standard approaches to the kind of reliability that industrial distribution actually requires. The hallucination problem is not going away on its own. But it can be engineered around, with the right knowledge layer, the right harness, and a team that understands both the AI architecture and the industrial domain deeply enough to build them correctly.
References
[1] Xu, Z., Jiang, F., Niu, L., Sha, F., & Riezler, S. (2024, updated February 2025). Hallucination is Inevitable: An Innate Limitation of Large Language Models. arXiv:2401.11817. https://arxiv.org/abs/2401.11817
[2] Dumit, J. et al. (2025, March). AI hallucinations are a feature of LLM design, not a bug. Nature, 639(8053), 38. https://doi.org/10.1038/d41586-025-00662-7
[3] OpenAI. (2025). Why language models hallucinate. https://openai.com/index/why-language-models-hallucinate/
[4] Anh-Hoang, Tran, & Nguyen. (2025). Survey and analysis of hallucinations in large language models: attribution to prompting strategies or model behavior. Frontiers in Artificial Intelligence. https://pmc.ncbi.nlm.nih.gov/articles/PMC12518350/
[5] Barnett, S., Kurniawan, S., Thudumu, S., Brannelly, Z., & Abdelrazek, M. (2024). Seven Failure Points When Engineering a Retrieval Augmented Generation System. Proceedings of the 3rd International Conference on AI Engineering — Software Engineering for AI. https://arxiv.org/html/2401.05856v1
[6] Dev Community / Neuriflux. (2026, April). Claude Code is reshaping software engineering in 2026. https://dev.to/hamza_a_1dba9c327788c448f/claude-code-is-reshaping-software-engineering-in-2026-4ljf
[7] Neuriflux. (2026). Claude Code Review 2026: The Tool That Flipped the Dev Market in 8 Months. https://neuriflux.com/en/blog/claude-code-review-2026
[8] Anthropic. (2026). Claude Code. https://www.anthropic.com/product/claude-code
[9] ComputingForGeeks. (2026). OpenCode vs Claude Code vs Cursor: AI Coding Agents Compared. https://computingforgeeks.com/opencode-vs-claude-code-vs-cursor/
[10] InfoWorld. (2026, April). Enterprise developers question Claude Code's reliability for complex engineering. https://www.infoworld.com/article/4154973/enterprise-developers-question-claude-codes-reliability-for-complex-engineering.html