KI-Agenten bauen: vom Prozess zum Sales-Call-Briefing

Ein KI-Agent ist eine Anwendung, in der ein Sprachmodell innerhalb eines Auftrags nächste Arbeitsschritte und Werkzeugaufrufe auswählt. Es verarbeitet deren Ergebnisse und entscheidet, ob weitere Informationen nötig sind oder die Aufgabe abgeschlossen werden kann.

Für unseren Sales Call könnte der Agent auf der Kundenwebsite eine Standorterweiterung finden. Daraufhin liest er die ursprüngliche Meldung, prüft den Zeitpunkt und sucht im internen Kontext nach passenden Grundlagen für standortübergreifende Zusammenarbeit. Welche Quelle er als Nächstes benötigt, ergibt sich während der Bearbeitung.

Der übergeordnete Ablauf bleibt festgelegt. Der Agent entscheidet innerhalb der einzelnen Aktivitäten, welche Quellen und Werkzeuge er benötigt. Für den Einstieg lässt sich dieser Entscheidungsspielraum klar begrenzen: Er darf die Recherche vertiefen, muss aber das vereinbarte Briefing zur Prüfung übergeben.

Beim Bau betrachten wir diese Teile als zusammenhängendes System: Der Auftrag bestimmt den Prozess, der Prozess den benötigten Kontext und die Werkzeuge. Die Arbeitsanweisung verbindet diese Grundlagen mit den Entscheidungen des Agenten. Die Prüfung zeigt anschließend, wo wir nachbessern müssen. Fehlt im Briefing etwa der aktuelle Produktstatus, prüfen wir, ob die Quelle veraltet war, der Abruf scheiterte oder der Agent eine vorhandene Angabe überging. Daraus ergibt sich, welchen Baustein wir ändern.

Bevor du eine Agentenumgebung konfigurierst, beschreibst du die Aufgabe so, dass eine andere Person sie übernehmen könnte. Für unser Beispiel lautet sie: Bereite ein Erstgespräch vor, indem du das Anliegen einordnest und höchstens drei begründete Gesprächsansätze entwickelst.

Das gewünschte Ergebnis ist ein Briefing mit maximal 500 Wörtern. Es enthält den Anlass, relevante Kundeninformationen, mögliche Ansatzpunkte, konkrete Fragen und einen Vorschlag für den nächsten Schritt. Quellen und der ausführliche Abgleich stehen in einem Anhang. Damit lässt sich später prüfen, ob der Agent seine Aufgabe erfüllt hat.

Als Eingabe braucht er Firmenname, eindeutige Domain, Termin, Gesprächspartner mit beruflicher Rolle, Gesprächsphase und vorhandene Kontaktnotizen. Eine unklare Unternehmenszuordnung muss vor der Recherche geklärt werden. Ein fehlender Kontaktverlauf darf dagegen als offene Grundlage im Ergebnis erscheinen.

Die Verantwortung für das Gespräch bleibt beim Vertrieb. Der Agent erstellt die Vorbereitung; die Person, die den Termin führt, prüft sie. Diese Aufteilung gehört bereits ins Prozessmodell, weil sie bestimmt, wo die automatische Bearbeitung endet und wie Korrekturen zurückfließen.

Bei NEXTHORIZN ordnen wir die Gesprächsvorbereitung dem Kernprozess Lead-to-Offer zu. Für den Artikel konkretisieren wir sie als eigenen Teilablauf. In PULSE beschreiben wir zuerst Ziel, Ein- und Ausgaben sowie die beteiligten Rollen. Die BPMN-Ansicht macht anschließend die Reihenfolge und die Übergaben sichtbar.

Der Ablauf hat sieben Aktivitäten: Auftrag klären → Kundenbild recherchieren → Beziehung ergänzen → NEXTHORIZN-Kontext abrufen → Passung begründen → Briefing erstellen → Briefing prüfen. Im Modell liegen die Recherche und Aufbereitung beim Agenten; Auftrag und abschließende Prüfung liegen beim Vertrieb. Die technische Ausführung durch einen Agenten ändert die fachliche Verantwortung nicht.

Die Aktivitäten beschreiben jeweils ein überprüfbares Arbeitsergebnis. Nach der Recherche liegt ein Kundenbild mit Quellen vor. Nach dem Kontaktabgleich sind das bestätigte Anliegen und frühere Vereinbarungen bekannt. Erst danach wird die Verbindung zum eigenen Angebot begründet. Rückfragen aus der Prüfung gehen an die betroffene Aktivität zurück.

In PULSE lässt sich zu einer Aktivität der zugehörige Kontext betrachten. Für „Passung begründen“ würde dieser Ausschnitt so aussehen:

