Retrieval-augmented generation, RAG, is a pattern where a system searches a knowledge base for the passages most relevant to a question and hands them to a language model as context before it generates an answer. It is fast to build and works well for single-fact lookups, things like "what's the current VPN client version" or "how do I request a new laptop." It breaks down the moment an answer requires comparing two documents, deciding which of three overlapping KB articles is current, or following a chain of dependent facts across separate sources.
That gap is exactly where most ServiceNow knowledge bases live. In one mid-market environment I reviewed, 340 published KB articles included roughly 110 that referenced a VPN client, MFA enrollment flow, or software version that had already been retired. Standard RAG has no way to know that. It ranks passages by how closely their wording matches the question, not by whether the passage is still true, so a stale article with better keyword overlap gets retrieved with the same confidence as the current one.
The model then answers fluently and wrong.
This is the failure mode that quietly caps ticket deflection rates. A chatbot can run the retrieval pipeline correctly, format a clean answer, and still send a user through steps that no longer apply, because nothing in a standard RAG pipeline checks recency or resolves conflicts between sources.
Four failure patterns show up over and over once a knowledge base grows past a few hundred articles:
Plain RAG runs one retrieval pass, hands the model whatever it finds, and generates an answer. Agentic retrieval gives the model tools instead, typically search, open, and compare, and lets it decide how many passes it needs before it has enough evidence. If the first search returns a March article and a June article on the same topic, the agent can open both, compare them, and pick the current one instead of blending them into a wrong answer.
| Plain RAG | Agentic Retrieval | |
|---|---|---|
| Retrieval steps | One pass, fixed | Multiple passes, model-directed |
| Conflicting KB articles | Picked by similarity score alone | Can open and compare before answering |
| Multi-hop questions | Answered from a single chunk | Designed to chain evidence across sources |
| Cost per query | One model call | Typically 2 to 5x more model calls |
| Latency | Sub-second to a few seconds | Several seconds to tens of seconds |
| Best fit | Single-fact lookups, FAQ-style questions | Multi-step policy and approval questions |
By a meaningful margin, and there is research behind it beyond vendor marketing. According to Google Research (2026), its agentic RAG framework improved accuracy on factuality benchmarks by up to 34% over standard RAG. A separate 2026 study on retrieval-augmented systems in straight-through underwriting found agentic approaches reached 85 to 86.5% decision accuracy, compared to 71.5 to 77.6% for naive RAG and single-LLM approaches on the same task. Underwriting is not IT support, but the shape of the problem, a decision that depends on cross-referencing multiple documents against a policy, is the same one that shows up in software approval and access request tickets.
Take a ticket that reads: "Can I install Adobe Acrobat Pro on my laptop?" Answering it correctly means checking three things: whether Acrobat Pro is on the approved software list, whether the user's license tier includes it, and whether their device meets the compliance baseline required for the install. Those live in three separate KB articles and often a ServiceNow catalog item. Plain RAG retrieves whichever article scores highest on "Adobe Acrobat Pro," usually the software list, and answers from that one document. The license and compliance checks never get retrieved, so they never get checked.
Permission-aware retrieval isn't optional once a knowledge base mixes HR or finance content with IT articles. Enterprise RAG deployments that skip access control at the retrieval layer can surface restricted documents to users who never should have seen them, because a vector index has no built-in concept of who is asking. Solve this before launch, not after an incident.
Agentic retrieval is not the default answer for every knowledge base. If your tickets are mostly single-fact lookups, password policy, printer setup, wifi credentials, plain RAG is faster, cheaper, and simpler to maintain, and adding an agent on top just adds latency and API cost with no accuracy gain. The decision point is whether your top ticket categories require cross-referencing more than one source to answer correctly. If fewer than one in five do, plain RAG paired with a disciplined content review process will beat a more complex system you now have to maintain.
The pattern is a small set of tools bound to the knowledge base, not one retrieval function. A minimal version looks like this:
{
"tools": [
{ "name": "search_kb", "description": "Search by keyword and semantic similarity", "params": ["query", "max_results"] },
{ "name": "open_article", "description": "Retrieve full text and metadata for one KB article", "params": ["article_id"] },
{ "name": "compare_articles", "description": "Flag conflicting or outdated content between two articles", "params": ["article_id_a", "article_id_b"] },
{ "name": "check_access", "description": "Verify the requesting user can view this article before returning it", "params": ["article_id", "user_id"] }
],
"max_tool_calls_per_query": 4
}The check_access tool is the one teams skip most often, and it is the one that turns a knowledge base mistake into a security incident. We cover the same scoping principle from the identity side in our three-tier security model for IT automation: permissions belong to the task, not to the tool, whether that tool resets a password or returns a document.
The honest tradeoffs are latency, cost, and complexity, not accuracy. Agentic retrieval typically runs two to five model calls per question instead of one, which multiplies token spend and adds a few seconds of response time, unnoticeable on a support ticket but noticeable on a live chat widget. It also means more moving parts to monitor: a search tool that returns nothing, a compare step that times out, a permission check that fails open instead of closed.
None of that is a reason to avoid it.
It is a reason to scope which ticket categories actually need it instead of routing every question through the more expensive path. This is the kind of scoping work we do as part of LLM integration engagements: mapping ticket categories to the retrieval pattern that actually fits them before writing any code.
Standard RAG runs one retrieval pass and generates an answer from whatever it finds. Agentic RAG gives the model tools to search, open, and compare multiple sources, and lets it decide when it has enough evidence, which is what makes it handle multi-hop questions and conflicting documents correctly.
It depends on your ticket mix, not your headcount. If most tickets are single-fact lookups, plain RAG with clean, current content will outperform a more complex system. If a meaningful share of tickets require cross-referencing multiple policies, an approved software list plus a license tier plus a compliance check, agentic retrieval earns back its added latency and cost.
Standard retrieval ranks passages by keyword and semantic similarity, not by whether the content is current. An outdated article that closely matches the question's wording can outrank a newer, more accurate one unless the retrieval layer explicitly checks recency or you actively retire stale articles.
Yes, typically two to five times more model calls per question, because the agent runs multiple search and comparison steps instead of one retrieval pass. The added cost is usually a few cents per query, worth it for complex policy questions and not worth it for simple lookups.
Yes, if the retrieval layer isn't permission-aware. A vector index has no built-in concept of who is asking, so without an explicit access check bound to each tool call, a passage from an HR or finance document can surface to a user who shouldn't see it.
If your ticket queue includes questions that span more than one policy or KB article, we help engineering teams design the retrieval architecture, tool scoping, and access controls before it goes near production.
Talk to an EngineerFree 2-minute assessment. Get an industry-specific score and action plan — no call required.