The questions buyers ask first.

A working conversational demonstrator of the B2B inside sales representative, covering live voice and typed chat across sixteen languages, with procedural objective ladders across eight enterprise scenarios, a structured outcome contract, agent versus agent simulation, a scored evaluator and a coaching loop that proposes prompt improvements. A second demonstrator points the same machinery at property operations in a different industry and language set, which is the portability proof. The Hub described across these pages is the platform being built around that core, and pages are explicit about what is designed rather than delivered.

Both, deliberately. The Hub is the platform: a governed runtime, a channel fabric, a calibration subsystem, a control plane and a governance regime. A worker is the product you actually buy, because a runtime is not something a sales director wants to purchase. The first worker is the inside sales representative, and others are commissioned on the same engine rather than built separately.

Most tools in that category do one of two things: build lists, or dial at scale. Neither navigates an organisation, earns a warm introduction, builds account intelligence over months, or recognises an opportunity while it is still an internal conversation. They also lock a conversation to the channel it started on, model contacts as flat records rather than stakeholders in a hierarchy, and bundle a CRM you already have. The differences that matter most are unified cross channel conversation state, an objective ladder that cannot be skipped, governed knowledge underneath the answers, and a scored improvement loop.

Into a relationship graph of organisations, people, positions, budgets and initiatives, with typed, dated, sourced connections between them. Not a pile of contact records. That distinction is what makes it possible to hold a role before you know who fills it, to keep a champion's relationships when they change employer, to trace a referral chain with the permission secured at each hop, and to ask who influences the person who controls the budget an initiative would draw on. Sentiment and influence are dated assertions with a source rather than fields, so a rating always resolves back to the conversations that produced it. The intelligence system is described here.

As work lists, which are a first class thing alongside tasks and processes, described on three independent axes. Origin is where it came from: a target account book, an intelligence operation, an event or marketing campaign, observed activity on your website, or a cold import. Cadence is how often it is worked, including a date anchored shape that moves when the event moves. Lifespan is how long the list itself exists: ephemeral, temporary with an enforced expiry, or maintained with a named owner. Origin determines the objective and the lawful basis, so a person who downloaded a specification yesterday is never opened as a cold call today. The full model is here.

It expires, and the expiry is enforced by a job rather than by somebody remembering. Rows that were never worked are deleted rather than archived, because there was never a reason to hold them beyond a contact that did not happen. What was learned in an actual conversation survives, on its own separate lawful basis, with its own retention and subject rights. That distinction matters: conflating the two is exactly how organisations end up keeping purchased data forever by declaring that it "became CRM data", and holding origin and expiry on the row rather than on the file removes that move.

Yes, and those are two different origins with different rules. Event work is five lists over one population, being invitation, registration chase, confirmation, attendance reconciliation and follow up, each with a window that closes, all anchored to the event date so a postponement reschedules everything automatically. Website activity, being a gated download, a demonstration request, repeated pricing page visits or an abandoned chat, enters at high priority with a sharp decay, because the measure there is time to first contact rather than coverage. One caution we state up front: a page view is anonymous until somebody identifies themselves, and identifying the visiting organisation from network data is an account level signal that may raise priority, never a basis to contact an individual.

That is a configuration choice with two answers, and most deployments use both. In the delegated model the worker extends the capacity of named sellers and its targets are their goals, narrowed to the accounts it covers and recomputed rather than copied, so a territory redraw moves accounts and the numbers follow with nobody reconfiguring anything. In the chartered model it holds a remit from the business itself, such as two hundred qualified opportunities a quarter in the mid-market, and behaves as an internal service provider whose output a seller consumes rather than as their subordinate. The difference settles who is accountable and who may redirect it, and it is usually visible in who signs for the deployment. The full model is here.

Two kinds of conflict, two different answers. Capacity conflicts, being competition for the worker's hours, are settled by a declared allocation with floors rather than by ranking, because ranking starves whatever comes second and nobody notices until a quarterly number is missed. Sixty percent to a coverage charter and forty percent across the reps it supports, say, with urgency reordering work inside an allocation but never eating another one. Directional conflicts, where two goals want contradictory behaviour on the same account, are settled in favour of the more restrictive goal and always escalated: acting on the ambitious goal when a restriction exists damages a relationship and that is not recoverable, while a missed opportunity is. The worker never settles a directional conflict itself, and conflicts are detected when a charter or instruction is registered rather than found later in a number that does not add up.

