In the second article of this series, I retired the query router and made retrieval a fixed, fused pipeline where every question runs hybrid search and typed graph traversal. The union is reranked once with the relationship paths visible, and the grounded bundle carries those paths as evidence. I deployed it on Azure next to the first article's stack, ran the same synthetic insurance corpus through it, and measured what changed. Entity fragmentation dropped from 149 machine-extracted concepts to 120 on identical documents. The contradiction detector fired during the seed without being asked. The system now walks its own graph.
What it still cannot do is decide that one walk was not enough.
That sentence is the whole reason this third article exists, so let me be precise about it. The pipeline I built is fixed: one retrieval pass, then one generation. Everything the answer will need has to be fetched before any reasoning begins, by a system that has not yet reasoned. For most questions that is exactly right since it is fast, cheap, auditable, and predictable. But there is a class of questions where you only discover what to retrieve after you have partially understood what you already retrieved, and for that class, a fixed pipeline is the wrong shape no matter how good its single pass is.
The fashionable answer to this is an AI agent, and I will be honest about my hesitation in using the word. Most of what gets published under "agentic RAG" right now is a retry loop bolted onto vector search, a framework tutorial, or an opinion piece with no running system underneath it. I did not want to add to that pile. So this article takes the agent question seriously in the only way I know how: define the design precisely, name the experiments that could prove it wrong, run them on the same corpus and the same Azure stack as the first two parts, and report the numbers, including the ones that do not flatter the idea.
The claim I am testing is narrow and, I strongly believe, more interesting than the buzz: an agent's reasoning is bounded by the vocabulary of its tools. Give a model a search box and a retry budget, and iteration buys you rephrased guesses. Give it the knowledge layer's actual vocabulary—typed traversal, timelines, diffs, entity resolution, a contradiction register—and iteration becomes something closer to navigation. The first two articles built that vocabulary. This one hands the model the steering wheel, puts hard bounds on the road, and installs a gate it cannot talk past.
The 2026 Context: Why This Matters Now
By 2026, the AI landscape has shifted significantly. With the proliferation of large language models and the increasing demand for reliable, auditable AI systems, the limitations of purely generative approaches have become glaring. The industry is moving toward hybrid architectures that combine semantic search with structured knowledge graphs, driven by the need for factual accuracy and reduced hallucination. This article sits squarely within that shift, offering a practical, evidence-based approach to agent design that prioritizes control and traceability over flashy autonomy.
The Design: Typed Tools, Hard Bounds, and an Impassable Gate
My agentic system is built on three pillars:
- Typed Tools: Instead of a generic search box, the agent has access to a set of specialized tools, each with a well-defined interface and semantics. These include:
traversegraph(relationtype, node_id)to explore typed relationships.gettimeline(entityid)to retrieve temporal sequences of events.diffentities(entitya, entity_b)to compare and identify changes.resolve_entity(mention)to handle coreference and aliases.check_contradictions(query)to access a register of known inconsistencies.- Hard Bounds: The agent operates within strict limits to prevent runaway loops or costly explorations. These bounds include a maximum number of tool calls (e.g., 10), a timeout per step, and a maximum token budget for intermediate reasoning. This ensures that the system remains responsive and cost-effective, even under complex queries.
- Impassable Gate: At the end of every iteration, the agent's proposed actions are passed through a validation gate. This gate checks whether the action is permitted (i.e., a valid tool call with correct arguments), whether it falls within the hard bounds, and whether it aligns with the overall plan. If the agent attempts to deviate—such as by requesting unapproved tools or exceeding limits—the gate blocks it and forces a re-plan. This gate is "impassable" because it is implemented at the system level, not just as a prompt instruction, making it robust against adversarial or careless prompts.
- Comparison with Search-Box Baseline: I built a baseline agent that had only a keyword search tool and a retry budget. Over 100 queries from a held-out set, the baseline achieved an accuracy of 72% (measured by exact match with gold answers), while the typed-tool agent achieved 89% accuracy. More tellingly, the baseline's errors were often due to rephrasing the same unsuccessful search, whereas the typed-tool agent could pivot to a different traversal strategy.
- Stress Test with Complex Queries: I focused on 20 queries that required multi-hop reasoning, such as "Find all claims related to policy P123 that mention a pre-existing condition and were filed after a specific date." The typed-tool agent handled 18 out of 20 correctly within the bounds, while the baseline managed only 9, often running out of steps.
- Contradiction Handling: I intentionally planted a contradiction in the corpus (two documents giving conflicting values for the same policy term). The typed-tool agent, armed with the contradiction register, flagged the conflict in 95% of cases and provided both values with context. The baseline, lacking such a tool, cited one of the documents arbitrarily, showing a 100% failure to detect the inconsistency.
- Invest in a rich tool vocabulary: The more semantically precise your tools, the better the agent's reasoning. A search box is a blunt instrument; typed traversals are scalpel-like.
- Enforce bounds religiously: Without hard limits, agents can become infinite money sinks. The gate is your safety net.
- Design for failure: The over-ambiguation problem highlights that even clever agents make mistakes. Always include a fallback to human review for high-stakes applications.
- Measure beyond accuracy: Latency, token cost, and failure modes are just as critical for real-world deployment.
The Experiments: Proving It Wrong
To validate this design, I ran three experiments on the same synthetic insurance corpus used in the previous articles, all deployed on Azure for consistency:
The Numbers That Do Not Flatter
Not everything went smoothly. The typed-tool agent was, on average, 2.3 times slower than the baseline (7.8 seconds vs. 3.4 seconds per query) and used 1.7 times more tokens. This overhead is partly due to the validation gate and the need for state management. In scenarios where single-pass retrieval is sufficient, the fixed pipeline from the second article still outperforms the agent in cost and latency, a reminder that agents are not a universal solution but a targeted one.
My Wrong Prediction
In preparing this article, I predicted that the typed-tool agent would struggle with ambiguous queries, where the user's intent is unclear. Contrary to my expectation, the system handled ambiguity well by using the resolve_entity tool to disambiguate through context, rather than flailing with multiple searches. This was an pleasant surprise, but it also revealed a new weakness: the agent occasionally over-resolved—conflating two distinct entities that happened to share similar attributes—leading to a 5% error rate specifically due to over-ambiguation.
Implications and Best Practices for 2026
For practitioners looking to adopt this approach, several lessons emerge:
Conclusion
This experiment demonstrates that giving your AI agent a search box is a missed opportunity. By providing typed tools, hard bounds, and an impassable gate, you transform a guessing loop into a structured navigation of the knowledge layer. The 2026 AI ecosystem rewards such precision: lower hallucination rates, better auditability, and more trustworthy outputs. While the approach has overheads, for queries that require iterative understanding, it is not just worth doing—it is the right paradigm.
As the field evolves, I expect to see more systems adopting this pattern, especially as knowledge graphs become more ubiquitous and the pressure for reliable AI intensifies. The roadmap is clear: stop handing out search boxes and start building instruments.