What Your Knowledge Base Looks Like to Your AI Support Agent
The retrieval endpoint Chat's AI agent actually queries against Knowledge, written from the knowledge-base owner's point of view.
If you maintain your team's Knowledge base, there's a reasonable question you might not have a concrete answer to: what does the AI actually see when it answers a customer's question using your content? This is the companion piece to Chat's grounded AI reply suggestions guide, written from the other side — what you're actually feeding it.
The retrieval path, concretely
When Chat's AI agent needs to ground a reply in your documentation, it doesn't reach into Knowledge's database directly. It goes through a dedicated route — frontend/apps/knowledge/src/app/api/ai-agent/knowledge-base/route.ts — which forwards the request to the shared AI-agent-worker's /apps/agent/kb endpoint. Along the way, it translates the camelCase parameters your UI and API use (agentId, documentId) into the snake_case contract the worker expects. That translation layer is a small detail, but it's the reason your knowledge base and the AI agent infrastructure can evolve their own conventions independently — the route is the seam between them, not a place where the two systems have to agree on naming.
What this means for how you write
Because the AI agent's replies are only as good as what it can actually retrieve, the practical implication is straightforward: content that's clearly written, accurately scoped, and kept current is what shows up in a grounded reply. Content that's vague, outdated, or missing entirely means the AI agent either can't answer a question at all, or answers it with weaker sourcing — visible directly in the suggested reply's citations, since a thin source list on a suggested draft is often a sign the underlying documentation itself is thin.
Why this closes the loop with the chat side
Chat's grounded AI reply suggestions retrieve from "the workspace's own knowledge base" — this route is the literal mechanism behind that phrase. Knowing that the same content you publish for human readers on your docs site is what the AI agent draws from for support replies means there's no separate "AI-only" content to maintain. Writing and maintaining good documentation in Knowledge does double duty automatically: it's your public-facing docs, and it's your AI agent's grounding material, through the same underlying articles.
A practical check
If you notice the AI agent consistently struggling with a certain type of question, the fix usually isn't on the chat side — it's going back to your Knowledge base and checking whether the relevant article actually exists, is published, and is written clearly enough to retrieve well. Treat weak AI-suggested replies as a signal pointing at your documentation, not just at the AI.