Salesforce, Microsoft Dynamics 365 and Zoho are the named platforms, with HubSpot and the other mid-market tools on the same contract. The important part is that the Hub never speaks a vendor's vocabulary: it has its own canonical model and an adapter translates, so the second connector does not inherit assumptions that were only ever true of the first. Field and value mapping is versioned configuration per tenant rather than code, which matters because two fifteen-year-old Salesforce orgs in the same industry differ from each other more than Salesforce differs from Dynamics. The contract also covers systems that are not CRMs at all, which is the normal case in property, lending and services, and it degrades in defined ways when a system cannot do something rather than failing.

No, and that is designed rather than hoped. Every one of these platforms limits how much you may call it, the allocation is shared with every other integration you run, and spending it would cause an outage in systems that have nothing to do with us. So the platform models an API budget per connector and enforces it like the cost meter, with live consumption, a projection and thresholds that act. When consumption approaches the limit it sheds load in a declared order, being reconciliation sweeps first, then polling frequency, then non-urgent writes, and never suppression.

Yes, in two directions. Reading, to keep 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 their calendar. The declared purpose determines the field set. A sales worker maintaining a roster reads employment status, role, manager, work contact details, location and leave windows, and nothing else. A recruiting or onboarding worker reads offer terms, compensation, benefits elections and beneficiary designations, because that is the job. The set is enforced at the adapter so anything outside it never enters the platform, sensitive classes are off by default and granted deliberately, and two controls matter more here than anywhere: identity verification before disclosure, and directional disclosure, since discussing someone's leave balance with them and with their manager are two different grants. Employees are also structurally excluded from any outbound list rather than filtered out. And provisioning, which is the more interesting direction: your HR system is where your approval, budget and lifecycle machinery already lives, so a virtual worker can be requisitioned, approved, provisioned, onboarded, supervised and terminated through it. One practical note: HR systems are scheduled rather than event driven, so a leaver is detected by comparing snapshots, and for that case specifically your identity provider is faster and more authoritative, so we watch both.

Exactly what you have granted, and nothing is switched off in the product itself. Privileged activities such as pricing, discounting, contractual terms, delivery commitments, transaction execution and access to sensitive personal data are off by default and granted deliberately, on a five grade scale: not granted, propose only, act with approval, act within limits, or act freely. Every grant carries a grantor, a scope, a ceiling where value is involved, an expiry and a review interval, and a grantor cannot confer authority they do not themselves hold. We avoided hard prohibitions on purpose, because a hard coded rule against quoting is a bet that nobody will ever have a legitimate reason to negotiate, and that bet loses. What survives is an invariant: a worker never authors a commitment, it sources one from a term sheet, a pricing engine, an approval workflow or a person. Delegation is bounded and revocable, taking effect on the next call rather than the next release, and you remain accountable.

It can run the conversation and it never signs anything. On a renewal it confirms intent, checks the person has authority to say so, conveys terms an authority produced, asks your order system to generate the paperwork and your signing system to send it, notifies the team, chases, and captures a warranted confirmation of intent. It does not execute the order, generate the contract or hold a signature. Where it holds no pricing authority a request for different terms is a variation and escalates. Where you have granted pricing authority, the same request routes to your pricing system and it conveys the approved answer, which is what makes real negotiation possible without it ever inventing a figure. A confirmation of intent is evidence of what a person said, never evidence that a contract exists.

Architecture rather than policy. An event never causes a call. It can only create or reprioritise a piece of work, and all outbound contact passes through a dispatcher that applies the caps, spacing, compliance and suppression checks before anything is sent. So the worst a bulk update, a migration or a replayed week of webhooks can do is fill a queue, which is visible, throttled and reversible. Three further defences sit in front of that: many changes to one account inside a short window collapse into one re-evaluation, a connector running far above its expected rate is paused rather than believed, and a change touching a large share of your records is reported as one thing that happened rather than deriving thousands of consequences.

Yes, and competitor watch lists are the main case. A work list declares a work type, being conversation, research, enrichment, verification or review, so a competitor or regulator list lives in the same machinery as a prospecting list with no possibility of anyone dialling it. Research items produce observations into the relationship graph without any outbound attempt at all.

The worker uses text, messaging or email instead and pursues exactly the same objectives. Channel availability is a property of the market and the contact rather than of the worker, computed per attempt and intersected with what the worker can do. This is deliberate rather than a fallback: objectives are stated as outcomes rather than in terms of a channel, so a regulatory change is a configuration change. The honest costs are that asynchronous exchanges reach an outcome over days rather than in one sitting, and that text carries no tone, so a text led market yields thinner intelligence per interaction.

No, and you should not. The Hub is not a CRM and never writes over the top of one. It integrates bidirectionally: contacts, opportunities and entitlements come in, and outcomes, qualification updates, stakeholder changes and intelligence go back out with provenance attached. The same interface serves systems that are not CRMs at all, which matters because in many industries the system your team lives in is a listing platform, a servicing system or a service desk. One thing worth knowing up front: the Hub deliberately holds more than your CRM does, because competitors, regulators, advisers and vacant positions have nowhere sensible to live in most CRMs and pushing them there degrades your own data. What flows back is what a CRM is built to hold.

