CRM-as-source-of-truth is not a feature. It's a tax bill.

Pick any CX-AI vendor's site. Find the architecture diagram. The agent will be in the middle. Their dashboard, their analytics, their data layer: everything orbits around the vendor's platform. Your CRM will be in the corner with an arrow pointing at it labeled 'integrates with.'

This is not an aesthetic preference. It is the vendor's commercial moat. When the customer record lives in the vendor's data layer, switching costs rise every month. The longer you run the agent, the more customer history they hold, the more your analytics depend on their dashboard, the more your team is trained on their interface. By the third year, the contract negotiation has shifted entirely toward the vendor.

When the customer record lives in the vendor's data layer, switching costs rise every month. The vendor knows this.

The flipped architecture

CRM-as-source-of-truth is the choice to invert that diagram. The customer record stays in Salesforce, HubSpot, Zendesk, Epic, Mindbody, ServiceTitan, or whichever system the team already lives in. The AI agent reads from it and writes to it natively. The vendor's data layer is, deliberately, a thin one: operational telemetry, model logs, billing meter. No customer records.

The benefit, for the customer, is portability. If you fire the vendor, your records stay where they are. If you switch CRMs, you switch CRMs (not vendors). The agent leaves no shadow data layer behind. The contract negotiation in year three is symmetrical.

The cost, for the vendor, is real engineering. Every CRM has its own API surface, its own schema, its own quirks. Native integration with Salesforce is one thing; native integration with Epic, Mindbody, ServiceTitan, Tekmetric, and forty others is another. There is no shortcut.

Why most vendors will not do this

Pulling customer data into your own cloud is, frankly, easier. One canonical schema. One source of truth that you control. One dashboard. One analytics pipeline. Your engineering team builds against one thing instead of forty. Your product team designs against one model instead of accommodating Epic's foibles and Tekmetric's quirks.

It is also, frankly, more profitable. Customers who cannot leave pay more. Customers whose analytics depend on your dashboard renew the contract. Customers who would have to migrate their customer history to switch vendors usually do not switch.

We have made the other choice because we do not believe the long-term equilibrium of this market rewards lock-in vendors. The buyer wakes up to it eventually (usually in a procurement review around year three) and the market shifts. We would rather build the architecture the market will want in three years than the architecture that maximizes near-term renewal.

What this looks like in practice

A booking confirmation in a clinic: the agent reads the patient record from Epic, checks availability in the clinic's PMS, applies the practice-specific scheduling rules, writes the appointment back to Epic, and writes a clean intake note to the same record. The morning team opens Epic, not Vorel.

A service appointment in an auto shop: the agent pulls the VIN from Tekmetric, checks bay availability, holds parts inventory, books the slot, and writes the customer note. The writer opens Tekmetric in the morning. Vorel does not store any of this.

A dispatch in a plumbing crew: the agent reads the technician schedule in ServiceTitan, applies the routing rules, dispatches the call, and writes the job and the customer note. The dispatcher works in ServiceTitan. Vorel writes the row and gets out of the way.

What we keep

Operational telemetry: model logs, latency traces, tool-call results, SLA tracking. This is real, useful data, and we retain it for ninety days under a strict no-PII policy. Customer records are redacted out before the telemetry is written.

Billing meter rows: what got resolved, what handed off, what cost what. These are the per-case ledger rows that flow into the customer's invoice. They reference the CRM ticket ID but do not duplicate the ticket itself.

Model training opt-in (off by default). We do not train on customer data unless the customer has explicitly opted in. If they do, the training data is theirs to revoke and we redact derived models on request.

Everything else lives in the CRM the team is already using. That is, deliberately, our architecture, and it is the single most important commercial decision we have made about how to ship this product.