Overview
What the PlanCover assistant is allowed to do, and what stays with the backend.
PlanCover's assistant answers member questions about policies, claims and coverage across three channels: the web portal, the mobile app, and WhatsApp. All three talk to one backend.
The governing rule is simple, and everything else in these docs follows from it:
The division of authority
The model handles language and reasoning. The backend keeps authority over data, permissions and actions. A question is never answered from the model's own knowledge of insurance — only from retrieved evidence and tool results.
What it answers
Questions arrive in a member's own words and usually mix two different kinds of information:
- Stable knowledge — policy wording, coverage, exclusions, waiting periods, FAQs and process documentation. These are retrieved from the vector index.
- Live state — claim status, pending documents, CD account balances, e-card availability. These are fetched through approved tools, never embedded.
A question like "why is my claim still pending, and is this treatment covered?" needs both, in one answer, with each half attributed to where it came from.
What it never does
Reach a database
The model receives tool results. It never holds a connection string, a query, or a raw HTTP client.
See a token
Access tokens never enter a prompt, a tool argument, graph state, a trace, or a log line.
Assume success
No action is reported as done until the upstream PlanCover API confirms it.
Loop unbounded
Tool steps, model iterations, retries and retrieval size all carry hard limits.
Reading order
Start with Architecture for the shape of the system, then Streaming for the event contract the frontends consume. Components documents the MDX components available when writing a page here.