Build a digital worker
A digital worker is a hosted agent that pursues one goal under declared rules and records every decision it makes. This page explains what that means, when to choose a worker instead of embedding the Decision Runtime in your own code, and how the Helixor sales assistant is built as one. It ends with the capabilities a worker can use, their status, and how each is licensed.
Status
The Digital Worker platform is in Preview. Its first worker, the sales assistant, runs in production but is not open to the public yet. Workers are declared and deployed by the Helixor team on the hosted platform; self-serve worker authoring is Planned. Everything on this page not marked Planned exists and is covered by tests.
What a digital worker is#
A digital worker has four parts. Each one is declared, so you can read it, test it and change it through review.
| Part | What it is | In the sales assistant |
|---|---|---|
| A goal | The outcome the worker drives toward, and the fixed set of outcomes it may reach. | Qualify a website visitor to one next step: start a trial, book a demo, talk to an engineer, come back later, or stop. |
| What it tracks | The state it keeps between steps. | A qualification record of eight slots (role, company, use case, pain, scale, current approach, timeline, constraints), the conversation stage and the history. |
| Decisions within rules | Every choice is made inside a legal set the rules allow. Learned parts may prefer one option; they can never pick one the rules forbid. | A playbook decides which moves are legal on each turn; a trained head chooses among them; a reply gate decides whether a drafted reply may be sent. |
| An audit trail | A durable record of each decision and its inputs. | One record per conversation, with one row per turn: what was read, the legal moves and the rule that bounded them, the chosen move and why, the cited facts, the gate result and the version of every head involved. |
A worker, or the runtime in your own code#
The Decision Runtime and a digital worker use the same idea, a decision taken from declared rules with a record of why, but they put the loop in different places.
| Decision Runtime in your code | Digital worker | |
|---|---|---|
| Shape | A function your process calls: typed facts in, one action from a closed set and a receipt out. | A hosted service that owns the loop: it keeps state across turns or steps, and returns a decision, a reply and a record for each one. |
| Who owns the loop | You do: conversation, state, retries, model calls and storage are your code. | The worker does: state, model calls, gating, next steps and the durable record are part of the platform. |
| Language model | None. The runtime makes no model call. | Used to read free text into proposals and to word replies, under the controls described below. |
| Where it runs | In your process, offline, with a licence verified locally. | On the hosted platform, reached over an API. |
| Choose it when | The decision sits inside a system you already run, and its inputs arrive as fields. | The work is a multi-step interaction toward a goal, such as a conversation, and you want the platform to run it and keep the record. |
| Status | Available | Preview |
Worked example: the sales assistant#
The sales assistant talks with website visitors. It answers from public material only, learns who the visitor is, and drives to a decided next step. Each component below is what runs in production today.
| Component | What it does | Where it lives |
|---|---|---|
| Scope check | Before any model call, the visitor's message is checked against the declared product and playbook packs. The verdict is implementable, needs_input (the move becomes asking for the missing input) or out_of_scope (an honest decline from a rule template, with no model call at all). If the packs fail to load, every turn is declined. | Worker service; scope declared in the worker's packs |
| Intent and sentiment heads | Two small trained classifiers read the message: one picks an intent from a fixed list, the other scores sentiment from 0 (hostile) to 4. Each abstains below its confidence threshold, and the turn record says so. Intents that end the conversation are acted on only when the read is confident. The heads were trained on synthetic conversations; their calibration against real outcomes has not been validated yet. | Worker service; each head pinned by version in the worker's manifest |
| Qualification record | A language model proposes values for the eight slots. A value is stored only if it appears word for word in the visitor's message. | Worker service |
| Playbook legality matrix | For each intent and sentiment level, the playbook lists the legal moves. Hard rules apply first: a request for a person allows only a hand-off, a no allows only disengaging, a hostile message allows no selling move, and a signup ask is removed at low sentiment or within three turns of the last one. The turn records the legal set and the rule that produced it. | Worker service; playbook tables in the worker |
| Move choice | A trained move head scores only the legal moves. One legal move is forced. When the head is unsure, the playbook's default move is used and the turn is marked escalate. | Worker service |
| Reply gate | A drafted reply is sent only if every cited fact was retrieved this turn from the public knowledge base, it cites at least one fact, it names no excluded company the visitor did not name first, it states no price, discount or guarantee, and it asks no more than the one question the turn calls for. A refused draft goes back to the model once with the reasons. A second refusal sends a hand-off line and queues the question for a person. | Worker service; knowledge base built from public collateral only |
| Durable conversation record | One record per conversation, with a row per turn holding the decision and its inputs. A write against a stale revision is refused with CONVERSATION_CONFLICT; an ended conversation refuses new turns. | Worker service, in the platform's durable store |
| Booking seam | For a demo or engineer next step, the worker can list a shared calendar's open times and book one, collecting only a name and a work email. Booking can be disabled, and it is disabled in production today: the worker still decides the next step and records it, and offers the contact path instead of times. | Worker service, behind a calendar connector |
| Widget authentication | The website widget's server calls the worker with its cloud workload identity: a short-lived token signed by the cloud provider, checked against an allow-list of service identities and accepted only on the sales routes. No stored secret, and the browser never holds a credential. | Widget server route and worker service |
You can hold a conversation with it and watch each turn's decision on Talk to the sales assistant. The full build, in the order it happened, is in How the sales assistant was built.
Which steps use a language model#
This is the difference that matters. A language model reads free text into proposals and words the reply. It never decides scope, legality or the move. Those are decided by declared rules and small trained heads, and every one of them is recorded.
| Step | Decided by | Language model |
|---|---|---|
| Is the request in scope? | Deterministic check against the declared packs | Not called. An out-of-scope turn makes no model call at all. |
| What does the visitor mean, and how do they feel? | Intent and sentiment heads, with abstention | Not used |
| What have we learned about them? | A verbatim-span rule admits or rejects each value | Proposes values |
| Which stage, and which next step to aim for? | Rules over the qualification record | Not used |
| Which moves are legal? | The playbook matrix and hard rules | Not used |
| Which legal move now? | The move head over the legal set; forced when one move is legal; playbook default when unsure | Not used |
| Which facts may be stated? | Lexical retrieval from the public knowledge base | Not used |
| What are the words? | The model writes a draft for the chosen move from the retrieved facts only | Writes the draft, and one repair |
| May the reply be sent? | The reply gate | Not used |
| A request for a person, or a no | Hard rule; the reply comes from a template and the conversation ends | Not called for the reply |
Because of this split, a changed rule, head or fact changes behaviour in a way you can test and replay, instead of a prompt you have to re-tune. The heads are learned, but they choose only among options the rules allow, and they are pinned by version.
What a worker does not do yet#
- Learning from outcomes Planned. The worker records a conversion forecast on every turn and queues unanswered questions and out-of-scope requests, but heads are not yet retrained from real conversation outcomes. See How agents work.
- Declared playbooks for any domain Planned. The sales assistant's scope packs are declared files, but its turn loop, playbook tables and qualification slots are written for sales. A second conversational worker needs its own worker code today.
- Live booking Planned, until calendar delegation is set up.
- A public entry point Planned. The assistant's public chat host is not live yet.
Capabilities and licensing#
A worker can use four capabilities. They differ in maturity, and each is licensed separately. The entitlement ids below are a draft under review: they are not yet in any licence, and nothing checks them yet. The licence file reference describes the entitlements that exist today.
| Capability | Status | What it adds | Entitlement (draft) |
|---|---|---|---|
| Decision Runtime | Available | Decisions from versioned packs inside your own process, offline, with a receipt for each decision. | Existing licence tiers and licensed_packs, unchanged. See Licensing and tiers. |
| Digital Worker platform | Preview In production, not public yet | A hosted worker that owns the loop: turn state, scope check, heads, playbook, gated replies, durable per-turn records. The sales assistant is Helixor's own worker built on it; running it on your own material is Planned, with self-serve worker authoring. | worker.platform.v1 (Enterprise); add-ons worker.sales_rep.v1 and, once booking is live, worker.connector.calendar.v1. Draft. |
| Governed data (Lattice) | Partial | Live reads from your systems under ontology policy, with no copy of the data made. Today this covers virtual reads only: filters and projections pushed down to relational databases, REST sources filtered in the gateway, row and field policy from the ontology that denies when no policy applies, pages of up to 2,000 rows, and joins in the gateway capped at 2,000 rows. There is no aggregation. The governed read path returns no access receipt, and the prototype's receipts are unsigned digests; signed access receipts are Planned. The console and the MCP surface for external agent frameworks are prototypes and are not connected to the governed read path. The sales assistant does not use governed data. | data.governed_read.v1 (Enterprise add-on, scope stated here; whether it is issued now is still open). The MCP surface would be data.governed_read.mcp.v1, not issuable yet. Draft. |
| Isolated execution | Not available | Would let a worker run commands or code in an isolated guest, away from the host. It is not built: nothing runs in isolation today, and a request that requires isolation is refused with HELIXOR_EXECUTION_ISOLATION_UNAVAILABLE. It ships only with a test proving a command in the guest cannot touch the host. The sales assistant runs no commands. | exec.isolated.v1, not issuable until the capability ships. Draft. |
Two rules apply to every row. A licence never grants a capability that is not built: entitlements for capabilities that are not available cannot be issued. And a capability marked Partial is sold with its scope stated, as it is here.
Related#
How agents work
Goals, perception, strategy under constraints, action and outcome learning, mapped to the sales assistant.
Tutorial · PreviewHow the sales assistant was built
The build walkthrough: heads, playbook, grounding, the gate and parity-first engineering.
Try itTalk to the sales assistant
Hold a conversation and see each turn's decision.