Damit hat die Modellierung einen direkten Nutzen für den Bau des Agenten: Sie zeigt, welche Informationen an welcher Stelle gebraucht werden und wer das Ergebnis beurteilen kann. Die Agentenumgebung muss diesen Ablauf anschließend technisch umsetzen. Ein modellierter Prozess und verknüpfte Systeme allein führen noch keine Werkzeugaufrufe aus.

Für unseren Agenten kommen drei Perspektiven zusammen: das öffentliche Bild des Kunden, die bestehende Beziehung und der eigene Unternehmenskontext. Sie erfüllen unterschiedliche Aufgaben und sollten mit ihrer Herkunft erhalten bleiben.

Die Webrecherche beschreibt Geschäftstätigkeit, Leistungen, Standorte und aktuelle Entwicklungen. CRM und Gesprächsnotizen ergänzen, was der Kontakt selbst angesprochen hat und was bereits vereinbart wurde.

PULSE bildet in unserem Entwurf die Grundlage für die interne Perspektive. Aus Strategie und Wertversprechen ergibt sich, für welche Aufgaben und Zielkunden unser Angebot gedacht ist. Prozessbeschreibungen liefern Abläufe, Rollen und Zusammenhänge. Gepflegte Wissensquellen ergänzen Produktdetails, Voraussetzungen und geeignete Unterlagen.

Für die konkrete Vorbereitung wählen wir daraus vier Grundlagen aus: das relevante Portfolio mit seinem aktuellen Produktstatus, die adressierten Kundenaufgaben, passende Prozessbezüge und die Vorgaben für die jeweilige Vertriebsphase. Im Beispiel geht es um ein Erstgespräch über Teamübergaben. Der Agent benötigt daher vor allem Wissen über Prozessabläufe, Rollen und zugehörige Informationen.

Kontext wird pro Aktivität ausgewählt. Nach der Kundenrecherche lässt sich genauer bestimmen, welche internen Quellen gebraucht werden. Die Arbeitsanweisung legt fest, nach welchen Kriterien der Agent diese Quellen auswählt und wann er weitere Informationen nachlädt. Für jeden Gesprächsansatz bleibt nachvollziehbar, welche Produktbeschreibung ihm zugrunde liegt.

Dabei müssen wir die eigenen Prozesse und die möglichen Kundenprozesse auseinanderhalten. Unser Lead-to-Offer-Prozess bestimmt die Vorbereitung und das Gesprächsziel. Wie Projektübergaben bei der Agenturgruppe tatsächlich funktionieren, wird erst im Gespräch geklärt. Eine interne Prozessbeschreibung kann Fragen anregen, aber diese unbekannte Realität nicht belegen.

Jetzt lässt sich aus jeder Aktivität ableiten, welche technische Fähigkeit der Agent benötigt. Dafür wählst du eine Agentenumgebung, die Werkzeugaufrufe unterstützt und deren Ergebnisse an das Modell zurückgeben kann. Für einen ersten Prototyp genügt ein einzelner Agent mit einer gespeicherten Arbeitsanweisung und einem manuellen Start.

Bei der Webrecherche sind Finden und Lesen zwei eigene Fähigkeiten. Der Agent sucht beispielsweise nach Leistungsseiten und aktuellen Unternehmensmeldungen. Anschließend öffnet er die relevanten Seiten, um Aussagen im Zusammenhang zu prüfen.

Im Musterfall liefert eine Meldung den Hinweis auf einen zusätzlichen Standort. Der Agent muss prüfen, ob dessen Eröffnung geplant ist oder bereits stattgefunden hat. Eine Stellenanzeige kann wiederum Hinweise auf Aufgaben oder verwendete Anwendungen geben. Ob diese für das ganze Unternehmen gelten, bleibt zunächst offen.

Der interne Zugriff kann über MCP erfolgen, sofern die benötigten PULSE-Inhalte über die eingerichtete Schnittstelle verfügbar sind. MCP beschreibt den technischen Austausch zwischen Anwendung, Kontextquellen und Werkzeugen. Die Auswahl der passenden Quellen und der fachliche Abgleich werden in der Agentenanwendung umgesetzt.

Teste jeden Zugriff einzeln: Kann der Seitenleser eine Kundenmeldung vollständig abrufen? Findet der CRM-Zugang die richtige Notiz? Liefert der PULSE-Zugang die benötigte Produktbeschreibung samt Herkunft? Für den Prototyp kann ein freigegebener Dokumentauszug einen noch fehlenden Connector ersetzen. So lässt sich bereits prüfen, ob die fachliche Aufgabe funktioniert.

Für jeden Werkzeugaufruf sollten Zweck, Eingaben und Rückgaben klar beschrieben sein. So kann der Agent zuordnen, welches Werkzeug eine Quelle findet, ihren Inhalt liest oder eine interne Produktbeschreibung abruft. Die Laufzeitumgebung begrenzt außerdem Zugriffe und Rechercheumfang. Öffentliche Suchanfragen verwenden öffentliche Firmenangaben; vertrauliche Kontaktnotizen werden intern ausgewertet.

