ERST DEN ACCOUNT LESEN.
DANN DIE NOTIZ.
Sie wollen einen Agent, der die echte Historie eines Kunden liest, bevor er die Verlängerungsnotiz entwirft. Nicht die generische ChatGPT-Zusammenfassung, die den Accountnamen falsch schreibt. Dieser Agent braucht einen Graphen, keinen HubSpot-Export.
DER EXPORT IST NICHT DER ACCOUNT.
In einem Product-led-Geschäft ist die Geschichte eines Accounts weit verstreut: Wer hat sich zuerst registriert, wer wurde zum Champion, welcher Deal steht zur Verlängerung an, was stand im letzten Review-Deck, was hat der Kunde im letzten Gespräch angefragt? Manches davon steht im CRM. Vieles steckt in Dokumenten, Aufzeichnungen und Notizen.
Die übliche Abkürzung: einen CRM-Export über einen Zapier-Umweg in den Agent schieben, der diese Woche erschienen ist. Der Agent erhält Textzeilen. Er kann einen Champion nicht von jemandem unterscheiden, der nur in Kopie stand — also rät er. Er befüllt ein Feld, das nie deklariert wurde. Er nennt eine Pipeline-Phase, die es nicht gibt. Nicht, weil das Modell schlecht ist — sondern weil die Quelle nicht für diesen Leser gebaut wurde.
Das Ergebnis ist eine Verlängerungsnotiz, die überzeugt klingt und im Detail falsch ist. Irgendjemand in Ihrem Team bemerkt es — oder der Kunde.
WAS DER AGENT TATSÄCHLICH ERHÄLT.
Ein konzeptioneller Vergleich zweier Wege, einem Agent Kundenkontext zu geben. Er beschreibt die Form der Eingabe, nicht die Funktionen eines Anbieters.
| Export im Prompt | CMP42 Context-Graph | |
|---|---|---|
| Form | Flache Zeilen und Text, als ein Block gelesen | Typisierte Objekte mit benannten Kanten, gelesen wie eine Datenbank |
| Beziehungen | Aus Spaltennamen abgeleitet; der Agent muss sie erschließen | Explizit: Ein Kontakt verantwortet einen Deal, verfasste ein Dokument |
| Aktualität | Ein Stand vom Zeitpunkt des Exports | Der aktuelle Graph, jedes Objekt versioniert |
| Fehlende Daten | Leicht mit plausiblen Vermutungen zu überdecken | Nur deklarierte Felder; Schreibvorgänge werden gegen Ihre Models validiert |
| Quellen | Ein Satz lässt sich kaum auf seine Quelle zurückführen | Jedes Objekt und jedes Feld per URI adressierbar |
| Zurückschreiben | Den Entwurf von Hand irgendwohin kopieren | MCP-Tools wie write_note, zuordenbar und versioniert |
VIER BAUSTEINE, EINE VERLÄNGERUNG.
Der Account als Graph
Unternehmen, Kontakte, der Verlängerungs-Deal, Produkt-Briefings, Meeting-Aufzeichnungen und Notizen — verbunden durch typisierte Kanten im Context-Graphen. Mit Tools wie get_context und list_related bewegt sich ein Agent darin.
Nur die Felder, die Sie deklarieren
Schlanke Standards für Kontakt, Unternehmen, Deal, Aufgabe und Aktivität. Die für Verlängerungen relevanten Felder, die Ihr Team wirklich nutzt, deklarieren Sie explizit in Models — mehr nicht. Was nicht in Ihrer Ontologie steht, steht nicht am Kontakt.
Eine Notiz mit menschlichem Schritt
Fassen Sie den Entwurf in einen Process: Der Agent liest und entwirft, die Account-Verantwortliche gibt frei, die freigegebene Notiz wird zurückgeschrieben. Jeder Lauf wird protokolliert und lässt sich gegen einen früheren Snapshot wiederholen.
Jeder Agent, den Ihr Team bevorzugt
Claude Desktop, Claude Code, Cursor, Cline oder ein eigener Agent auf Basis des MCP SDK nutzen dieselben Tools. Für den Rest Ihres Stacks stellen REST und GraphQL dieselben Operationen bereit — mit gleicher Authentifizierung und gleichem Audit-Trail. MCP-Tools →
VOR DEM VERLÄNGERUNGSGESPRÄCH.
Die Verlängerungsnotiz für Aspen
„Aspen“ ist ein fiktiver Kunde. Die Schritte zeigen, wie die Konzepte zusammenspielen; Tool-Namen und Process-Format sind beispielhaft und werden mit den Design Partnern ausgestaltet.
- Die Account-Verantwortliche bittet ihren Agent, die Verlängerungsnotiz für Aspen vor dem Termin nächste Woche zu entwerfen.
- Der Agent ruft
get_contextfür den Aspen-Verlängerungs-Deal auf undlist_relatedfür die Menschen und Dokumente darum herum. Er sieht, wer die Verlängerung verantwortet, das aktuelle Dokument zum Verlängerungsplan und die Notizen der letzten beiden Gespräche. - Aus dieser Historie entwirft er die Notiz und listet die verwendeten Quellobjekte auf. Versucht er, eine Deal-Phase zu setzen, die Ihre Models nicht kennen, liefert die Validierung beim Schreiben eine klare Fehlermeldung — und er korrigiert sich.
- Ein Process-Schritt leitet den Entwurf an die Account-Verantwortliche. Sie gibt frei;
write_notespeichert die Notiz, zugeordnet dem Agent und freigegeben von ihr. - Im nächsten Quartal wiederholt das Team denselben Process gegen den Snapshot des Vormonats, um zu prüfen, ob die Notiz damals anders ausgefallen wäre.
# beispielhaft — die Idee, nicht die finale Syntax
process: renewal_note
steps:
- agent: read_account # get_context + list_related
- agent: draft_note # nennt Quellobjekte per URI
- human: approve # Account-Verantwortliche gibt frei
- agent: write_note # zuordenbar + versioniert
observe:
run_history: gegen früheren Snapshot wiederholbar
cost: Token-Verbrauch pro LaufFUNDIERTE ENTWÜRFE. KEINE BLACKBOX.
Was sich ändert
- Entwürfe auf Basis des echten Accounts, mit Angabe der Quellobjekte.
- Ein Freigabeschritt genau dort, wo Ihr Team ihn haben will.
- Ein Audit-Trail pro Lauf: was der Agent gelesen und geschrieben hat, zu welchen Token-Kosten.
- Ein Graph für jeden Agent — heute der Verlängerungsassistent, im nächsten Quartal der Support-Bot.
Was CMP42 bewusst nicht liefert
- Keine proprietäre „KI-Insights“-Schicht. Nutzen Sie das Modell, dem Sie vertrauen. Warum →
- Keine Dashboards, die am Dienstag schon veraltet sind — bis Sie sie selbst schreiben.
- Kein Kontaktobjekt mit 200 Feldern. Die Standards sind schlank; Erweiterung ist explizit.
Benennen Sie das Tool, das Ihren Verlängerungen fehlt
Design Partner können ein MCP-Tool vorschlagen und benennen, das an alle künftigen Kunden ausgeliefert wird. Erzählen Sie uns im 15-minütigen Gespräch, was Ihrem Verlängerungsprozess fehlt.
→ Als Design Partner bewerben