Zum Inhalt springen
Implementa.

Einen KI-Agent bauen · Guide 15 von 15

In welchem Kanal gehört ein KI-Agent hin: die Oberfläche entscheidet, ob er benutzt wird

Die Frage, in welchem Kanal ein KI-Agent hingehört, kommt fast immer zum Schluss — wenn er schon gebaut ist und jemandem gezeigt werden muss. Falsche Reihenfolge, denn die Oberfläche ist keine Verpackung: sie entscheidet, wer ihn wirklich benutzt, wie lange er antworten darf, mit welchen Rechten er startet und was aufgeschrieben ist, wenn er etwas falsch macht. Ein guter Agent auf der falschen Oberfläche hat ein wiedererkennbares Nutzungsmuster — Ausschlag in Woche eins, Stille in Woche drei — und landet als «hat nicht funktioniert» im Archiv. Nicht funktioniert hat aber die Zumutung, noch einen Tab zu öffnen. Hier sind die fünf realen Oberflächen, die vier Achsen, nach denen du wählst, und die Tabelle, mit der die Entscheidung an einem Nachmittag steht.

In welchem Kanal ein KI-Agent hingehört: die Entscheidung, die zuletzt fällt und von Anfang an regiert

In welchem Kanal ein KI-Agent hingehört, fragt fast niemand am Anfang. Die Frage kommt zum Schluss, wenn der Agent schon funktioniert und man ihn jemandem zeigen muss. Und dann ist sie zu spät, denn es ist keine Frage der Präsentation: Sie entscheidet, wer ihn wirklich benutzt, wie viel Zeit er zum Antworten hat, mit welchen Berechtigungen er geboren wird und was schriftlich bleibt, wenn er sich irrt. Eine Oberfläche wählen heißt, gleichzeitig Architektur, Latenzbudget und Sicherheitsmodell zu wählen.

Die These dieses Leitfadens ist simpel und lässt sich in jedem Unternehmen nachprüfen: Der Agent, der dort lebt, wo die Leute ohnehin arbeiten, wird benutzt; der Agent in einem eigenen Tab stirbt von allein — egal wie gut er ist. Das hat nichts mit Begeisterung oder Schulung zu tun. Jede neue Oberfläche, die du aufmachen lässt, ist eine Aufmerksamkeitsmaut, die jemand täglich bezahlt, und diese Maut ist gemessen: Die im August 2022 im Harvard Business Review veröffentlichte Untersuchung über 137 Mitarbeitende aus drei Fortune-500-Unternehmen zählte rund 1.200 Wechsel pro Tag zwischen Anwendungen und Fenstern — knapp vier Stunden pro Woche, etwa 9 % der Arbeitszeit, die allein fürs Neuorientieren draufgehen. Quelle: How Much Time and Energy Do We Waste Toggling Between Applications?, Harvard Business Review, August 2022.

Der Kontext hilft einem neuen Werkzeug auch nicht gerade. Der Bericht von Microsoft WorkLab über den endlosen Arbeitstag, im Juni 2025 auf Basis aggregierter und anonymisierter Signale aus Microsoft 365 veröffentlicht, verortet eine Unterbrechung alle zwei Minuten während des Arbeitstags — 275 pro Tag bei den 20 % der Nutzer mit den meisten Benachrichtigungen — zwischen Meetings, Mails und Chats. Quelle: Breaking down the infinite workday, Microsoft WorkLab, Juni 2025. Gegen dieses Rauschen zu verlangen, dass sich jemand an ein weiteres Tab erinnert, ist keine kleine Bitte: Du konkurrierst um den teuersten Platz, den dein Team hat.

Die fünf realen Oberflächen und wer jeweils gegenübersitzt

