NOBODY OPENS
EITHER SYSTEM.
Marketing works in one CRM, enterprise sales in another, and the same customer carries two lifecycle stages. Syncing harder only makes the two systems disagree more precisely. The answer is not a third screen.
TWO SYSTEMS. TWO TRUTHS.
The setup is common enough to be boring: a marketing hub where campaigns, forms and lifecycle stages live, and a corporate CRM where enterprise sales runs its opportunities. Between them, a bidirectional sync with field mappings and conflict rules that one person understood in 2024.
It breaks quietly. A lifecycle stage moves in one system; a workflow in the other moves it back. Now the person answering the customer's email sees one stage and the account executive sees another, and neither has a reason to doubt the screen in front of them. Nobody notices until the customer gets two different answers in the same week.
Mapping more fields does not fix this, because a sync moves values — it does not decide which one is true. That decision needs somewhere to live, and neither CRM can be that place: both are built on the assumption that they are the system of record.
ONE GRAPH. NO SCREENS.
Both records, one account
Each system's record becomes an object in the Context graph, with a typed edge to the company it describes and a record of where it came from and when it was last written.
The account is no longer a field in whichever window you happened to open. It is an object with a history that can be read, cited and disagreed with.
The interface is the agent
CMP42 ships no forced UI. You ask the question where you already work — Claude, ChatGPT, Cursor or your own client — and the agent reads the graph through MCP tools, then names the objects it read.
That is the actual resolution: not a third dashboard reconciling the other two, but nobody needing to open either. Headless →
Writes that say who wrote them
Every write records whether a human or an agent produced it, and a Process can hold a change for approval before it counts.
When two sources disagree, the graph does not hide it. It shows both, with timestamps and origin, and keeps the decision that settled it.
THE ACCOUNT IS THE OBJECT.
Your ontology decides how a record from each system is typed and what it may claim. The sketch on the right illustrates the idea: one company, two source records, each carrying its origin and the moment it was last written.
Models are validated at write-time, so a record arriving with a stage your ontology does not have gets a clear error instead of quietly inventing one. How Models work →
# illustrative - the idea, not the final syntax
account:
fields:
stage: enum[lead, mql, sql, opportunity, customer]
decided_by: enum[human, agent]
edges:
for: company
mirrors: source_record[] # one per system of origin
source_record:
fields:
system: string # where it came from
stage: string # what that system believes
written: datetime # when it last changedWHICH STAGE IS TRUE?
A question nobody answers by opening a CRM
A fictional B2B team running a marketing hub alongside a corporate CRM. The steps show how the concepts fit together — it is not a customer story, and details of the interface will change during Alpha.
- A prospect replies to a campaign. Marketing moves the contact to MQL in the marketing hub.
- Enterprise sales already has that company as an open opportunity at a later stage in the corporate CRM, entered by an account executive three weeks earlier.
- Both records exist in CMP42 as objects, each with a typed edge to the same company and each carrying its origin system and the time it was last written.
- Before the call, the account executive asks her agent which stage is true for this account. The agent reads the graph through MCP and answers with both records, their timestamps and their origin — and names the objects it read.
- She decides which one holds. A Process records the decision and that a human made it. Neither CRM was opened.
WHAT THE ALPHA DOES — AND DOES NOT.
This page describes a way of working, not a connector catalogue. CMP42 is in Alpha, so here is the line between the two, in plain terms.
What works today
- Objects come in by import. CSV import for contacts, companies, deals and notes ships as a built-in mapper; anything beyond it is migrated with founder support inside the Design Partner Program.
- Your ontology decides the typing. Records from either system are shaped by your Models, validated at write-time.
- Agents read and write through MCP tools, with REST and GraphQL parity for everything else.
- Every write is attributable and can be held for human approval.
What is not there yet
- There is no live bidirectional connector. The one-click HubSpot API connector with OAuth arrives with the Beta in Q1 2027.
- A corporate CRM connector is not on the published roadmap. If your setup depends on one, tell us before you assume a date.
- The self-hosted image is published with the Beta in Q1 2027. Self-hosting →
- No numbers on this page. Alpha begins in October 2026; measured results will come from Design Partner case studies or not at all.
THE DISAGREEMENT STAYS VISIBLE.
A context layer does not make two systems agree. It makes the disagreement legible, dated and attributable — and it moves the answer out of whichever screen someone happened to trust. Why we built it this way →
Bring the two systems to the call
Design Partners shape the tool surface during Alpha. If your setup is two CRMs and a sync nobody trusts, that is a useful thing for us to build against.
→ Apply to be a Design Partner- Both systems keep running. CMP42 sits beside them; it does not ask you to migrate first.
- The answer cites its objects, so a wrong answer can be traced instead of argued about.
- Your team keeps its tools. Claude, ChatGPT, Cursor or your own agent — no new interface to adopt.
- Managed in the EU or self-hosted. On the managed tier CMP42 does not train on your data. DPA on request.
- Lean by default. Extending the ontology is explicit, so the graph does not fill up with fields nobody reads.