Answer it before it becomes a ticket, then make every ticket that survives faster
Multiple agents across multiple knowledge hubs is a core capability of the platform, and it is what lets the customer-facing agent and the internal one draw on very different knowledge, safely.
One platform, two very different knowledge boundaries
The public agent and the internal agent are not the same agent with different permissions. They are different hubs, which is what makes the boundary safe.
The front-loaded agent
Deployed on your website and inside your product, answering technical support questions before they reach a person. It is the first responder to everything.
It handles 30% of commonly asked questions end to end in a straightforward deployment, and up to 75% depending on the use case and the complexity of your products. Every customer is different, and we would rather give you the range than a single flattering number.
In the AMD ROCm developer community (Discord and Discourse, thousands of developers, public) it reduced L1 support requests by more than 30%.
The agent behind the escalation
When a ticket escalates to your internal technical support team, those people can see things the public agent cannot: confidential data, and products not yet released to market. Their knowledge hub reflects that.
A support ticket or email arrives. We intercept it and produce the right answer from the information that team is entitled to see. The engineer reviews it, reads it, and sends it back to the customer, very quickly.
Human judgment stays in the loop. The agent does the retrieval and the drafting; your engineer approves and sends.
An unreleased product should never surface on your website
Scoping by hub rather than by instruction is the difference between a policy and a guarantee.
Public
Published documentation only. What a customer or an anonymous visitor is entitled to see, and nothing more.
Partner
Channel-appropriate depth for dealers and integrators, more than the public hub, less than internal.
Internal
Confidential material, support history, and products not yet released. Available to your engineers, invisible everywhere else.
The question every support leader asks in the second demo is "what stops it telling a customer about a product we have not launched?" The answer is that the material is not in that agent’s hub at all.
It also tells you what your documentation is missing
Alongside the agent we hand back analytics on document gaps and on the conversations happening, then work with you to close them.
- Document gaps, the questions being asked that your content cannot answer.
- Conversation themes, what customers and partners are trying to do on your platform.
- Answer quality review, including the conversations that went badly and why.
- Deflection is not a fixed ceiling. It is a function of coverage, and coverage is something you can improve deliberately.
- Your knowledge base improves as a by-product of running the agent, which helps your human team too.
- Next quarter’s number should be higher than this quarter’s, and you will know exactly why.
Common questions from support leaders
Why is the deflection number a range?
Because it truly is one. It depends on how complex your products are, how good your documentation is today, and which surface you deploy on. 30% is what a straightforward deployment achieves; up to 75% is achievable where the question mix and the content support it. We would rather set that expectation than quote you the top of the range.
What happens to the tickets it cannot answer?
They escalate to your team, but not empty-handed. The internal agent drafts the answer from confidential and pre-release material your engineers can see, and the engineer reviews and sends. The escalation still happens; it just takes minutes instead of hours.
Can it live inside our product rather than on a help center?
Yes, and that is where it performs best. Embedded in your product it becomes the first thing a customer meets when they hit a problem. Several of our physical security customers run it this way.
How do you handle a public developer community?
Carefully: the threat model there is completely different from an authenticated dashboard. Our FireShield safety layer handled 100% of harmful and off-topic queries in benchmarking against the ToxiGen dataset, with 98.5% blocked at the first layer and no false positives on legitimate questions.
How do we get comfortable before it goes live?
Shadow mode. The agent answers real incoming questions without exposing anything, your team reviews and ranks the responses, and you go live when the quality is where you want it. AMD ran two weeks of shadow production testing on Discord and forum questions before launch.
Related
Run it in shadow mode first
Point it at your real incoming questions without exposing anything. Review the answers with your team, then decide.
SOC 2 Type II · Every answer traceable to its source