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.

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.

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. 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.