How to Ground an AI Support Agent in Your Own Knowledge Base
When a biotech company splits off into its own operation, the org chart isn’t the only thing that changes overnight. The support inbox does too. One team we worked with went from having an established parent company’s infrastructure behind them to standing up an entirely new operation, and within weeks their inbox was buried in the same handful of questions. Where’s my kit. How long does shipping take. What do these results mean. None of those questions were hard. There were just too many of them, and they were landing on people who needed to be handling harder problems.
This is a common pattern for any business going through a system migration, a spinoff, or rapid growth. The volume of routine questions scales faster than the team that has to answer them. The instinct is often to hire more support staff or push everyone to work faster. But in this case, the better fix wasn’t more people. It was building an AI agent that could actually answer those routine questions correctly, and know when not to.
The problem with jumping straight to AI
Here’s the part that gets skipped in a lot of AI conversations. You can’t hand an AI agent a pile of unorganized information and expect good answers. This company was migrating away from an old platform, which meant there was no existing knowledge base to plug an agent into. The knowledge had to be built first.
That’s actually a useful position to be in, even though it doesn’t feel like it at the time. Most businesses that want to add AI to their support process are working with a decade of accumulated, disorganized documentation, tribal knowledge that lives in one person’s head, and support tickets that were never turned into anything reusable. This team was starting from nothing, which meant every article they wrote could be written correctly the first time, in a format built for AI retrieval rather than retrofitted later. If you’re earlier in that process yourself, How to Audit Your Support Data Before Adding AI is a good place to start before you touch any AI tooling at all.
Standing up the foundation
The build had two parts. First, standing up a new Salesforce Service Cloud instance so the support team had a home for tickets, routing, and customer communication. Second, and more importantly, building a knowledge base from scratch inside that instance.
This is also a highly regulated space. It’s consumer biotech, which sits close enough to healthcare that accuracy isn’t optional. If an AI agent gets a shipping estimate wrong, that’s annoying. If it gets a test result explanation wrong, that’s a real problem. So the tolerance for error here was much lower than in a typical customer support use case, and that shaped every decision that came after.
Writing knowledge articles for retrieval
Once the knowledge base existed, the next job was making sure it was written in a way an AI agent could actually use. There’s a real skill to this that’s separate from the AI part entirely. It’s writing documentation that’s accurate, specific, and structured so a retrieval system can pull the right piece of it at the right time, rather than a wall of loosely organized text. How Your AI Agent Actually Finds the Right Answer goes deeper on how that retrieval process actually works.
Grounding the agent, not letting it wander
With the knowledge base in place, the team built an AI agent using Salesforce’s Agentforce, set up specifically to answer questions using only that knowledge base. This is an important distinction. The agent isn’t searching the open internet the way a general chat tool might. It’s confined to the business’s own documentation, which means every answer it gives is traceable back to something the business actually wrote and approved.
That constraint is a feature, not a limitation. In a regulated industry, you want an agent that can say “I don’t know” rather than one that improvises a plausible-sounding answer. So the build included clear guardrails. If a question touches on specific clinical information or medical advice, the agent doesn’t attempt an answer. It escalates to a human. The same is true anytime it can’t find a confident answer in the knowledge base. Answer what you know, escalate what you don’t, is a simpler design principle than it sounds, but it’s the one that actually keeps an AI agent trustworthy in a sensitive industry. Before any of this goes live, it’s worth running the agent through real scenarios first, which How to Test an AI Agent Before It Talks to Customers covers in more detail.
What actually changed
Within the first version of this build, the agent was handling about 40 percent of inbound inquiries without any human involvement at all. That’s a large enough number to be meaningful on its own, but the more important shift was in where the support team’s time went. Instead of spending their day on the same repetitive questions, they had room to handle the inquiries that actually needed a person. And because the knowledge base lived inside Salesforce, keeping it current didn’t require a separate process. When someone wrote a new article to cover a gap, it synced automatically and the agent could use it right away.
That kind of result is worth measuring properly rather than just feeling anecdotally. If you want a framework for what to actually track, How to Measure Whether Your AI Agent Is Actually Working walks through the specific signals that matter.
The part most businesses skip
It’s tempting to treat a result like this as a technology story, but it’s really a data story. An AI agent is only as good as what it’s grounded in. Good data produces good answers at scale. Bad or incomplete data produces bad answers at scale, because whatever mistake exists in your knowledge base gets repeated to every customer who asks that question, not just one.
That means the real work here wasn’t the AI configuration. It was the audit of what questions were actually being asked, the discipline of writing it down accurately, and the willingness to treat that as foundational work rather than a formality to get through before the “real” AI project starts. If your team is earlier in a system change like this one, What Happens to Support When You Migrate Systems is worth reading before you’re mid-migration and trying to catch up.
Where to start if this sounds familiar
If your support team is fielding the same questions over and over, or you’re in the middle of a platform migration and staring down a knowledge base that doesn’t exist yet, this is solvable without a massive AI initiative. It starts with understanding your own process well enough to write it down, then building an agent that’s grounded in exactly that, with a clear path to a human for anything sensitive.
Listen to the full podcast episode here.