Der Administrator ist ein Agent

Ein CRM zu administrieren heißt in der Regel: klicken. Felder anlegen, Vorlagen pflegen, Automationen zusammenstecken — alles in einer Oberfläche, die dafür gebaut ist, und deren Ergebnis danach niemand mehr nachvollziehen kann. Bei propgen liegt diese Ebene inzwischen hinter derselben Schnittstelle wie die Daten. Wir arbeiten seit einigen Wochen so, und das hier ist der Bericht darüber.

Der Unterschied ist nicht das Werkzeug

Es ist verlockend, die Geschichte über das Werkzeug zu erzählen — wir nutzen für diese Arbeit einen KI-Agenten, konkret Claude, so wie wir auch diese Website ohne Agentur gebaut haben. Aber das ist der uninteressante Teil. Modelle werden ausgetauscht und für alle gleichzeitig besser. Entscheidend ist, woran sie andocken können.

Ein Agent kann nur tun, was die Schnittstelle hergibt. Und die meisten CRMs geben ihre Daten heraus und behalten ihre Konfiguration in der Oberfläche. Man kann Kontakte auslesen, aber nicht die Maske, in der sie erfasst werden. Man kann ein Objekt anlegen, aber nicht die Vorlage, aus der sein Exposé entsteht. Genau dort liegt die Grenze zwischen einer Integration, die Daten hin- und herschiebt, und einem System, das sich beschreiben lässt.

Was inzwischen hinter der Schnittstelle liegt

Über die vergangenen Wochen ist diese Ebene Stück für Stück nach außen gewandert. Fünf Bereiche, die vorher nur in der Oberfläche existierten:

Damit läuft die Kette durch: Feldprofil ausrollen, Objekt mit Struktur und Bildern anlegen, Vorlage prüfen, Dokument erzeugen — ohne dass jemand dazwischen eine Maske öffnet. Einen Überblick über alles, was über die Schnittstelle läuft, gibt die Seite Public API.

Wie das in der Praxis aussieht

Ein Beispiel aus unserer eigenen Arbeit: Für die Objektart Einzelhandel brauchte es ein eigenes Feldprofil — andere Kennzahlen, andere Pflichtangaben, andere Reihenfolge als bei einer Wohnung. Früher wäre das ein Nachmittag in der Maskenkonfiguration gewesen, einmal pro Instanz. Stattdessen wurde der bestehende Stand ausgelesen, als Datei gesichert, das neue Profil beschrieben, im Probelauf gegen die Schnittstelle validiert und erst dann geschrieben. Der Stand davor liegt noch immer daneben.

Der zweite Fall ist der aussagekräftigere. Auch unsere eigenen Texte über diese Schnittstellen entstehen zunächst aus Entwicklungsnotizen — und bevor sie erscheinen, werden sie gegen die laufende API geprüft, jede überprüfbare Aussage einzeln. Nicht jede hält dieser Prüfung stand. Was nicht standhält, wird korrigiert, bevor es jemand liest, statt später richtiggestellt zu werden.

Das ist der eigentliche Gewinn: nicht dass etwas schneller geht, sondern dass sich Behauptungen gegen ein System prüfen lassen, statt gegen eine Erinnerung. Der Merge-Vertrag beantwortet für jede der vier Oberflächen maschinenlesbar, welche Platzhalter dort wirklich aufgelöst werden — bei Word-Dokumenten über viertausend Pfade. Wer eine Vorlage baut, muss nicht mehr raten, ob das Feld wesentlicher_energietraeger heißt oder anders. Er fragt.

Warum das nicht fahrlässig ist

„Wir lassen eine KI unser CRM administrieren" klingt nach Kontrollverlust. Der Grund, warum es keiner ist, liegt nicht im Modell, sondern in dem, was die Schnittstelle zulässt. Sechs Eigenschaften, die den Unterschied machen:

• Schreiben erzeugt zunächst nur Entwürfe — eine per Schnittstelle angelegte Automation ist inaktiv und wirkt nicht, bis sie aktiviert wird.
• Aktivieren ist ein eigenes Recht — und lässt sich getrennt vergeben. Ein Integrationspartner kann entwerfen, prüfen und testen, ohne im laufenden Betrieb etwas auszulösen.
• Was von Hand gebaut wurde, bleibt unantastbar — in der Oberfläche aktivierte Automationen kann die Schnittstelle nicht ändern, deaktivieren oder löschen. Sie verwaltet nur, was sie selbst angelegt hat.
• Vorher durchspielen — ein Plan lässt sich gegen echte Datensätze rücktesten: Welche hätten die Bedingungen erfüllt, was wäre passiert? Ohne dass eine Aktion ausgeführt wird.
• Keine überschriebenen Änderungen — wer ändert, schickt den Stand mit, auf dem er aufsetzt. Hat in der Zwischenzeit jemand anders gespeichert, lehnt die Schnittstelle ab, statt die fremde Änderung zu überschreiben.
• Ein Weg zurück, der kein Projekt ist — was ausgerollt wurde, lässt sich zurücknehmen. Der Zustand davor ist ein Vorgang, keine Rekonstruktion aus Erinnerung und Screenshots.

Zusammen ergibt das eine Arbeitsteilung, die vor der KI-Frage liegt: Der Agent macht die Fleißarbeit — auslesen, abgleichen, beschreiben, validieren. Die Entscheidung, ob etwas produktiv wirkt, bleibt an einem Menschen und an einem Recht, das jemand ausdrücklich vergeben hat.

Für wen diese Tür offensteht

Nicht für jeden — und es wäre unredlich, das anders darzustellen. Wer so arbeiten will, braucht jemanden, der mit einer Schnittstelle umgehen kann: eine eigene IT, einen Entwickler im Haus oder einen technischen Dienstleister, mit dem man ohnehin zusammenarbeitet. Das ist keine hohe Hürde, aber es ist eine.

Wo dieses Know-how vorhanden ist — intern oder eingekauft —, steht dieselbe Tür offen, durch die wir gehen. Es gibt keine private Schnittstelle für uns und eine kleinere für alle anderen: Es ist dieselbe öffentliche API, mit denselben Rechten je Schlüssel. Besonders naheliegend ist das für Häuser mit mehreren Gesellschaften oder Standorten: Eine Korrektur an der Exposé-Vorlage geht bei fünf Gesellschaften einmal raus statt fünfmal.

Und für alle, die davon nie Gebrauch machen, bleibt trotzdem etwas übrig. Dass die Konfiguration auslesbar ist, heißt: Sie ist sicherbar, vergleichbar und zurückrollbar — auch dann, wenn wir sie im Auftrag pflegen. Der Unterschied zwischen einer Einstellung, die irgendwo in einer Datenbank liegt, und einer, die man in der Hand halten kann, zeigt sich nicht am guten Tag. Er zeigt sich, wenn etwas schiefgegangen ist.

Zwei Ebenen, dieselbe Idee

Im agentischen Maklerbüro haben wir beschrieben, was sich ändert, wenn ein Assistent nicht nur zusammenfassen, sondern handeln darf: Der Tag beginnt nicht mehr damit, dass man sein CRM abfragt, sondern damit, dass es einem den nächsten Schritt vorlegt. Was hier passiert, ist dieselbe Bewegung eine Etage tiefer. Nicht der Makler-Alltag wird agentisch, sondern der Betrieb des Systems darunter.

Beides hängt an derselben Voraussetzung, und die ist unspektakulär: Was ein Agent tun soll, muss die Schnittstelle können. Wo sie aufhört, hilft kein Modell weiter — egal, wie gut es im nächsten Jahr wird. Deshalb bauen wir sie zuerst.

Die technischen Details zu den hier beschriebenen Fähigkeiten stehen in den Release Notes. Weitere Beobachtungen aus dem deutschen Makler-CRM-Markt finden sich unter propgen Perspektiven.