In der Praxis gibt es nur fünf Orte, an denen sich ein Unternehmensagent installieren lässt, und an jedem klebt ein anderer Nutzer. Die Oberfläche wählt man nicht nach Geschmack: Man wählt sie, indem man herausfindet, wo diese Person genau in dem Moment steckt, in dem die Arbeit auftaucht.

  • Im CRM oder ERP. Nutzer: der Mitarbeiter, der dort ohnehin acht Stunden am Tag lebt. Beste Adoption, schlechteste Sichtbarkeit für den, der einkauft — niemand macht eine glanzvolle Demo von einem Seitenpanel. Dafür erscheint der Agent direkt neben dem Datensatz, den er anfassen wird, mit Konto und Historie vor Augen, und niemandem muss erklärt werden, wo er zu finden ist.
  • Slack oder Teams. Nutzer: das Team, im Gespräch. Taugt für Arbeit, die im Reden entsteht — »weiß jemand, ob dieser Kunde einen Supportvertrag hat?« — und für Prozesse, in denen kollektiv entschieden wird. Echter Vorteil: Frage und Antwort stehen für alle sichtbar da, und das baut Vertrauen viel schneller auf als ein privater Chat.
  • WhatsApp. Nutzer: der Kunde, der dir dort sowieso schon schreibt. Der Kanal mit der größten kommerziellen Zugkraft in Spanien, Italien und Portugal — und der mit den meisten Plattformregeln im Gepäck. Man wählt ihn, weil der Kunde schon da ist, nie um ihn dorthin zu bringen.
  • Der Chat auf der Website. Nutzer: ein anonymer Besucher, der gerade entscheidet. Die anspruchsvollste Oberfläche bei der Latenz und die ärmste beim Kontext: Du weißt nicht, wer da ist. Ihr Job ist qualifizieren und einsammeln, nicht Kundenfälle lösen.
  • Die E-Mail. Nutzer: eher der Prozess als die Person. Lieferantenrechnungen, Bestellungen, Anfragen, die ohnehin in einem Postfach landen. Die unglamouröseste Oberfläche — und die, die die meiste Wiederholungsarbeit versteckt, weil niemand sie als Kanal betrachtet: Alle sehen darin einen Ordner.

Eine sechste fehlt, die fast alle standardmäßig wählen und die mit Absicht nicht auf der Liste steht: das eigene Tab, die interne App mit eigener URL und eigenem Login. Nicht dass sie nie taugt — für tiefe Arbeit mit langen Sessions und einem Expertennutzer, der genau dafür hinkommt, ist sie richtig. Sie wird nur gewählt, weil es dem bequem ist, der baut, nicht weil dort die Arbeit liegt. Wenn der Use Case lautet »etwas lösen, das nebenbei auftaucht«, ist das eigene Tab die schlechteste verfügbare Option.

Latenz: wie viel Stille jeder Kanal aushält, bevor der Nutzer weg ist

Jede Oberfläche hat ein implizites Zeitbudget, das niemand aufschreibt und alle einhalten. Man merkt es, wenn es gerissen wird: Der Nutzer erklärt den Agenten für tot und geht. Das sind die Größenordnungen, mit denen man designen sollte.

OberflächeAntwortbudgetWas du dafür bauen musst
Website-ChatSekundenSchnelles Modell + Teilantwort während der Arbeit; nicht warten, bis die ganze Antwort steht
WhatsAppSekunden bis ein paar MinutenSofortige Empfangsbestätigung; der Kunde sitzt nicht mit offenem Bildschirm davor
Slack / TeamsZehner-SekundenReaction oder »bin dran«, danach die richtige Nachricht; Asynchronität ist hier längst akzeptiert
Im CRM / ERPSekunden bei einem Button; Minuten, wenn er in den Datensatz schreibtEntscheiden, ob es Interaktion oder Hintergrundprozess ist — das sind zwei verschiedene Designs
E-MailStundenFast nichts: Hier hört Latenz auf, das Problem zu sein, und Nachvollziehbarkeit wird es

