Monat: Oktober 2026

Ein Chatbot, der eine falsche Antwort gibt, ist ein Ärgernis. Ein Agent, der eigenständig eine E-Mail verschickt, einen Datensatz ändert oder ein Angebot erstellt, ist etwas anderes. Er handelt — und wer handelt, muss sich erklären können.

Die meisten Teams, die heute Agenten in Betrieb nehmen, merken das erst beim ersten Zwischenfall. Dann steht die Frage im Raum: Was genau ist da passiert? Und die ehrliche Antwort lautet überraschend oft: Wir wissen es nicht mehr.

Warum Logs für Agenten nicht reichen

Klassisches Logging ist für Software gemacht, die Anweisungen abarbeitet. Eine Zeile pro Ereignis, Zeitstempel, Schweregrad. Für einen Webserver ist das angemessen.

Ein Agent arbeitet anders. Auf eine Eingabe hin entscheidet er selbst, welche Werkzeuge er benutzt, ruft eins davon auf, bewertet das Ergebnis, ruft womöglich das nächste auf und formuliert am Ende eine Antwort. Diese Abfolge nennen wir einen Turn. Was dabei zählt, ist nicht das einzelne Ereignis, sondern der Zusammenhang: Welches Modell war beteiligt? Welche Werkzeuge wurden mit welchen Argumenten aufgerufen? Was kam zurück? Und an welcher Stelle wurde die Entscheidung getroffen, die am Ende zum Problem wurde?

Ein Chatverlauf zeigt davon nur die Oberfläche: Frage rein, Antwort raus. Alles dazwischen — und genau dort passiert das Handeln — bleibt unsichtbar.

Turn-Tracing: der Ablauf als Einheit

Wir haben Observability deshalb um den Turn herum gebaut und nicht um die einzelne Logzeile. Ein aufgezeichneter Turn lässt sich aufklappen wie ein Protokoll: jeder Werkzeugaufruf mit seinen Argumenten, jedes Ergebnis, jeder Modellaufruf, in der Reihenfolge, in der es tatsächlich geschah.

Das macht einen praktischen Unterschied. Bei der Frage „Warum hat der Agent diesen Kunden angeschrieben?“ muss man nicht mehr aus verstreuten Logzeilen rekonstruieren, was vermutlich passiert ist. Man sieht den Ablauf.

Ein Detail, auf das wir Wert gelegt haben: Das System füllt keine Lücken auf. Wenn ein Teil der Ausführungshistorie fehlt, wird das angezeigt — und nicht durch eine plausibel aussehende Rekonstruktion ersetzt. Ein Nachweis, der an den unsicheren Stellen rät, ist schlimmer als gar keiner, weil man ihm glaubt.

Lückenlosigkeit, die sich prüfen lässt

Ein Agent läuft in einem eigenen Container, oft beim Kunden, und meldet seine Ereignisse an die Plattform. Daraus ergibt sich eine unangenehme Frage: Woher weiß man, dass dabei nichts verloren ging — oder nachträglich verändert wurde?

Jedes Ereignis trägt deshalb eine fortlaufende Sequenznummer und einen Hash, der den Vorgänger einschließt. Beim Eingang prüft die Plattform beides: Passt die Nummer lückenlos an die vorige an, und passt der Hash zur bisherigen Kette? Wenn nicht, wird der Zustand als broken markiert — samt Begründung.

Das ist bewusst strenger als Monitoring. Monitoring sagt Ihnen, ob ein System läuft. Eine geprüfte Ereigniskette sagt Ihnen, ob die Aufzeichnung dessen, was es getan hat, vollständig ist. Bei einem System, das selbstständig in Kundendaten schreibt, ist das der Unterschied zwischen einem Protokoll und einem Nachweis.

Wenn etwas auffällt, bevor jemand fragt

Aus denselben Daten entstehen Alarme. Vier Typen decken in der Praxis das meiste ab:

• Agent offline — der Agent meldet sich nicht mehr. Bei einem System, das im Hintergrund arbeiten soll, fällt das sonst erst auf, wenn ein Ergebnis ausbleibt.
• Häufung abgelehnter Aktionen — der Agent versucht wiederholt etwas, wofür ihm die Rechte fehlen. Entweder ist seine Aufgabe falsch zugeschnitten, oder er läuft in eine Richtung, die so nicht gedacht war.
• Häufung von Fehlern — die Fehlerrate steigt gegenüber dem Normalbetrieb.
• Kette unterbrochen — die Integritätsprüfung schlägt an.

Jeder Alarm hat eine Schwere von niedrig bis kritisch und geht wahlweise in die Oberfläche, per E-Mail oder an einen Webhook. Der Punkt ist nicht die Benachrichtigung an sich, sondern dass die Auffälligkeit aus dem Verhalten des Agenten abgeleitet wird und nicht aus der Systemauslastung.

