Channels, systems, tools and skills. Plug in, do not fork.
An adapter is how the Hub reaches the world. Channels carry the conversation, systems of record hold the business, tools let a worker act, and skills package how a job is done. Every one of them sits behind a stable interface, and the single most important rule is that an adapter never owns conversation state. State, identity resolution and thread continuity stay in the Hub.
Most tools are multi channel but single channel per conversation: once a contact is engaged on a messaging app, that conversation lives and dies there. The fabric works at the server level instead, so a conversation can start in a message, shift to voice for the complex part, and return to text for scheduling, as one continuous thread.
| Capability | What the fabric does |
|---|---|
| Unified state | A single thread per contact spanning every channel, so the worker sees one continuous interaction regardless of where each part happened |
| Preference tracking | Learned from response patterns, time of day behaviour and explicit statements, then used to route new outreach where a reply is most likely |
| Automatic fallback | Unresponsive on the primary channel escalates to alternates on configurable timing and sequencing, per account or per contact |
| Voicemail handling | Detect and execute a configured strategy: leave a contextual message, skip to an alternate channel, or schedule a retry |
| Language routing | Detection and following handled server side, so the worker stays language agnostic at the logic level |
| Graceful degradation | Voice unavailable reroutes to text, a rate limited channel queues and switches, and every degradation raises a system event rather than failing silently |
The Hub never replaces your system of record. It enriches it. A virtual worker is only as useful as its ability to write back into the system its human colleagues actually live in, and in most industries that system is not a CRM at all.
The Hub standardises on the Model Context Protocol as the interface through which workers reach tools. That is not a preference about protocols. It is the decision that removes a category of integration work from every future worker.
End the interaction and file the outcome contract, transition to another channel, hand off to a human with full context.
Schedule a meeting, deliver an asset, raise a request onto the board, send a follow up, update a task.
Search, ask, browse the topic graph, run deep research, retrieve a premise chain, seal a warrant.
Read and write contacts, opportunities, activities, entitlements, listings and tickets, normalised per system.
A tool is a single capability. A skill is a packaged procedure: how to carry out a kind of work, which tools to use, in what order, with what judgement at each step. The ecosystem has converged on a portable format, which means a large body of published skills is already in a shape the Hub can read.
Skills written for a coding assistant or a desktop chat agent assume a filesystem, a shell, a patient user who can be asked a clarifying question, and no regulator. A worker on a live phone call has none of those.
Skills are bound to task classes, and the default is deny in conversation. Most are far too slow for a live turn, where the budget is a few hundred milliseconds.
Booking a ticket, confirming attendance, registering a contact, converting an anonymous visitor to a signed in user, upgrading a member tier, extending content access. These are what make a virtual worker commercially load bearing. They are also what can do real damage, so they form their own safety class.
| Rule | Requirement |
|---|---|
| Idempotency | A key generated once at intent and reused across every retry. Agentic systems retry, so without a key a retry becomes a second charge. The most consequential requirement in the class |
| Explicit confirmation | The worker states back exactly what is about to be committed, and requires an unambiguous affirmative. Consent is never inferred from conversational momentum |
| Two phase execution | Reserve or hold first, then confirm. A dropped call between the two leaves a reservation that expires, not a half completed sale |
| Authority bounds | Value ceilings and permitted transaction types per worker and per scope. Above the ceiling, escalate to a named human rather than proceed |
| Compensation path | Every type declares its reversal: cancel, refund, downgrade, release. The worker knows the path before it commits |
| No credentials in conversation | Never card numbers by voice or message. A hosted payment or verification link instead, which keeps the platform out of credential scope entirely |
| Warranted | Every commitment sealed with a signed, replayable record of what was offered, agreed, known and authorised |
The conversion ladder and the meeting ladder are the same object. Only the rungs and their scores differ, and those live in the worker definition rather than in the runtime.
Every conversation is scored, failures are classified as defects with an owner, and nothing reaches production until it passes regression against a saved suite.