Am schwersten zu akzeptieren ist die Folge daraus: Der Kanal regiert über das Modell. Wenn die Oberfläche Sekunden verlangt, kannst du dir keine drei verketteten Aufrufe des stärksten Modells leisten, so gut sie auch antworten; du wirst aufteilen müssen — billig zum Klassifizieren und Routen, stark zum Entscheiden — und etwas zurückgeben, bevor du fertig bist. Diese Aufteilung steht ausführlich in welches Modell für einen KI-Agenten, und sie wird nach der Oberflächenentscheidung getroffen, nicht davor.

Rechte: jede Oberfläche bringt ihre eigenen schon eingeschaltet mit

Einen Agenten auf einer Oberfläche zu installieren ist sicherheitstechnisch nicht neutral: Er erbt das Berechtigungsmodell dieser Oberfläche, und standardmäßig verlangt er fast immer zu viel. Das schaut man sich vor der Unterschrift an, nicht nach dem ersten Vorfall.

  • CRM / ERP: erbt — und das ist die gute Nachricht. Der Agent kann mit der Rolle des Nutzers laufen, der ihn aufruft. Wenn der Vertriebler dieses Konto nicht sieht, sieht es der Agent auch nicht. Der einzige Fall, in dem dir die Oberfläche die Arbeit geschenkt abnimmt. Aufpassen muss man nur auf die Versuchung, ihm einen Service-Account mit Adminrechten zu geben, »damit nichts schiefgeht«.
  • Slack / Teams: eigene Scopes, und der gefährliche ist die Historie. Der Agent wird als App mit eigenen Rechten installiert. Den kompletten Verlauf eines Kanals zu lesen ist weit mehr, als meistens nötig ist: Für die meisten Fälle reicht es, die Nachrichten zu bekommen, in denen er erwähnt wird. Die ganze Historie zu verlangen macht den Agenten zum dauerhaften Mitleser interner Gespräche — eine Entscheidung, die bewusst getroffen gehört.
  • Website-Chat: Unbekannte. Er spricht mit nicht authentifizierten Besuchern, also darf er keinen Lesezugriff auf konkrete Kundendaten haben. Alles, was nach »sag mir den Status meiner Bestellung« riecht, verlangt vorher einen Identifikationsschritt — sonst hast du ein elegant designtes Datenleck.
  • WhatsApp: brüchige Identität. Eine Telefonnummer ist keine verifizierte Identität: Nummern werden recycelt, Handys verliehen. Für jede Aktion mit Konsequenzen braucht es eine zusätzliche Verifizierung.
  • E-Mail: der Scope ist die Falle. Zugriff auf ein Postfach zu geben heißt, Zugriff auf dessen gesamte Historie zu geben. Der Scope wird über Label, Ordner oder dedizierten Alias eingegrenzt, nie über das ganze Postfach.

Die Regel gilt für alle fünf: Rechte werden pro Use Case beantragt und mit Ablaufdatum überprüft. Man nimmt nicht das, was der Installer mitbringt. Der vollständige Aufbau — was man gibt, wie man es entzieht und was protokolliert wird — steht in welche Berechtigungen ein KI-Agent bekommen sollte.

Was protokolliert bleibt und was sich beim Schließen des Tabs auflöst

An dem Tag, an dem sich der Agent irrt — und der Tag kommt — lautet die Frage nicht »warum?«, sondern »wo schaue ich nach?«. Die Oberfläche entscheidet, ob diese Frage in zwei Minuten oder in zwei Tagen eine Antwort hat.

Slack und Teams sind auf dieser Achse die beste Oberfläche, und fast niemand berücksichtigt das bei der Wahl: Das Gespräch bleibt schriftlich stehen — wer gefragt hat, was der Agent geantwortet hat und wer ihm widersprochen hat — an einem Ort, den das Unternehmen ohnehin aufbewahrt und exportieren kann. Im CRM passiert Ähnliches, sofern der Agent in den Datensatz schreibt statt in ein flüchtiges Panel: Die Notiz klebt am Kunden und am Fall. Der Website-Chat ist das Gegenteil: Die Session schließt, und wenn du die Persistenz nicht absichtlich gebaut hast, bleibt nichts zum Auditieren außer dem, was dein Anbieter zu speichern beschließt und wie lange.

