Mallín — One system at a given time

It's an easy architecture to draw and a quiet disaster to ship: the AI tool holds the authoritative copy of the rep's notes, with a "sync to CRM" arrow pointing outward. It looks clean. It creates a problem that compounds.

The moment a tool holds the source-of-truth copy of anything the customer's CRM is shaped to hold, the customer has two systems to reconcile. Even if the tool's UI is better. Even if the sync is reliable. The manager who spent ten years building MEDDPICC scorecards in Salesforce now has to ask: when the rep typed that note, did it land here, there, or both? When the dashboard says X, is X from the canonical source or a lossy mirror?

The principle that prevents the drift is simple to state and surprisingly hard to hold:

One system at a given time. The tool is where the rep works. The CRM remains the governed system of record.

Call it write-through. This post is about why it's worth the cost.

What write-through actually means

When a rep adds a note, that note doesn't live in the tool and also live in the CRM. It lives in the CRM. The tool's UI is the writing surface; the CRM is where the artifact persists. There is no tool-side authoritative copy.

The implication: the tool honors the CRM's existing governance. If the customer's admin set up a private-note flag, the tool exposes that flag in the write UI and passes it through. If a rep doesn't have access to a record, the tool doesn't show it. CRM permissions are the permission model. You don't invent a parallel one.

This sounds obvious. It is not how most AI products work. The default for an AI tool is to accumulate state in its own database — it's faster to build, easier to query, and lets you ship features without integration friction. The products that drift toward "we'll add CRM sync later" rarely add it. By the time they try, they've shipped a year of features that depend on tool-shaped data the CRM doesn't understand.

The way to prevent this is to make write-through a non-negotiable from day one, and to encode the rule somewhere a future engineer can't drift past it.

The eight checks

A useful way to keep it honest: treat every write surface — rep notes, deal-thread replies, manager-brief contributions, stakeholder updates, MEDDPICC writes, action-queue completions, email-composer logs — as having to satisfy eight rules before it ships. Make them PR-review-blocking.

Authority boundary. Every authoritative field writes to a CRM record. Not a tool-side table.
Sync visibility. The rep sees Syncing / Synced / Pending retry / Failed in real time at the surface. No silent saves, no hidden divergence.
Retry path. When sync fails, the surface shows what failed, why, and the action to fix. No failed write is silently abandoned.
CRM-governed permissions. Record-level, field-level, and private-note flags are honored. No parallel ACL.
No durable tool-side content. No field on a tool-side table that would lose authored rep content on delete. A simple test: if it can hold a sentence a rep wrote and would lose meaning when the CRM record is deleted, it's CRM-shaped and shouldn't live in the tool authoritatively.
Tenant boundary. Every read and write filters by tenant_id. No cross-tenant leak path. Row-Level Security at the database layer enforces it as defense in depth.
Deletion test. If the CRM record is deleted, the tool-side metadata becomes orphan. That's correct behavior. If deleting the CRM record would lose user data permanently, the surface is violating the doctrine.
No async authority drift. Sync is write-time, not batched ETL. Queueing is transport, not authority. A nightly sync job that holds writes for 24 hours is a parallel data plane with a 24-hour divergence window — it just hasn't been caught yet.

The shape of these checks matters. They're not aspirational principles. They're testable claims a reviewer can verify in a PR. If any box is unchecked, the surface isn't write-through and doesn't ship.

Where a tool can still have its own state

The doctrine doesn't say the tool can't store anything. It says it can't store authoritative rep content. There's a meaningful distinction.

A tool can — and should — hold:

Metadata about CRM records. When a rep tags a note as "cross-deal pattern," that tag is tool-side. The note itself still syncs to the CRM as a normal deal note. The memory layer carries the tag so the agent surfaces the right past notes on future similar deals.
Telemetry and operational state. Which features the rep uses, which briefs they open, sync retry counts, audit trails.
Computed intelligence. Pattern detection, confidence scores, surfacing rules, embedding-based lookups — anything that's derived from the CRM substrate, not a replacement for it.

The test is the deletion test from above: if you delete the CRM record this metadata refers to, the metadata is correctly orphan. The customer's authored content is intact in their CRM.

Why this is the thing that compounds

When people ask what's defensible about a revenue AI tool, the answer is usually "the model" or "the prompts" or "the data we collect." None of those are particularly defensible. Models commoditize. Prompts get copied. Data sets stay with the customer.

The thing that compounds is trust. And trust in this category requires architectural choices that look indistinguishable from operational competence: the CRM stays canonical, the rep's contributions stay attributable, the manager's view of the pipeline doesn't develop a parallel-truth problem because some notes lived in a different system.

A rep can switch between briefs all day and never have to ask "did that save?" Because the answer is always "it saved to your CRM, the same place everything else lives." That's not a feature. That's the absence of a problem most AI tools have.

The wrong turn that makes it concrete

The tempting version always looks like a better product first. The tool holds the authoritative note; the UX is tighter, the performance better. It looks like a real product. Then a buyer asks the casual question that ends it: "if I stop using this, do I still have all my notes in Salesforce?"

If the honest answer is "you'd have some of them, and the ones generated by the AI would be ours," the deal is over. It would have been over at signing, too — the buyer just hadn't thought to ask yet.

The fix is never as clean after the fact: rewrite the note storage to be CRM-first, build the sync-status UI so reps can see write-through happening in real time, add queued-retry behavior for offline cases, and write the doctrine down so no one quietly drifts back. That's the cost of write-through — more engineering, slower features, a harder integration story. The benefit is that you never have to convince a customer their CRM is still the source of truth. It just is.