One contract worker handles inbound and outbound sales.
Direction, request type, commercial authority and campaign are independent configuration choices. An Industrial Sales role can answer customer enquiries and run outbound account development or surplus clearance on the same engine. A conversation may start inbound and create an agreed outbound follow-up; its buyer, worker, quote and negotiation history stay connected across channels.
| Work | Configured behavior | Completion evidence |
|---|---|---|
| Customer enquiry | Answer product, specification and compatibility questions from approved sources; refer uncertainty. | Source-linked answer or acknowledged specialist handoff. |
| Stock check and quote | Read current available-to-promise stock and the applicable price book. Prepare a time-limited quote within delegated authority. | Item/lot, stock snapshot, price-book version, commercial decision and quote reference. |
| Inbound order request | Verify buyer and agreement, capture items, accepted quote and delivery details, then hand off or submit through a granted intake tool. | Request receipt; a confirmed order requires an authoritative order-system acknowledgement. |
| Order status or unavailable part | Resolve authorized order status. If stock is absent, offer an approved alternative or raise an agreed new supply/order enquiry. | Current order reference or acknowledged new request. No invented stock or lead time. |
| Outbound account development | Contact eligible prospects, previous purchasers and distributors from a dated worklist; handle replies and schedule follow-ups. | Contact decision, conversation history, buyer response and agreed next step. |
| Surplus approaching scrap | Bind a campaign to stock lots, eligible buyers, sell-by deadline, planned scrap review, approved pricing and stop conditions. | Available, requested and confirmed quantities remain distinct; completed sales come from order receipts. |
Commercial authority is a reusable library. Default to fixed prices from the customer's effective price book, with value-led objection handling. Optional strategies include a quantity-conditioned concession or staged clearance negotiation. Version the strategy and bind the customer, products/lots, currency, minimum quantity, total discount ceiling, absolute floor, maximum rounds, quote expiry, milestone and approval owner. Goals such as resolving stock enquiries, progressing an offer, capturing an order request and clearing stock are reusable primary or secondary assignments.
The lowest permitted price is the stricter of the absolute floor and the total discount ceiling. Existing concessions, freight, payment terms, bundles and other economic benefits count toward the total authority. Negotiation history and rounds belong to the buyer/offer across channels; a new call cannot reset them. Hard limits, current stock and price freshness are evaluated by a deterministic authorized tool such as pricing.evaluate_offer, exposed through either a native adapter or MCP. A language-model strategy can propose a concession; it cannot grant one.
A scrap deadline creates urgency, not unlimited price flexibility. Fixed pricing may remain in effect throughout clearance. A staged playbook may permit concessions only after an approved milestone. Recheck stock and policy at each offer and acceptance; cap quote expiry by campaign close. Stop new offers on sell-out, suppression or sell-by expiry, reconcile outstanding commitments and escalate remaining stock. Scrap disposition remains a separately authorized business process. Do not invent scarcity or claim a reservation from an enquiry.
Client operations: Sales work shows inbound request types, outbound follow-ups, clearance progress, listed terms and pricing decisions needing attention. Clients can keep the listed price, refer a requested exception or prepare an order handoff. Hidden floors, negotiation instructions, internal approvals configuration and provider details stay in administration. Administration: configure coverage and sales playbooks separately from the outcome-billing contract. A product's selling price is not the fee for engaging a contract worker.
The first version demonstrates enquiry handling, current-record lookup, offer decisions, order intake and handoff through shared capabilities. Binding inventory allocation, order execution, payments and auctions require the relevant transactional adapters and grants. Neither a draft quote nor an order request constitutes a completed sale. The local preview simulates these records and sends no communications or orders.
Worker engagements: customers engage contract workers under worker contracts. “Contracted role” describes the reusable role covered by the agreement; assignment and capacity describe the deployed workforce.
One customer engages its workforce. A team organises the work.
The catalogue is global; worker contracts and worker instances belong to a customer tenant. Inside sales, property and industrial sales are the first three definitions, not three separate applications or tenant types. A customer may engage one contract worker today and several different roles later. The same engine, libraries, instance model and client workspace must support a hundred definitions without customer-specific code.
| Object | Responsibility | Relationship |
|---|---|---|
| Definition and version | Reusable role, goals, skills, data schema, capabilities and evaluations. | Published once in the catalogue; available to many customers. No customer data or credentials. |
| Customer tenant | Commercial ownership, users/memberships, workforce, isolation and customer controls. | Owns worker contracts, teams, deployments and instances. A country or department does not create another tenant. |
| Worker contract entitlement | Which worker role the customer has contracted, allowance, term, status and contract. | One customer can hold many; one entitlement may allow multiple separately configured instances. |
| Worker instance | Durable worker identity, assigned objectives, work, data access, conversations, memory, activity and outcomes. | Belongs to exactly one customer, references a definition/version and entitlement, and has a primary team assignment. |
| Team | Business ownership, reporting, assignments and explicitly shared collections. | Sales, accounting, safety or another customer-defined group. A team can contain several worker types or have no workers yet. |
| Deployment and operating profile | Environment, hosting/data location, operating coverage, country rules and provider bindings. | Technical axes independent of the team hierarchy. Any worker type can bind any supported, evaluated country configuration. |
Example: Northstar engages Industrial Sales contract workers and assigns two independent instances to Sales for different buyer groups. Its Accounting and Safety teams can exist without workers. Meridian engages Inside Sales and Industrial Sales contract workers; both types work in Sales. Later, either customer can add an Accounting worker from the same catalogue. The worker definition does not encode the customer, department or country.
Per-worker ownership: each instance has its own queues, activities, transcripts, records, memory, knowledge scope and attribution. Sharing a customer or team does not merge those histories. Customer identity resolution, contact preferences and suppression are common controls; only authorized projections expose related records. Published customer/team knowledge requires explicit grants. A cross-worker handoff transfers the minimum authorized context, with recipient, purpose and acceptance recorded.
Use tenant ID on every record, event, query and asynchronous job; add owning worker ID to private operational data. Team membership scopes access and reporting but is not a substitute for record grants. A team move changes assignment without changing the tenant or silently sharing private data. A cross-customer clone is a sanitised configuration copy with a new identity, never a data transfer.
Customer invoices consolidate the contracted roles and accepted outcomes under their agreements, with drill-down by team and worker. Internal provider cost and margin remain administrative views. Runtime state and draft configuration state are separate: changing an administrative draft does not interrupt or reconfigure the client’s running worker.
A configuration is a versioned product object.
Define once
Goals, skills, scenarios, knowledge schemas, tool capabilities and country profiles.
Compose and bind
Template versions, primary/secondary assignments, providers, tools, knowledge, authority and contract.
Run with evidence
Resolved configuration, contact decisions, tool receipts, outcome evidence and attributed costs.
Customer → worker contracts and teams → worker instances → configuration revisions. A deployment is a separate environment and hosting binding. A worker instance is a durable logical identity owned by the tenant and assigned to a team; compute replicas do not create another worker or another outcome fee. Customer, definition, team and country are independently selected during administration.
Templates reference published goal and skill versions. Instances bind customer data, knowledge, provider routes, credentials, country profiles and contracts. Each run records its resolved configuration. Library updates produce a diff and evaluation requirement; they do not silently change running workers.
New customer solutions require configuration. A genuinely new capability or integration is implemented once as a reusable adapter, tool or skill implementation. Customer-specific runtime forks are outside this model.
Goals define success. Skills define behaviour. Tools provide access.
| Library object | Required contract | Controls |
|---|---|---|
| Goal definition | Objective, parameters, inputs, success evidence, completion predicate, required skills, evaluation scenarios and fallback. | Version and provenance; conflicts, deadline and stop conditions. Financial acceptance stays in a separate outcome contract. |
| Goal assignment / objective set | Multiple primary objectives and multiple secondary objectives, each with priority/weight, applicability, dependencies, completion evidence, capacity allocation and outcome mapping. | The same definition may be primary on one worker and secondary on another. Resolve conflicts across the full objective set. Secondary work cannot displace mandatory policy handling or the agreed primary objectives. |
| Skill definition | Instructions, typed inputs/outputs, parameters, knowledge needs, capability dependencies, authority ceiling, budgets, retry policy and tests. | Portable SKILL.md imports are normalised, quarantined, reviewed and evaluated. A document cannot grant access or authorize arbitrary execution. |
| Tool capability | Stable semantic name and schema, such as records.lookup or crm.append_note, mapped to a native adapter or MCP tool. | Tenant credentials, data scope, explicit grants, idempotency, timeouts and receipts. Discovery is not a grant. |
MCP servers supply tool discovery and invocation. A connection records its owner, authentication binding, discovered schemas and enabled capabilities. Schema changes and new permissions require review. All tool execution passes through the same backend authorization and policy boundary, including native adapters. Any CVW management MCP surface must mirror the corresponding API authorization.
Imported instructions and tool descriptions are untrusted data. They cannot override country rules, disclose secrets, widen grants or alter billing evidence. Tool capabilities follow the MCP tools specification; CVW adds its own execution policy.
One learning system reviews every configured role.
Score each conversation transcript against its applicable primary and secondary objectives using a versioned rubric, with supporting transcript passages and authoritative tool receipts. Keep per-objective scores, uncertainty and policy failures visible; an aggregate cannot conceal a failed primary objective. Inapplicable objectives are identified explicitly. The same configurable scoring, review and improvement system serves industrial sales, inside sales, property and future roles.
Learning cycle: transcript and evidence → objective scores → review of gaps → proposed configuration improvements → regression tests → approved release. Reviewers can correct scores and propose changes to reusable goals, skills, knowledge or guidance. Record the scorer, rubric, evidence and configuration versions. Test changes against the relevant scenario library before promoting a new worker configuration; live workers do not silently expand their own authority.
Customer evidence remains in authorized data scopes. Shared learning reuses methods, rubrics and reviewed improvements without exposing one customer's transcripts to another. Quality scores remain separate from verified business outcomes and customer charges. The present mockup's single primary-goal selector is a simplification to replace with the full objective-set editor.
Country is a central operating profile.
The initial profile registry contains United States, Singapore, United Arab Emirates and Australia. A profile contains operational defaults and reviewed policy references. It is neither a country dropdown scattered through the application nor a blanket legal approval.
| Profile | Operational considerations | Review scope before activation |
|---|---|---|
| United States · US | Multiple IANA time zones and DST; state overlays; configured sender and provider capability. | Applicable federal/state contact rules, channel consent, suppression, disclosure, recording and sender requirements. |
| Singapore · SG | Asia/Singapore; configured language coverage and registered sender identities. | DNC applicability and exceptions, consent, messaging sender requirements, capture and retention. |
| United Arab Emirates · AE | Asia/Dubai; activity/authority context, approved numbers, evaluated Arabic/English handling. | Calling permissions, DNC, disclosure, recording, language and data obligations. |
| Australia · AU | Multiple IANA zones with state/territory overlays and differing DST observance. | DNC and contact rules, spam and sender requirements, recording and retention. |
Profile fields: country and subnational selectors, default languages and calendar, time zones, channel availability, provider priority, sender/number requirements, contact basis, consent and suppression sources, contact windows, frequency caps, disclosure/capture, retention and data-location constraints, escalation hours, evidence references and review ownership.
Inheritance: central profile → subnational/channel overlay → stricter customer constraints → instance bindings. Time zone, hosting region, recipient location, record language and contract currency remain distinct fields. One customer may target several countries through separately configured instances; each contact attempt resolves the applicable destination rules.
Publication: draft → review → evaluate → approved version with effective date → staged rollout. Missing mandatory answers block live activation. A central update shows affected deployments and a diff. Normal execution pins a version; urgent revocation and current suppression are checked at the next action boundary. Unknown destination or an unavailable mandatory check holds the action.
No numeric calling-window or consent entitlement is asserted by the draft profiles. Operational readiness requires review against applicable authoritative sources and current provider capabilities. Earlier demonstrations are evaluation references outside the initial operational profile set.
Telnyx is the default communications operations adapter.
Use Telnyx by default for number bindings, voice call control, media events, messaging, delivery receipts and provider usage attribution. CVW retains orchestration, worker state, policy, billing and telemetry. Telnyx does not become the tenancy or financial system of record.
A route binds customer + deployment + country/channel + sender + provider account + adapter version. Twilio and other providers are selectable alternatives where an adapter and the required capabilities have been evaluated. A selectable design option does not claim that the implementation is complete or that a carrier is ready in all four countries.
Voice and SMS can share a provider choice; email, web chat and optional messaging channels have their own adapters and eligibility. Normalize callbacks into delivery and conversation events. Verify webhooks, deduplicate events, reconcile provider IDs and costs, and enforce bounded retries and circuit breakers.
Fallback requires independent credentials, sender approval, capability checks and policy eligibility. A provider outage can cause a hold or escalation. It must not silently route traffic through another country or bypass consent and suppression.
Implementation references: Telnyx media streaming, call control commands, and number requirement groups. Confirm account- and market-specific availability during deployment.
Multiple instances are part of the first version.
Authorized administrators create, clone and independently configure instances under the customer’s worker contract entitlement and allowance. A clone receives a new ID and draft state, copying only selected configuration references. It does not inherit credentials, live grants, sender identities, contacts, work queues, conversation history, financial records or customer-specific secrets. Same-customer suppression and deduplication remain shared controls. Cross-customer cloning requires sanitised template content and complete rebinding.
Lifecycle: draft, validating, ready, active, paused/draining, suspended and retired; service health is a separate dimension. Pause stops new work and drains existing conversations within defined time/spend limits. Resume rechecks current eligibility. Suspend can revoke action authority immediately. Retire preserves required evidence and reconciles remaining work and charges.
Activation validates goals, skills, tools, country profile, sender and provider readiness, knowledge scope, customer roles, outcome contract, spend/capacity and evaluation results. A simulation may use fixtures and incomplete live bindings. A live activation may not.
Client operations shows the released brief, current activity, queued work, results and actionable blocks. Clients assign work, give business instructions, pause/resume and review decisions within their authority. Administration owns queue recovery, safe replay, contact locks, secret rotation, provider health, rollout/rollback, retention, backups and recovery. The client’s view of a service issue identifies business impact, owner and next update; its technical cause remains in administration.
Bill for an accepted outcome with evidence.
Keep three separate concepts: a quality score, a verified business outcome and a customer charge. A model may propose an outcome candidate. Independent CRM/order/calendar receipts establish the business event, and the customer contract defines verification, acceptance and the billable unit.
Ledger lifecycle: recorded → verified → accepted under the contract → billable → invoiced, with disputes, cancellations and reversals handled by appended adjustments. Deduplicate the business event across contacts where appropriate, channels, retries and instances. Attribute one owning worker according to a versioned policy; retain every contributing worker’s costs.
Contracts have effective dates, currency, unit prices, tiers/minimums where needed, acceptance windows, exclusion rules, cancellation/dispute terms, attribution policy and tax/export configuration. Use precise monetary units, idempotent ledger writes and a transactional outbox. Template or skill version changes cannot alter contracted rates.
The first version includes contract administration, evidence review, accepted/billable events, invoice drafts and exports, adjustments, payment status and reconciliation. External invoicing/payment software is a finance adapter, selected after validating its commercial fit. Provider COGS and customer charges remain separate; pricing need not expose token or carrier costs.
Attribute every cost, including failed work.
Attach tenant, deployment, instance, configuration, goal and skill versions, job, conversation, channel, provider route, tool, attempt, source event and trace IDs at execution. Capture model usage, voice, SMS, email, retrieval, external tools, simulations, evaluation, retries and failures. Shared infrastructure and storage use a versioned allocation policy. Unknown and unreconciled amounts are visible, not zero.
Diagnostic telemetry can be sampled; accounting cannot. OpenTelemetry traces explain latency and failures. Durable usage, cost, outcome and billing ledgers own financial evidence. Reconcile estimates to provider statements through adjustments, and distinguish direct cost, allocated cost, customer fees and margin. Redact sensitive content and restrict finance and trace access separately.
Budgets reserve capacity across concurrent work before execution. Enforce customer, deployment, instance and campaign limits, plus provider and tool rate limits. The contract defines any bounded grace for finishing an active conversation. Alert and hold new work when capacity is exhausted; do not promise unlimited scheduled work at zero balance.
Use the OpenTelemetry signal model for diagnostics. Do not place personal data, transcripts or secrets in trace baggage.
Clients run workers. Administrators configure the platform.
| Surface | What belongs here | What the user does |
|---|---|---|
| Client workspace | The customer’s workers and teams, agreed briefs, current work, queues, conversations, worker-specific data, business results and attention items. | Assign work, prioritise eligible tasks, give instructions, pause/resume, approve a business next step or take over a task. |
| Customer administration | Customer directory, worker contract entitlements, instance allowances, teams, memberships, scoped data grants and provisioning. | Configure any contracted worker role for a customer and team, choose its operating coverage and release a reviewed version. |
| Platform administration | Definition/goal/skill catalogues, MCP and native tool bindings, central country profiles, communications providers, telemetry, internal costs, outcome contracts and billing operations. | Publish reusable capabilities, certify operating bindings, diagnose failures, verify outcomes and reconcile charges/costs. |
Client entry point: the workforce workspace. Its navigation is Overview, Workers, Sales work, Work queue, Activity, Needs attention, Teams and Results. Worker detail shows Work, Activity, Data and Agreed brief. Team filters reveal only the selected customer’s workforce. A customer with one contracted role sees a normal small workforce, not the entire global catalogue.
Admin entry point: administration. It starts with the customer directory and worker contract model. Provisioning setup chooses customer, contracted role and team independently, then binds country, goals/skills, knowledge, tools, provider, contract and evaluation. The initial catalogue has three definitions; the searchable catalogue and entitlement model support many more without new application shells.
Translate blocks for their audience. “Requested terms need your approval” belongs in the client’s decision queue. “Outbound calling is temporarily unavailable; operations owns restoration” is a client-facing service update. Provider account failures, country-profile drafts, route IDs and raw policy decisions belong in the corresponding administrative incident. Do not show technical setup completeness as the client’s operational dashboard.
The preview customer selector and admin-preview links are outside the simulated product UI. In the real product, identity and server-granted memberships determine customer scope and access to separate administration routes. There is no unrestricted role toggle for clients.
Revise the design, then build one vertical slice.
- Design first. Align the console, setup and design pages on this object model, operational scope and four-country registry. This revision is a local prototype; publication is a separate delivery action.
- Build reusable service components. Reuse FastAPI/Cloud Run, PostgreSQL, Firebase verification, secrets, jobs/idempotency, structured events and release-owned migrations. Keep customer domain records, authorization and transaction contracts explicit.
- Build the common slice. Configuration libraries and instances, native authorization, country profile checks, contact/work state, one knowledge/CRM binding, Telnyx adapter, conversation/event model, outcome/cost ledgers and the revised console.
- Prove configurability. Run the same release with all three templates and two cloned instances. Evaluate inbound/outbound continuity, secondary goals, suppression, country selection, MCP grants, independent outcome evidence and billing reconciliation.
- Expand through reusable adapters. Certify additional countries, languages and providers; add transactional inventory/auction capabilities only when their domain contracts and tests are defined.
Storage: PostgreSQL owns operational and financial truth. A graph projection can follow when relationship queries justify it; graph infrastructure is not a prerequisite for the first common slice. Long-running voice connections and asynchronous jobs remain separate runtime concerns.