IHRE ONTOLOGIE.
VERSIONIERT WIE CODE.
CMP42 bringt sinnvolle Standards für die CRM-Grundbausteine mit — Kontakt, Unternehmen, Deal, Aufgabe, Aktivität. Dann erweitern Sie: in TypeScript-artigem YAML, in Git, migriert mit einem Befehl, validiert beim Schreiben. Ihre Ontologie ist ein erstklassiges Produktartefakt, keine versteckte Salesforce-Einstellung.
DAS SCHEMA IST DAS PRODUKT.
In den meisten CRMs steckt das Datenmodell drei Reiter tief in den Admin-Einstellungen und gehört einem Ops-Team, das Sie nie zu Gesicht bekommen. Über die Jahre sammeln sich Felder an. Niemand weiß mehr, welche noch gepflegt werden, welche Pipeline-Phase welche ersetzt hat oder warum ein Unternehmen vier „Branche“-Felder hat.
Menschen kommen damit zurecht — sie überspringen, was sie nicht verstehen. Agents nicht. Für einen Agent ist jedes deklarierte Feld die Behauptung, dass es etwas bedeutet, und jedes leere Feld eine Einladung zum Raten. Ein Schema, für das niemand verantwortlich ist, wird ein Agent mit Halluzinationen füllen.
CMP42 behandelt das Model als Code. Es liegt in Dateien, in Git, neben allem anderen, das Ihr Team prüft. Änderungen sind Diffs. Migrationen sind ein Befehl. Und die Agents in Produktion werden nie von einem Schema überrascht, das sich unter ihnen verändert hat.
SCHLANKE STANDARDS.
EXPLIZITE ERWEITERUNG.
Die Standards sind schlank. Erweiterung ist explizit. Steht ein Feld nicht in Ihrer Ontologie, steht es nicht am Kontakt. Stille ist ein Feature.
Das ist kein Minimalismus um seiner selbst willen. Für einen Agent ist ein Feld, das nicht existiert, eine ehrliche Antwort; ein Feld, das existiert, aber leer ist, sieht nach fehlenden Daten aus, die er ergänzen sollte. Jedes Feld, das Sie hinzufügen, sollte eines sein, das Sie definieren, gepflegt halten und von einem Agent beschreiben lassen wollen.
Deshalb beginnt CMP42 mit den fünf Grundbausteinen, die jedes CRM braucht — und sonst nichts. Alles, was spezifisch für Ihr Geschäft ist — ein Mandat, ein Retainer, ein Playbook, ein Verlängerungsdatum —, deklarieren Sie selbst, dort, wo Ihr Team es sieht.
| Standard-Baustein | Wofür er steht |
|---|---|
contact | Ein Mensch, mit dem Sie arbeiten. Kennt ein Unternehmen, verantwortet einen Deal, verfasste ein Dokument. |
company | Eine Organisation, mit der Sie arbeiten oder an die Sie verkaufen. |
deal | Eine Verkaufschance, die die von Ihnen deklarierten Phasen durchläuft. |
task | Etwas, das ein Mensch oder ein Agent erledigen muss. |
activity | Etwas, das passiert ist — ein Anruf, ein Meeting, eine Notiz. |
Die genauen Standardfelder pro Baustein werden während der Alpha gemeinsam mit den Design Partnern festgelegt.
VIER EIGENSCHAFTEN EINES MODELS.
Deklarative Model-Dateien
Models werden in TypeScript-artigem YAML deklariert und in Git versioniert. Prüfen Sie eine Änderung der Ontologie wie einen Pull Request, sehen Sie, wer was wann geändert hat, und machen Sie sie rückgängig wie jeden anderen Commit.
Validiert beim Schreiben
Jeder Schreibvorgang wird gegen das Model geprüft, bevor er im Graphen landet. Die Fehlermeldungen sind klar und konkret — ein Agent, der einen falschen Wert sendet, erfährt, was erlaubt ist, und korrigiert sich, statt einen Umweg zu erfinden.
Abwärtskompatible Migrationen
Ein einziger Befehl migriert Ihre Models. Die Migrationen sind abwärtskompatibel, damit Agents und Integrationen, die bereits in Produktion laufen, keine Schema-Überraschung erleben.
MCP-Tools pro Model
Jeder Model-Typ wird automatisch zu einem Satz MCP-Tools — get_contact, list_deals_at_stage, write_note_on_company —, die jeder MCP-kompatible Client nutzen kann.
EINE DATEI, KEINE EINSTELLUNGSSEITE.
Das Beispiel unten veranschaulicht die Idee für eine Boutique-Beratung, die Mandate erfasst. Es deklariert ein neues Model mit typisierten Feldern und benannten Kanten zu den Standard-Bausteinen und ergänzt den Standard-deal um ein optionales Feld.
Ein Befehl übernimmt die Änderung und erzeugt die Tools neu, die Agents sehen. Schreibt ein Agent später einen Wert, den das Model nicht zulässt, erhält er eine Fehlermeldung, mit der er etwas anfangen kann.
Die gezeigte Syntax ist beispielhaft. Das konkrete Model-Format erscheint mit der Alpha und wird gemeinsam mit den Design Partnern ausgestaltet.
# Ein eigenes Model, deklariert neben Ihrem Code
model: Engagement
fields:
title: string # Pflichtfeld
stage: "scoping" | "active" | "closed"
started_on: date? # optional
budget_eur: number?
edges:
client: -> Company # Mandat für ein Unternehmen
lead: -> Contact # wer es leitet
playbook: -> Doc? # das zugrunde liegende Framework
# Einen Standard-Baustein erweitern — explizit
extend: Deal
fields:
renewal_date: date?$ cmp42 migrate
+ model Engagement neu
+ field Deal.renewal_date optional · abwärtskompatibel
✓ tools get_engagement, list_engagements_at_stage,
write_note_on_engagement
✓ Migration angewendet✕ Engagement.stage
erhalten: "in progress"
erwartet: "scoping" | "active" | "closed"
→ neuer Versuch mit stage: "active" ✓ geschrieben · v2KEINE SCHEMA-ÜBERRASCHUNG IN PRODUKTION.
Ein Agent in Produktion hat die Form Ihrer Daten gelernt: welche Tools es gibt, welche Felder sie erwarten, welche Werte gültig sind. Ändern Sie diese Form unbedacht, wirft der Agent keinen sichtbaren Fehler — er macht still und leise das Falsche.
Deshalb sind Migrationen in CMP42 abwärtskompatibel. Ein neues Model, ein optionales Feld oder eine neue Kante erweitern, was Agents können, ohne zu brechen, was sie bereits tun. Identitäten sind inhaltsadressiert und bleiben über Schema-Änderungen hinweg stabil — Referenzen, die ein Agent oder eine Integration hält, überstehen eine Migration.
Weil Models in Git liegen, ist die Geschichte Ihrer Ontologie die Geschichte Ihres Repositorys: jede Änderung geprüft, zuordenbar und umkehrbar.
JEDES MODEL WIRD ZU TOOLS.
Sie schreiben nie einen MCP-Server für Ihr CRM von Hand. Wird ein Model migriert, erzeugt CMP42 die passenden Tools — für die Standards und für alles, was Sie selbst deklarieren. Fügen Sie Engagement hinzu, und Ihr Agent kann Mandate abfragen, nach Phase filtern und Notizen dazu schreiben — mit Eingaben, die durch Ihr Model typisiert sind.
Dieselben Operationen stehen Clients ohne MCP über REST und GraphQL zur Verfügung, mit derselben Authentifizierung und demselben Audit-Trail. Zur MCP-Tool-Oberfläche →