Das Prozessmodell beschreibt die Arbeit aus fachlicher Sicht. Die Arbeitsanweisung legt fest, wie der Agent sie bearbeitet: welche Reihenfolge gilt, wo er selbst nachrecherchieren darf und unter welchen Bedingungen er nachfragt oder ein unvollständiges Ergebnis zurückgibt.

Der entscheidende Schritt heißt in unserem Modell „Passung begründen“. Dafür verwenden wir eine feste Verbindung:

Kundensignal → möglicher betroffener Prozess → belegte Leistung → Nutzenhypothese → Gesprächsfrage.

So wird aus der Nachricht der operativen Leitung ein konkreter Gesprächsansatz. Die wiederholte Informationssuche ist ein ausdrücklich genanntes Anliegen. Projektübergaben sind der zu untersuchende Ablauf. PULSE kann Prozessschritte mit Rollen und relevantem Wissen verbinden. Die Hypothese lautet, dass diese Zusammenhänge den Beteiligten helfen könnten, benötigte Informationen an einer Übergabe leichter zu finden.

Daraus folgt die Frage: „Können Sie uns eine Übergabe zeigen, bei der heute besonders viel gesucht oder nachgefragt wird?“ Die Antwort würde klären, ob die angenommene Verbindung trägt und welche Informationen tatsächlich fehlen.

Die Standortmeldung kann einen zweiten Ansatz liefern. Sie belegt jedoch für sich genommen keine Schwierigkeiten in der Zusammenarbeit. Im Briefing bleibt deshalb sichtbar, ob ein Punkt auf einer Kundenaussage oder auf einer noch zu prüfenden Vermutung beruht. Jeder vorgeschlagene Angebotsbezug braucht zusätzlich eine interne Quelle, die die betreffende Leistung tatsächlich beschreibt.

Eine erste Arbeitsanweisung kann diese Regeln knapp zusammenfassen:

Die konkreten Termindaten werden bei jedem Start neu übergeben. Die Anwendung führt erlaubte Werkzeugaufrufe aus, gibt die Ergebnisse an das Modell zurück und protokolliert, welche Quellen verwendet wurden. Der Agent setzt die Bearbeitung fort, bis das vereinbarte Ergebnis vorliegt, eine Rückfrage nötig ist oder die konfigurierte Grenze erreicht wurde.

Für diese Aufgabe sind lesende Zugriffe und die Ausgabe des Briefings ausreichend. Eine automatische Terminbuchung oder Kundenkommunikation wäre eine zusätzliche Prozessaktivität mit eigenen Regeln und Berechtigungen.

Das erste Briefing zeigt, ob die Bausteine grundsätzlich zusammenarbeiten. Ob du dich im Alltag darauf verlassen kannst, prüfst du mit bekannten Fällen und vorher festgelegten Erwartungen. Lege für jeden Fall fest, welche Informationen das Briefing enthalten muss und welche Aussagen durch die vorhandenen Quellen nicht gedeckt wären.

Wähle beispielsweise einen Erstkontakt ohne Historie, eine neue Anfrage nach einer früheren Absage und einen Kundenwunsch, der nur zu einer geplanten Funktion passt. Im ersten Fall muss die fehlende Historie erkennbar bleiben. Im zweiten muss der Agent die zeitliche Entwicklung berücksichtigen. Im dritten darf die geplante Funktion nicht als heute verfügbar dargestellt werden.

Prüfe anschließend entlang des Prozessmodells: Gehören die Rechercheergebnisse zum richtigen Unternehmen? Ist das tatsächliche Anliegen getroffen? Decken die internen Quellen die Produktaussagen? Führen die Fragen zu Informationen, die wir für den nächsten Schritt brauchen? Wenn etwas nicht stimmt, lässt sich die betroffene Aktivität gezielt verbessern.

Auch der Übergang zum Vertrieb gehört zum Test. Die prüfende Person muss erkennen können, worauf ein Ansatz beruht. Für unser Beispiel sollte die Vorbereitung etwa mit diesem Gesprächseinstieg enden:

Miss die benötigte Vorbereitungszeit einschließlich Korrekturen und sammle nach dem Gespräch Rückmeldungen. Eine nützliche Frage oder ein früh erkanntes Missverständnis sagt mehr über den Wert des Briefings aus als seine Länge. Mit diesen Beobachtungen verbesserst du Recherche, Kontextauswahl oder Arbeitsanweisung.

Für deinen ersten eigenen Agenten kannst du genauso beginnen: Wähle eine begrenzte Aktivität aus einem bekannten Prozess. Beschreibe das Ergebnis, verknüpfe die benötigten Grundlagen und binde die erforderlichen Werkzeuge an. PULSE macht dabei den fachlichen Zusammenhang sichtbar, aus dem der Agent seinen Auftrag und seinen Kontext erhält.