Im Video zu sehen

Wie das in der Oberfläche aussieht, zeigen wir in diesem kurzen Video — Dashboard, Turn-Suche und die Detailansicht eines einzelnen Ablaufs:

Warum das keine Nebensache ist

Es gibt einen betrieblichen Grund und einen regulatorischen.

Betrieblich: Ein Agent, dessen Verhalten man nicht nachvollziehen kann, lässt sich nicht verbessern. Man kann ihn abschalten oder ihm weiter vertrauen, aber man kann nicht gezielt an der Stelle nachbessern, an der er danebenlag — weil man diese Stelle nicht kennt.

Regulatorisch: Der AI Act verlangt für Systeme mit entsprechendem Risiko Protokollierung und menschliche Aufsicht. „Wir haben den Chatverlauf“ ist dafür keine tragfähige Antwort. Eine lückenlos geprüfte Aufzeichnung dessen, welche Werkzeuge mit welchen Daten aufgerufen wurden, schon eher.

Unsere Haltung dabei ist unbequem, aber wir halten sie für richtig: Wer Agenten einsetzt, die eigenständig handeln, übernimmt Verantwortung für dieses Handeln. Observability ist das Werkzeug, mit dem diese Verantwortung überhaupt wahrnehmbar wird. Ohne sie bleibt nur Vertrauen — und Vertrauen ohne Nachprüfbarkeit ist bei autonomen Systemen keine gute Grundlage.

Agent Observability ist Teil der HybridAI-Plattform und für gehostete HybridClaw-Agenten verfügbar.

Jedes Unternehmen, das ein CRM betreibt, kennt die gleiche Klage aus dem Vertrieb: „Das System kostet mich mehr Zeit, als es mir bringt.“ Die üblichen Antworten darauf sind Schulungen, Pflichtfelder, Reminder-Mails und irgendwann Druck vom Management. Sie funktionieren selten, und der Grund dafür ist strukturell.

Warum CRM-Daten unvollständig sind

Ein Außendienstmitarbeiter führt ein vierzig Minuten langes Gespräch beim Kunden. Darin stecken: eine Mengenangabe, ein Preisvorbehalt, die Information, dass der eigentliche Entscheider gerade gewechselt hat, eine Beschwerde über die letzte Lieferung, und ein Gefühl dafür, wie wahrscheinlich der Abschluss ist.

Was davon im CRM landet, hängt daran, ob diese Person zwei Stunden später — nach zwei weiteren Terminen, im Zug oder abends zu Hause — die Energie aufbringt, elf Formularfelder auszufüllen. Meistens landet ein Satz darin. Manchmal gar nichts.

Das ist kein Disziplinproblem. Es ist ein Schnittstellenproblem. Das Gespräch ist gesprochene Sprache, unstrukturiert, voller Kontext. Das CRM erwartet Formularfelder. Dazwischen liegt eine Übersetzungsleistung, die jemand manuell erbringen muss — und zwar ausgerechnet die Person, deren Zeit am teuersten ist.

Die gesamte KI-Diskussion der letzten Jahre hat sich auf die andere Richtung konzentriert: bessere Auswertung der Daten, die schon da sind. Dashboards, Forecasts, Lead Scoring. Das ist nicht falsch, aber es behandelt das Symptom. Wenn die Hälfte dessen, was im Markt passiert, nie ins System gelangt, ist auch das beste Modell darauf eine Analyse von Lücken.

Warum Realtime Voice hier anders ist als Chat

Sprachsteuerung für Software gibt es seit zwanzig Jahren, und sie war fast immer enttäuschend. Der Unterschied heute liegt nicht in der Spracherkennung — die war auch vorher schon brauchbar — sondern darin, was zwischen Erkennung und Ausführung passiert.

Ein Realtime-Voice-Modell hört nicht zu und tippt mit. Es versteht einen gesprochenen Absatz, erkennt darin verschiedene Sachverhalte, ordnet sie unterschiedlichen Zielstrukturen zu und fragt nach, wenn etwas fehlt. Aus

„Gerade bei Müller GmbH raus. Die wollen 200 Stück zum Q3-Preis, Entscheidung bis Monatsende — ich würde auf 70 Prozent gehen.“

werden drei verschiedene Einträge: ein Besuchsbericht, ein Angebotsentwurf und eine Deal-Einschätzung. Jeder landet dort, wo er hingehört, mit den richtigen Feldern befüllt.

Entscheidend ist der Zeitpunkt. Das funktioniert auf dem Parkplatz, zwei Minuten nach dem Termin, während die Details noch präsent sind. Nicht abends, wenn die Erinnerung schon abgeschliffen ist und die Motivation fehlt.