Das hängt direkt daran, was passiert, wenn der Agent zweifelt oder nicht weiterweiß: Die Übergabe an einen Menschen ist nur dann billig, wenn die Oberfläche den Kontext behält. In Slack oder im CRM kommt die Person dazu und liest, was schon da steht. In einem Website-Chat ohne Persistenz fängt die Person bei null an und der Kunde wiederholt alles. Was bei dieser Übergabe mitreisen muss, steht in was ein KI-Agent macht, wenn er die Antwort nicht kennt.

Die Kanalregeln, über die nicht verhandelt wird: WhatsApp und E-Mail

Zwei der fünf Oberflächen bringen eigene Plattformregeln mit, und die sind nicht als Empfehlung gemeint: Ignorierst du sie, hört der Kanal auf zu funktionieren. Gut, das zu wissen, bevor du ein Erlebnis versprichst, das die Plattform gar nicht erlaubt.

Bei WhatsApp öffnet sich ein 24-Stunden-Kundenservice-Fenster, sobald dir ein Nutzer schreibt; innerhalb dieses Fensters darfst du mit freien Nachrichten antworten, und schreibt der Nutzer erneut, startet der Zähler neu. Außerhalb davon darfst du nur über vorab genehmigte Templates kontaktieren, nach Kategorie klassifiziert — Utility, Authentifizierung, Marketing — mit je eigenen Regeln und Kosten. Quelle: offizielle Dokumentation von Meta, WhatsApp Business Messaging Policy, abgerufen am 14. September 2026. Die operative Übersetzung fürs Agentendesign ist eindeutig: Ein WhatsApp-Agent ist standardmäßig reaktiv, und jeder Flow, der das Gespräch von sich aus eröffnen muss, gehört als genehmigtes Template designt, bevor eine Zeile Code entsteht. Was erlaubt ist und was nicht, steht im Detail in was Meta bei einem KI-Agenten auf WhatsApp erlaubt, und die kommerzielle Version des Falls in WhatsApp rund um die Uhr beantworten.

Die E-Mail hat keine Plattform, die dich sanktioniert, aber zwei genauso harte Einschränkungen: die Absenderidentität (antwortet der Agent von einer generischen Adresse, bricht die Antwortrate ein; antwortet er von der einer Person, haftet diese Person für das Gesagte) und den Thread (wer mit einem neuen Thread antwortet, zerreißt das Tracking jedes Prozesses). Keine der beiden ist technisch, und beide entscheiden, ob der Kanal taugt.

Die Entscheidungstabelle: vier Fragen, eine Oberfläche

Die Entscheidung fällt an einem Nachmittag, mit vier Fragen in dieser Reihenfolge. Die Reihenfolge zählt: Die erste streicht die Hälfte der Optionen, die übrigen justieren.

  1. Wer ist der Nutzer, und was hat er offen, wenn diese Arbeit auftaucht? Mitarbeiter in einem System → dieses System. Team im Gespräch → Slack oder Teams. Kunde, der dir schon schreibt → sein Kanal. Anonymer Besucher → Website-Chat. Niemand, weil die Arbeit von allein ankommt → E-Mail.
  2. Wie lange kann er warten, ohne sich verlassen zu fühlen? Lautet die Antwort Sekunden, muss die Architektur etwas zurückgeben, bevor sie fertig ist. Lautet sie Stunden, hast du Budget übrig und kannst es in bessere Prüfung stecken.
  3. Welche Rechte zwingt mich diese Oberfläche zu beantragen, und wie viele davon brauche ich wirklich? Wenn schon das Minimum, das die Oberfläche zulässt, mehr ist, als der Fall rechtfertigt, ist das ein legitimer Grund, die Oberfläche zu wechseln.
  4. Wenn es schiefgeht: wo steht es geschrieben? Gibt es keine Antwort, baust du die Persistenz vor dem Start — oder du wählst eine andere Oberfläche.

