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 |
| Channel eligibility | The permitted channel set is computed per contact per attempt from jurisdiction, consent and preference, then intersected with what the worker can do. A worker never picks a channel it is not allowed to use, because it never sees one |
There is a version of this platform where voice is the product and everything else is a convenience. That version does not survive contact with the world. Some markets restrict or effectively prohibit cold outbound voice. Some restrict internet telephony specifically. Some contacts have consented to email and nothing else. Some enterprises forbid recorded calls as a matter of policy. In every one of those cases the behaviour is the same: the worker uses text, messaging or email instead, and pursues exactly the same objectives on the channel it is permitted to use.
A worker whose objectives are stated in terms of a channel is a bot for that channel, and every new market becomes a new build. A worker whose objectives are stated as outcomes runs wherever it is allowed to run, and a regulatory change becomes a configuration change rather than a project.
Timing changes shape, because an asynchronous exchange reaches an outcome over days rather than in one sitting. Cue extraction degrades, because text cannot carry hesitation or tone, so a text led market yields thinner intelligence per interaction. And a voice score and an email score measure different things, so channel is a dimension of scoring rather than a footnote.
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 never speaks Salesforce. It speaks its own model, and an adapter translates.
That sentence is the whole design. The temptation in every integration project is to let the first system's vocabulary leak upwards, because the first connector is always written against a real system with real field names and it is quicker to just use them. The cost arrives with the second connector, when the platform is full of assumptions that were never true of anything but the first.
And two systems of the same brand differ more than two brands do. Two Salesforce orgs, both fifteen years old, in the same industry, will have different record types, different required fields, different validation rules and different meanings attached to the same picklist. So field and value mapping is versioned configuration per customer rather than code, diffable, because a mapping change is the most likely cause of a sync defect and "what changed" has to be answerable in seconds.
Read organisations and people with stable identifiers, write an activity, resolve an identifier to a current record, and accept a suppression or preference change. A system that cannot do these is not a connector. That last one is non-negotiable: a person who asks not to be contacted must be honoured in your own system, not just in ours.
Opportunities, leads as a separate object, campaigns, account teams, custom objects, bulk operations, a change feed, metadata discovery, a sandbox. A connector declares what it supports and the platform adapts, so an absent change feed becomes scheduled polling with the latency reported honestly rather than hidden.
| Platform | Shape | What actually bites |
|---|---|---|
| Salesforce | OAuth with a connected app and a certificate-based server flow, REST for interactive work, bulk for volume, metadata discovery rather than assumed fields, and change data capture where enabled | Sharing and visibility, so a connector that looks like it is missing half your accounts is usually under-permissioned rather than broken. Validation rules that reject writes. Record types changing what a field means. Person Accounts breaking the account-and-contact assumption. And an org-wide API allocation shared with every other integration you run |
| Dynamics 365 | Microsoft Entra ID with an application user scoped to what the connector actually needs, the Dataverse Web API over OData, alternate keys for clean upsert, and change tracking with delta queries | Service protection limits that return a retry instruction, which must be honoured precisely rather than retried aggressively. Publisher prefixes on custom columns, so field names are not guessable and metadata discovery is mandatory. Business units and hierarchy security as the equivalent visibility trap |
| Zoho | OAuth with a server-based application, REST over modules, and asynchronous bulk jobs that produce a file rather than an inline response | The data centre is part of the identity: an account lives in a specific region and both the authorisation and API hosts differ accordingly, so getting it wrong produces failures that look like bad credentials and are not. And webhook subscriptions expire and must be renewed, so renewal is a scheduled job with an alert rather than something set up once |
| HubSpot and the mid-market | The same contract. HubSpot's association model is closer to our graph than a classical CRM is | Which makes it a good second adapter for proving the canonical model rather than a hard one |
| Not a CRM at all | Listing platforms, origination systems, servicing systems, professional services tools | Frequently tier one and little of tier two, which the design handles by degrading rather than refusing. This is the case the contract exists for |
A worker can connect to Workday or a comparable system for one narrow purpose: keeping the account team accurate. A rep who leaves should stop being routed escalations, their instructions should expire, their pairings should close, and nobody should be offered a meeting in a calendar nobody is watching. Availability and leave matter for the same reason.
A sales worker keeping its team roster accurate reads employment status, role, manager, work contact details, location and leave windows, and nothing else, because nothing else is needed. A recruiting or onboarding worker reads offer terms, compensation, benefits elections and beneficiary designations, because that is the job. The field set is derived from the declared purpose and enforced at the adapter, so data outside it never enters the platform rather than being filtered later. Sensitive classes are off by default and granted deliberately, with a named grantor, a stated basis and a review interval.
The Hub never writes to a human being's record in a workforce system. Employees are a distinct class of person with their own classification, and they are excluded from outbound list resolution in the query layer rather than by a filter somebody remembers. There is no configuration that puts a colleague on a prospecting list. Two further controls matter more here than anywhere: identity verification before disclosure, to a standard set by the data class, and directional disclosure, because discussing someone's leave balance with them and with their manager are two different grants.
The reverse direction, and the more interesting one. A workforce system is not only a source of facts about people. It is where your approval, budget and lifecycle machinery already lives, and a virtual worker can be provisioned and managed through it rather than beside it.
A role holder with a position, a manager, a start date, a job family and a cost centre, managed by HR through the same processes as a person, and appearing in headcount and the org chart. This is what makes fleet supervision feel natural to the people doing it.
A licensed capability with an owner, a lifecycle and a renewal cycle, managed by IT or procurement through a service catalogue and an asset register. Keeps headcount metrics clean and avoids a set of questions some organisations would rather not open.
Neither is more correct, so it is configuration rather than an assumption. And the questions are worth naming: representing virtual workers as personnel records affects headcount ratios and the metrics built on them, may attract employee representation interest where co-determination regimes apply, and in some regulated contexts raises disclosure questions about who or what performed a function. Choosing the asset model to avoid all of that is a legitimate decision rather than an evasion.
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.