Der zweite Unterschied zu Chat ist die Freihändigkeit. Ein Vertriebler im Auto kann nicht tippen, aber er kann sprechen. Genau in diesem Zeitfenster — zwischen zwei Terminen — ist er am ehesten bereit, etwas zu erledigen, was sonst liegen bleibt.

Lesen und Schreiben gehören zusammen

Eine reine Diktierfunktion wäre nur die halbe Lösung. Interessant wird es, wenn dieselbe Stimme auch Auskunft gibt.

„Was muss ich über diesen Kunden wissen?“ auf der Fahrt zum Termin — und die Antwort enthält offene Angebote, die letzten Bestellungen, Notizen vom vorherigen Besuch und die relevanten E-Mails der letzten Wochen. Das ist dieselbe Datenbasis, die auch am Schreibtisch zur Verfügung steht, nur über eine Schnittstelle, die im Auto funktioniert.

Technisch sind das zwei verschiedene Aufgaben. Fragen nach Umsätzen, Mengen und Pipeline müssen zu exakten Abfragen auf strukturierte Daten werden — da darf nichts geschätzt werden, Zahlen sind Zahlen. Fragen nach Hintergründen, Gesprächsverläufen oder Produktdetails müssen dagegen semantisch über unstrukturierte Dokumente laufen: Protokolle, E-Mails, Datenblätter, Verträge.

Wir trennen das bewusst in zwei Pfade — Text-to-SQL für die Zahlen, semantische Suche für die Geschichte dahinter — und lassen ein drittes Modell die Ergebnisse zusammenführen und erklären. Die Arithmetik macht dabei nie das Sprachmodell, sondern der Code. Ein Angebot, dessen Summe ein LLM „geschätzt“ hat, wäre unbrauchbar.

Was das in der Praxis bedeutet: Sales Companion

Genau dafür haben wir den Sales Companion gebaut: eine iPhone-App mit CarPlay-Unterstützung, die als Sprachschnittstelle auf dem bestehenden CRM sitzt.

Wichtig dabei: Es ist kein neues CRM. Die Daten bleiben in Salesforce, SAP, Dynamics oder Zoho, wo sie heute schon liegen. Es kommt eine Schicht darüber, die über Adapter auf diese Systeme zugreift. Keine Migration, kein Parallelsystem, keine Umgewöhnung für die Teams, die am Schreibtisch weiter mit ihrem gewohnten Werkzeug arbeiten.

Im Alltag sieht das so aus:

• Briefing vor dem Termin — die relevanten Informationen zum Kunden, zusammengefasst auf der Anfahrt.
• Besuchsbericht danach — diktiert statt getippt, mit Kunde, Ansprechpartnern, Themen und nächsten Schritten.
• Angebotsentwurf — gesprochene Mengen und Preise werden zu einem Entwurf, exakt gerechnet.
• Analysen auf Zuruf — „Welche Kunden haben dieses Quartal weniger bestellt als letztes?“ in Sekunden, ohne auf einen BI-Report zu warten.

Ein Teil, der uns selbst überrascht hat, wie gut er ankommt: Dieselbe Stimme, die die Kunden kennt, taugt auch zum Üben. Ein Rollenspiel mit einer KI, die den Gesprächspartner spielt, Einwände bringt und Widerstand leistet — danach eine Auswertung pro Fähigkeit und konkrete Hinweise, woran zu arbeiten ist. Für neue Mitarbeiter im Vertrieb ist das deutlich wirksamer als jedes Handbuch.

Datenschutz ist keine Fußnote

Wer Kundengespräche durch ein Sprachmodell schickt, muss wissen, wohin die Daten gehen. Unsere Infrastruktur läuft auf europäischen Servern, DSGVO- und AI-Act-konform. Personenbezogene Daten lassen sich maskieren, bevor ein Prompt ein Modell erreicht, und über Rollen steuern Sie, welche Teams welche Datenquellen überhaupt erreichen.

Das ist kein nachgereichtes Feature, sondern bei einem System, das Besuchsberichte über reale Ansprechpartner erfasst, eine Voraussetzung dafür, dass es überhaupt eingesetzt werden darf.

Ausprobieren

Auf unserer Seite zum Agentic CRM können Sie sich die Demo-Videos ansehen und die Sprachfunktion direkt testen — die öffentliche Demo läuft auf Beispiel-Vertriebsdaten, ohne Anmeldung.

Die interessantere Frage ist ohnehin nicht, ob die Technik funktioniert. Sie ist, ob Ihr Vertrieb sie benutzt. Unsere Erfahrung bisher: Wenn die Eingabe zwei Minuten auf dem Parkplatz dauert statt zwanzig Minuten am Abend, benutzen sie sie.