Und eine Architekturregel, die alles davor umkehrbar macht: Der Agent ist ein Service, der Kanal ist eine dünne Schicht obendrauf. Wenn die Logik — die Schritte, die Bedingungen, die Aufrufe in deine Systeme — im visuellen Builder des Chat-Anbieters lebt, ist ein Oberflächenwechsel kein Umzug, sondern ein Neubau. Lebt sie auf deiner Seite, hinter einem Vertrag aus Ein- und Ausgabe, dann ist es Tagearbeit, denselben Agenten vom Web nach WhatsApp oder vom eigenen Tab nach Teams zu verschieben. Genau diese Bedingung macht die Oberflächenentscheidung zu etwas, das du korrigieren kannst, wenn dir die Nutzungsdaten widersprechen.

Wir fangen hier an, vor dem Modell und vor dem Prompt: wo die Arbeit liegt, wer sie macht und was diese Person in dem Moment offen hat. Das liegt unter KI-Adoption für Teams — denn KI im Unternehmen zu haben ist nicht dasselbe, wie dass das Unternehmen KI benutzt — und das wird mit KI-Infrastruktur für Unternehmen gebaut, wenn der Agent in Systemen leben muss, die bereits in Produktion sind. Der Rest des Aufbaus — Berechtigungen, Autonomie, Gedächtnis, Evals — steht in einen KI-Agenten bauen, der Produktion aushält.

Häufig gestellte Fragen

In dem, der schon offen ist, wenn die Arbeit auftaucht — und das hängt davon ab, wer der Nutzer ist. Ist es eine Mitarbeiterin, die im CRM oder ERP lebt, gehört der Agent in dieses Werkzeug, direkt neben den Datensatz, den er anfassen wird. Entsteht die Arbeit in einem Teamgespräch, gehört er in Slack oder Teams. Ist der Nutzer ein Kunde, der dir ohnehin über WhatsApp schreibt, gehört er dorthin — mit Metas Regeln eingebaut. Ist es ein anonymer Besucher deiner Website, gehört er in den Website-Chat. Und landet der Prozess ohnehin in einem Postfach — Lieferanten, Bestellungen, Rechnungen —, gehört er in die E-Mail. Eine einzige Betriebsregel deckt das ab: der Agent schafft keine neue Oberfläche, er zieht in eine ein, die es schon gibt. Jede zusätzliche Oberfläche, die du öffnen lässt, ist ein Aufmerksamkeitszoll, den jemand täglich zahlt — und der Zoll ist gemessen: die im August 2022 von Harvard Business Review veröffentlichte Untersuchung an 137 Beschäftigten in drei Fortune-500-Unternehmen zählte rund 1.200 Wechsel pro Tag zwischen Anwendungen und Fenstern, knapp vier Stunden pro Woche — etwa 9 % der Arbeitszeit — allein fürs Wiederhineinfinden. Quelle: How Much Time and Energy Do We Waste Toggling Between Applications?, Harvard Business Review, August 2022.

Weil das Problem fast nie die Antwortqualität ist, sondern die Entfernung bis zur Antwort. Ein Agent in einem eigenen Tab verlangt drei Entscheidungen vor der ersten Frage: daran denken, dass es ihn gibt, das Laufende liegen lassen, und den Kontext noch einmal erzählen, den das Werkzeug von vorhin schon hatte. Alle drei sind gratis für die, die ihn gebaut haben, und teuer für die, die ihn benutzen — und sie reichen, damit die Nutzung in drei Wochen von selbst einbricht, ohne eine einzige Beschwerde. Zwei Symptome bestätigen das in fünf Minuten: die Nutzung konzentriert sich auf die Leute, die bei der Demo dabei waren, und die Fragen sind solche, deren Antwort der Nutzer schon kannte — er testet das Spielzeug, er arbeitet nicht. Die Hypothese zu prüfen ist billig: setz denselben Agenten in das Werkzeug, in dem die Arbeit entsteht, und miss neu.

