What Privyrex is, and how it actually works
Privyrex is an AI-native helpdesk: a support widget, ticketing system, and knowledge base built around a retrieval-augmented generation pipeline, rather than a traditional ticketing system with an AI feature added on top. This page explains what that means concretely — the request pipeline, the data model, and the guarantees behind each part of it.
What Privyrex is
Privyrex is a support platform with three parts working off one shared knowledge base: an embeddable chat widget for end-users, an agent-facing ticketing console, and a retrieval pipeline that sits between them. When a visitor asks a question, the same knowledge base your agents use is queried in real time, and the widget either resolves the question directly or escalates it to a human with full context attached.
The distinction that matters technically: most helpdesk platforms were built as ticketing systems first, with an AI answer-generation feature added afterward. Privyrex's schema, retrieval layer, and evaluation layer were designed together, so a ticket, a knowledge-base chunk, and a widget conversation are all first-class, tightly linked entities rather than separate systems bridged by an integration.
The request pipeline, step by step
From the moment a visitor sends a message to the moment they get an answer:
Hybrid retrieval and fusion
A single retrieval method rarely works well for every kind of support question. Vector search is strong on paraphrased or conceptual questions but can miss exact terms — model numbers, error codes, SKUs. Keyword search catches those exact terms but misses paraphrasing. Privyrex runs both at once, plus metadata filtering and a recency-decay score that favors freshly updated documentation over stale ones.
These four result sets are merged using Reciprocal Rank Fusion (RRF) rather than a simple
weighted average, which is more robust when the retrievers disagree about which result is actually best.
A semantic deduplication pass then removes near-identical chunks so the model isn't shown the same fact
three times, and a context compressor enforces a fixed token budget — protecting both response latency
and cost.
Agentic multi-round retrieval
Most AI helpdesk tools run retrieval exactly once per question. If the first pass doesn't find strong matches, the model either answers from weak context (risking a hallucinated or unhelpful answer) or gives up. Privyrex adds a sufficiency check after every round: if confidence is below threshold, the query is automatically reformulated — not just repeated — and retrieval runs again, up to a bounded number of rounds.
This means a vague first message like "it's not working" can still resolve correctly, because the system can narrow the query based on what the first retrieval pass did and didn't find, rather than requiring the visitor to rephrase manually.
Response evaluation before delivery
Every generated response is scored by a separate evaluation pass — an "LLM-as-judge" — before it reaches the visitor. This checks faithfulness (does the answer actually match the retrieved source content, or does it drift into unsupported claims), relevance, and completeness relative to the question asked.
Responses that fail this check are routed to a human agent along with the full retrieval trace, rather than delivered anyway. This is the mechanism that keeps automation coverage high without trading away answer accuracy for volume.
Multi-tenant architecture
Every organization's data — tickets, documents, embeddings, conversations, audit logs — is isolated with Row-Level Security enforced at the database layer, not solely in application code. Role-based access control governs what platform admins, organization owners, organization admins, agents, and customers can each see and do, and every privileged action is captured in an immutable audit trail.
Deployment and model flexibility
Privyrex supports bring-your-own-key (BYOK) for OpenAI and Anthropic, with configurable per-organization fallback chains and budget limits — if one provider is rate-limited or down, requests fail over automatically. For organizations that can't send data to a third-party model provider at all, both the embedding and generation layers support fully self-hosted models, so the entire pipeline can run on your own infrastructure.
Technical specification summary
See the pipeline on your own data
No credit card required to start.