What a help assistant should and should not know about your business
Sage answers how-to questions from our help corpus and declines questions about your records, your numbers, or what you should do next. Here is why.
The help assistant inside PartnerView is named Sage. It answers a question by retrieving excerpts from our help articles, the User Manual, and the Feature Catalog, then synthesizing an answer that cites the source.
It does not read your live business data. It does not predict business outcomes. It politely declines questions about specific records, specific numbers, or what you should do next.
That last set of refusals is deliberate. The line between “how do I model this” and “what should I do” is the line between a documentation question and a judgment call. The first is something a help assistant should answer. The second is something the firm should answer, with the firm’s context, by a person who is accountable for the outcome.
What Sage is grounded in
Sage’s knowledge is three corpora plus a code-derived domain layer.
The first corpus is our help articles, written as documentation. The second is the User Manual, the long-form prose that explains how the product works. The third is the Feature Catalog, the structured inventory of every shipped capability. A code-derived domain layer adds the schema of the product, so Sage understands what a deal is, what a commission schedule is, what a revenue recognition entry is, in the abstract.
The retrieval is FTS5 over chunked content. No vector database. Keyword retrieval against indexed chunks of the corpora above. When a user asks a question, the retrieval ranks the most relevant excerpts. Claude synthesizes an answer using only those excerpts as input.
When the retrieval is weak, when no excerpt scores high enough to be useful, Sage returns “not covered” and does not call the model at all. Sage does not hallucinate an answer from training data when the help corpus does not contain one. The not-covered cases land on an admin dashboard so we can write the missing article.
The corpus is re-indexed at every deploy, after migrations. The help content Sage knows about equals the help content the product just shipped. There is no separate “AI knowledge base” maintained by a separate team that drifts from the product. The product is the source.
What Sage deliberately will not see
No business data. None of it.
The system prompt and the code that calls the model pass three things only. The user’s current question. The recent conversation turns. The retrieved help excerpts. That is the entire context window.
Sage never sees a deal record. Never a commission. Never a margin number. Never a journal entry. Never a customer name from your CRM. Never a time entry. Never a permission role. Never an aging report.
If a user asks “how is my deal with Acme Corp doing,” Sage does not look up the deal. Sage explains that it answers how-to questions about the product, and the user should open the deal record. If a user asks “what should I quote for a 12-week implementation,” Sage explains that pricing decisions are not in scope for the help assistant.
This is not a guardrail bolted on after the fact. It is a design choice about what shape of question the assistant is for. We do not want a model making business judgment calls on a firm’s money, and the cleanest way to make sure that does not happen is to never put the firm’s data in front of the model in the first place.
The posture is independently leak-tested. The test suite includes adversarial probes that try to get Sage to surface business data, infer numbers from the structure of the question, or take a position on a judgment call. The probes are part of the standing test set. A failed probe blocks the build.
What an admin controls
The admin surface at /admin/helpbot is the proof that the posture is operable, not just declared.
An org-wide kill switch turns Sage off for the whole tenant. If the firm decides they do not want any LLM in the loop, the switch flips and Sage stops responding. The Help drawer falls back to keyword search against the help corpus.
A model selector lets the admin choose Sonnet (the default) or Haiku (cheaper, faster, slightly less capable). The choice is per-tenant. The admin who is cost-sensitive picks Haiku. The admin who wants the better synthesis picks Sonnet.
A monthly budget cap with auto-pause. If Sage spends more than the cap in a calendar month, it pauses for the rest of the month. The admin sees the pause on the dashboard. The cap is set by the admin, not by us.
A per-user hourly rate limit, default 30 questions per hour per user. Stops a runaway script. Stops a frustrated user from asking the same question 200 times.
The dashboard shows the thumbs split (helpful versus not helpful, per session) and the gap list (questions Sage marked “not covered”). The gap list is the firm’s input into our help-writing backlog. If your users keep asking a question we have not documented, we should know.
What PartnerView ships
Sage is the help assistant inside the Help drawer. Three corpora plus a code-derived domain layer, FTS5 retrieval, Claude synthesis from retrieved excerpts only, no business data in the system prompt, “not covered” on weak retrieval, org-wide kill switch, model selector, monthly budget cap, per-user rate limit, admin dashboard with thumbs split and a gap list.
The privacy posture is the same shape as the rest of the product. Money math is deterministic and stays out of any model. The help assistant is grounded in documentation and stays out of business judgment. The line between what a model is for and what a person is for runs through the product on purpose, and Sage is the visible part of where we drew it.
A model answering “how do I configure a commission schedule” is a documentation question. A model answering “should I take this deal” is a question the firm should answer. We chose where the line goes, and we test that the line holds.