Three things, in order. The conversation is scored automatically and, if it falls below threshold or returns a risk finding, written to a failure ledger with the transcript, the exact prompt layer versions in force and the engine bindings used. The failure is classified as behavioural, knowledge, asset, capability, configuration or compliance, which routes it to whoever can actually fix it. Then a revision is proposed with the evidence attached, a person approves or rejects it, and nothing reaches production until it passes regression against a saved scenario suite. A compliance failure is escalated immediately rather than queued.

The guardrails prohibit pricing commitments, outcome guarantees, and anything construable as legal or regulatory advice, and those live in the kernel prompt layer which a customer configuration cannot weaken. Where a worker is granted transactional capability, transactions form their own safety class: an idempotency key generated at intent so a retry never becomes a second charge, two phase execution, an explicit confirmation restating the terms, a value ceiling above which it must escalate to a named person, a declared reversal path, and a signed record of what was offered and agreed.

At the platform, before the worker is invoked. Every outbound number is checked against the applicable registries and blocked at the orchestration layer. AI identity disclosure is injected rather than instructed. Consent is recorded per contact and per purpose in an immutable ledger. Calling windows are enforced per jurisdiction and timezone. The depth of conversation record is selected automatically by jurisdiction and consent status, and cannot be set below the configured minimum. An instruction in a prompt is a preference; a check in the orchestration layer is a control.

Recording is available as the highest capture level and requires explicit, informed and separately obtained consent, disclosed before recording begins and repeated if a third party joins. A contact who declines still gets the conversation, at the next capture level down, with the refusal logged and honoured on every future interaction. The purpose travels with the recording: "for training and review" permits quality review, coaching and calibration, and does not by itself permit use as dispute evidence, third party model training, or retention beyond the stated period.

No. Scored conversations improve prompts, knowledge, assets and skills, all of which are versioned artefacts you own and can inspect. They do not become weights. We also do not use scores as a reward signal for automated optimisation, because optimising against a proxy is how a system learns to score well rather than to work well.

Authorisation is relationship based rather than role based alone, because almost every rule here is relational: a seller sees their own accounts, a manager sees their team's, a person can always read their own coaching record. Features are modelled as resources too, so a capability requires both a commercial entitlement and an organisational permission, checked in that order at the API. Workers are principals in the same model, which is how the rule that a worker cannot modify its own prompt or compliance configuration becomes a technical fact rather than an instruction.

Under a week for the core configuration: tenant, the worker's own workspace account, system of record connection, channels, agent template and voice, engine profile, client prompt layer, qualification framework, target accounts, compliance rules for your jurisdictions, flows and scenarios, and a calibration baseline. Knowledge and intelligence population run in parallel over a longer period and deepen continuously afterwards, because a worker is only as good as its scope.

Cost is captured per interaction and attributed by worker, task class, channel, language and scenario, so you get cost per conversation, cost per booked meeting and a projected cost per worker per month rather than a token bill you have to interpret. Budgets are enforced rather than merely reported, with a soft threshold that warns and a hard threshold that degrades, queues or escalates. A live conversation is never terminated by a budget, because quota is evaluated when a conversation starts and never mid turn.

Sixteen today, with detection and following handled as a runtime service rather than agent logic, including correct gendered grammar and politeness registers where a language requires them. The transcript is kept verbatim in the language actually spoken, and a parallel translation is produced in your record language so structured fields and CRM evidence stay consistent. Both are retained, always, because the verbatim text is the evidence and the translation is the working artefact.

Yes. Methodology is loaded as governed content rather than written into logic. BANT, MEDDPICC, SPIN and Challenger ship as standard, and a proprietary approach is loaded the way you would load a product datasheet. The qualification engine stores against a comprehensive schema while the interface relabels, so choosing a different framework changes what your team sees rather than requiring a change to the backend.

Model and voice are configuration, bound during setup or from the administration screen and never in code. Google is the first provider for both, with ElevenLabs as the named voice alternate, and moving between them is a setting rather than a migration because Corvair always owns the conversation loop itself: the voice interface is speech in and speech out, and the objectives, guardrails and outcome contract stay ours in either case. Each worker carries an engine profile binding a model class and a thinking budget to each task class it performs, because live conversation and analytical depth are opposing requirements that should never share one setting.

Your artefacts are yours. Worker definitions, knowledge, assets, skills and warrants are versioned, inspectable objects, expressible in an open portable format, and cancellation suspends provisioning while preserving them. We would rather earn renewal on delivered value than on the difficulty of leaving.