NIEMAND SCHAUT
IN BEIDE SYSTEME.
Marketing arbeitet in einem CRM, der Enterprise-Vertrieb in einem anderen, und derselbe Kunde trägt zwei Lifecycle-Stages. Mehr Sync sorgt nur dafür, dass beide Systeme präziser widersprechen. Die Antwort ist kein drittes Fenster.
ZWEI SYSTEME. ZWEI WAHRHEITEN.
Der Aufbau ist so verbreitet, dass er langweilig ist: ein Marketing-Hub für Kampagnen, Formulare und Lifecycle-Stages, daneben ein Konzern-CRM, in dem der Enterprise-Vertrieb seine Opportunities führt. Dazwischen ein bidirektionaler Sync mit Feld-Mappings und Konfliktregeln, die eine Person im Jahr 2024 verstanden hat.
Es bricht leise. Eine Lifecycle-Stage wandert im einen System; ein Workflow im anderen schiebt sie zurück. Jetzt sieht die Person, die die Kundenmail beantwortet, eine andere Stage als die Account-Managerin — und keine von beiden hat einen Grund, dem Bildschirm vor sich zu misstrauen. Auffallen wird es erst, wenn der Kunde in derselben Woche zwei verschiedene Antworten bekommt.
Mehr Feld-Mappings lösen das nicht, denn ein Sync verschiebt Werte — er entscheidet nicht, welcher stimmt. Diese Entscheidung braucht einen Ort, und keines der beiden CRMs kann dieser Ort sein: Beide sind unter der Annahme gebaut, dass sie das führende System sind.
EIN GRAPH. KEINE FENSTER.
Zwei Datensätze, ein Account
Der Datensatz jedes Systems wird zu einem Objekt im Context-Graphen — mit einer typisierten Kante zum Unternehmen, das er beschreibt, und mit der Angabe, woher er stammt und wann er zuletzt geschrieben wurde.
Der Account ist damit kein Feld mehr in dem Fenster, das man zufällig geöffnet hat. Er ist ein Objekt mit Historie, das man lesen, zitieren und bestreiten kann.
Die Oberfläche ist der Agent
CMP42 erzwingt keine Oberfläche. Sie stellen die Frage dort, wo Sie ohnehin arbeiten — Claude, ChatGPT, Cursor oder ein eigener Client —, und der Agent liest den Graphen über MCP-Tools und nennt anschließend die Objekte, die er gelesen hat.
Das ist die eigentliche Auflösung: kein drittes Dashboard, das die beiden anderen abgleicht, sondern niemand, der eines von beiden öffnen muss. Headless →
Schreibvorgänge, die sagen, wer sie war
Jeder Schreibvorgang hält fest, ob ein Mensch oder ein Agent ihn erzeugt hat, und ein Process kann eine Änderung zur Freigabe anhalten, bevor sie gilt.
Widersprechen sich zwei Quellen, verbirgt der Graph das nicht. Er zeigt beide — mit Zeitstempel und Herkunft — und bewahrt die Entscheidung, die den Fall geklärt hat.
DER ACCOUNT IST DAS OBJEKT.
Ihre Ontologie entscheidet, wie ein Datensatz aus jedem System typisiert wird und was er behaupten darf. Die Skizze rechts veranschaulicht die Idee: ein Unternehmen, zwei Quell-Datensätze, jeder mit seiner Herkunft und dem Zeitpunkt der letzten Änderung.
Models werden beim Schreiben validiert. Kommt ein Datensatz mit einer Stage an, die Ihre Ontologie nicht kennt, gibt es eine klare Fehlermeldung, statt stillschweigend eine neue zu erfinden. So funktionieren Models →
# beispielhaft - die Idee, nicht die finale Syntax
account:
fields:
stage: enum[lead, mql, sql, opportunity, customer]
decided_by: enum[human, agent]
edges:
for: company
mirrors: source_record[] # je Herkunftssystem einer
source_record:
fields:
system: string # woher er stammt
stage: string # was dieses System glaubt
written: datetime # wann er zuletzt wechselteWELCHE STAGE STIMMT?
Eine Frage, die niemand durch Öffnen eines CRM beantwortet
Ein fiktives B2B-Team, das einen Marketing-Hub neben einem Konzern-CRM betreibt. Die Schritte zeigen, wie die Konzepte zusammenspielen — es ist keine Kundengeschichte, und Details der Oberfläche werden sich in der Alpha noch ändern.
- Ein Interessent antwortet auf eine Kampagne. Marketing setzt den Kontakt im Marketing-Hub auf MQL.
- Der Enterprise-Vertrieb führt dasselbe Unternehmen im Konzern-CRM längst als offene Opportunity in einer späteren Stage — angelegt von einer Account-Managerin drei Wochen zuvor.
- Beide Datensätze liegen in CMP42 als Objekte vor, jeweils mit typisierter Kante zum selben Unternehmen und mit Herkunftssystem und Zeitpunkt der letzten Änderung.
- Vor dem Termin fragt die Account-Managerin ihren Agent, welche Stage für diesen Account gilt. Der Agent liest den Graphen über MCP und antwortet mit beiden Datensätzen, ihren Zeitstempeln und ihrer Herkunft — und nennt die Objekte, die er gelesen hat.
- Sie entscheidet, welche gilt. Ein Process hält die Entscheidung fest und dass ein Mensch sie getroffen hat. Geöffnet wurde keines der beiden CRMs.
WAS DIE ALPHA KANN — UND WAS NICHT.
Diese Seite beschreibt eine Arbeitsweise, keinen Konnektor-Katalog. CMP42 ist in der Alpha, deshalb hier die Grenze zwischen beidem, in klaren Worten.
Was heute funktioniert
- Objekte kommen per Import herein. Ein CSV-Import für Kontakte, Unternehmen, Deals und Notizen ist als Mapper eingebaut; alles darüber hinaus wird im Design-Partner-Programm gemeinsam mit dem Gründer migriert.
- Ihre Ontologie bestimmt die Typisierung. Datensätze aus beiden Systemen werden durch Ihre Models geformt und beim Schreiben validiert.
- Agents lesen und schreiben über MCP-Tools, mit REST und GraphQL für alles andere.
- Jeder Schreibvorgang ist zuordenbar und kann zur Freigabe durch einen Menschen angehalten werden.
Was es noch nicht gibt
- Es gibt keinen Live-Konnektor in beide Richtungen. Der One-Click-HubSpot-API-Konnektor mit OAuth kommt mit der Beta im Q1 2027.
- Ein Konnektor für ein Konzern-CRM steht nicht auf der veröffentlichten Roadmap. Wenn Ihr Aufbau davon abhängt, sagen Sie es uns, bevor Sie ein Datum annehmen.
- Das Self-Hosted-Image erscheint mit der Beta im Q1 2027. Self-Hosting →
- Keine Zahlen auf dieser Seite. Die Alpha beginnt im Oktober 2026; gemessene Ergebnisse kommen aus Design-Partner-Case-Studies — oder gar nicht.
DER WIDERSPRUCH BLEIBT SICHTBAR.
Eine Kontextschicht bringt zwei Systeme nicht dazu, sich zu einigen. Sie macht den Widerspruch lesbar, datiert und zuordenbar — und sie holt die Antwort aus dem Fenster heraus, dem jemand zufällig vertraut hat. Warum wir es so gebaut haben →
Bringen Sie die beiden Systeme mit ins Gespräch
Design Partner gestalten die Tool-Oberfläche während der Alpha mit. Wenn Ihr Aufbau aus zwei CRMs und einem Sync besteht, dem niemand traut, ist das ein nützlicher Fall, gegen den wir bauen können.
→ Als Design Partner bewerben- Beide Systeme laufen weiter. CMP42 stellt sich daneben und verlangt keine Migration vorab.
- Die Antwort nennt ihre Objekte, sodass eine falsche Antwort nachvollziehbar wird statt diskutierbar.
- Ihr Team behält seine Werkzeuge. Claude, ChatGPT, Cursor oder ein eigener Agent — keine neue Oberfläche.
- In der EU betrieben oder selbst gehostet. Im Managed-Tarif trainiert CMP42 nicht mit Ihren Daten. AVV auf Anfrage.
- Schlank als Standard. Die Ontologie zu erweitern ist eine bewusste Entscheidung — der Graph füllt sich nicht mit Feldern, die niemand liest.