Das Zeitbudget setzt der Kanal, nicht das Modell, und es reicht von Sekunden bis Stunden. Im Website-Chat mit jemandem, der gerade entscheidet, ob er kauft, ist die Sitzung nach wenigen Sekunden ohne Lebenszeichen verloren: dort braucht es ein schnelles Modell und eine Teilantwort, während gearbeitet wird. In Slack oder Teams ist die Unterhaltung gewohnheitsmäßig asynchron, also sind Dutzende Sekunden drin, solange der Agent den Eingang bestätigt. Im CRM oder ERP gilt: ist die Aktion ein Knopf, auf den jemand wartet, sind es wieder Sekunden; schreibt ein Hintergrundlauf das Ergebnis in den Datensatz, dürfen es Minuten sein. Bei E-Mail ist der implizite Standard Stunden. Praktische Folge: die Oberfläche beschränkt die Architektur. Ein latenzhungriger Kanal zwingt dich, Modelle aufzuteilen und etwas zurückzugeben, bevor du fertig bist — und das wird vor dem Bauen entschieden, nicht danach.

Die der Oberfläche, und das sind standardmäßig mehr, als du denkst. Ein Agent im CRM erbt das Rechtemodell des CRM, und das ist der gute Fall: sieht der Vertriebler diesen Account nicht, sollte der Agent ihn auch nicht sehen — das ist schon gelöst. Ein Agent in Slack oder Teams wird als App mit eigenen Scopes installiert, und der Scope «Kanalverlauf lesen» ist deutlich breiter als der Anwendungsfall braucht: meist reicht, auf Erwähnungen zu reagieren. Ein Agent im öffentlichen Website-Chat spricht mit nicht authentifizierten Fremden, darf also ohne vorherigen Identifikationsschritt keinen Zugriff auf Daten eines konkreten Kunden haben. Und ein E-Mail-Agent hat das umgekehrte Problem: ein Postfach sammelt die Historie von allem, also grenzt man über Label oder Ordner ein, nie über das ganze Postfach. Die Regel ist bei allen fünf gleich: Rechte werden pro Anwendungsfall beantragt und mit Datum überprüft, nie so übernommen, wie der Installer sie anbietet. Das ganze Detail steht in welche Rechte ein KI-Agent bekommen sollte.

Ja, und viel billiger als befürchtet — vorausgesetzt, die Logik steht nicht im Kanal. Die Bedingung ist architektonisch: der Agent muss ein Dienst mit eigenem Ein- und Ausgabevertrag sein, der Kanal eine dünne Anschlussschicht darüber. Dann ist der Umzug vom Website-Chat zu WhatsApp oder vom eigenen Tab nach Teams Arbeit von Tagen. Lebt die Logik dagegen im visuellen Baukasten des Chat-Anbieters — Schritte, Bedingungen und Aufrufe in deine Systeme, gezeichnet in dessen Werkzeug —, dann ist es kein Umzug, sondern ein Neubau, und das ist die echte Rechnung für eine schnelle Wahl. Genau deshalb fällt die Oberflächenentscheidung zuerst: nicht weil sie unumkehrbar wäre, sondern weil sie bestimmt, ob sie umkehrbar sein wird.

KI-Impact-Plan · kostenlos

Der Guide ist generisch. Dein Plan nicht.

Erzähl uns von deinem Unternehmen und du bekommst eine Diagnose mit Prioritäten, Zahlen und dem, was zuerst gebaut wird. Ohne Sales-Termin, ohne einen Euro zu zahlen.

In welchem Kanal gehört ein KI-Agent hin: die Oberfläche entscheidet, ob er benutzt wird · Implementa