Talk to the sales assistant

The Helixor sales assistant is a conversational digital worker built on the platform. Talk to it on the left; on the right, every turn shows what the platform decided and why, and the API calls the conversation made.

What each part of a decision shows#

Scope

Before any model is called, the request is checked against the packs the assistant is loaded with. Implementable means every part of it binds to a declared concept or action. Needs input means it binds to an action that is missing a required input, which becomes the next question. Out of scope means it binds to nothing declared: the assistant declines by rule, with no model call, and the unbound words and the missing shape are recorded as a coverage gap.

Intent and sentiment

Two decision heads read the message. Each reports a label and a confidence, and abstains below its admitted threshold. Their calibration is still being validated, so treat the confidence as the head's own score, not a measured probability. An abstained read cannot trigger a move that ends the conversation.

Move

The playbook turns the intent, the sentiment and the conversation's history into the set of legal moves; the move head chooses among those only. The moves it could not choose are listed with the playbook rule that excluded them.

Citations

A reply may state only what the governed knowledge base says. The cited facts are shown by source document and page, from the public tier only.

Reply gate

The drafted reply is checked before it is sent: every citation must resolve to a retrieved fact, no forbidden claim, no other vendor named, one question at most. A refused draft goes back once with the reasons; a second refusal hands the question to the team.

Model calls and latency

Whether a model was called this turn (to extract what the prospect said about themselves, and to word the reply), how many reply attempts it took, and the time the worker spent on the turn.

Why a rule engine alone cannot do this#

A rule engine decides over typed fields that are already known. A conversation arrives as free text, so something has to decide what the text means, how sure it is, and what to do when it is not sure. Here that is done by decision heads that abstain below a threshold, a scope check that binds words to declared concepts or refuses, and a verbatim-span rule for anything the prospect says about themselves.

The rules still hold the line: the playbook decides which moves are legal, the gate decides whether a reply may be sent, and an out-of-scope request never reaches a model. The learned parts propose; the declared parts decide. Every turn is recorded with the heads that read it, so a decision can be replayed and audited.

What this page can and cannot see#

• The conversation runs in a frame served by the assistant's host. This page talks to the frame only through window messages, checked by origin in both directions; it makes no network request of its own.
• The decision summary is served only to the browser session that opened the conversation, through a signed cookie the page's scripts cannot read.
• The summary never contains prompts, the model's raw output, the knowledge base text, internal identifiers or anything from another conversation. Your own words appear only where the scope check quotes what you typed.
• The booking form's name and work email are never reported to this page.

For what a digital worker is and how the one you just talked to is put together, read Build a digital worker and How agents work. To follow the build step by step, read How the sales assistant was built. For the decision runtime on its own, try the hosted playground.