Bild wurde mit Hilfe von KI generiert
Ein Nachmittag im Beratungsteam: die Notiz, die niemand wiederfindet
Statusmeeting, Donnerstagnachmittag. Ein Berater erwähnt beiläufig, dass der Kunde die Lieferfrist doch noch einmal verschieben will, eine kleine Randbemerkung zwischen zwei Tagesordnungspunkten. Jemand notiert sich dies und tippt zusätzlich diese Information schnell in den Firmen-Chatbot, Langdock oder Copilot, ganz gleich. Der Bot antwortet im Moment hilfreich, formuliert sogar einen sauberen Vorschlag für die interne Kommunikation.
Nur: Was hier tippt und antwortet, ist ein einfacher Chat ohne eigene Wissensdatenbank. Er kennt das laufende Gespräch, sonst nichts. Auf frühere Notizen hat er keinen Zugriff, und zurückgeschrieben wird auch nichts.
Die neuen „Memory“-Funktionen, die Copilot seit diesem Jahr schrittweise ausrollt, ändern daran wenig: Sie merken sich Vorlieben und Arbeitsweisen einer einzelnen Person, damit Antworten persönlicher wirken. Ein geteiltes Team-Wissen, das eine Kollegin später wiederfinden kann, ist das nicht.
Wochen später: die Rückfrage, auf die niemand eine Antwort hat
Zum Beispiel: Wochen später fragt eine Kollegin denselben Chatbot nach genau diesem Detail. Keine Antwort. Nicht, weil die Technik versagt, sondern weil das Wiki nie aktualisiert wurde und der Bot nur dort sucht, wo längst nichts mehr steht.
Also verschwindet die Information dort, wo sie entstanden ist: im Chatverlauf einer einzelnen Person. Vielleicht taucht sie noch einmal in einer privaten Mail auf, oder in einem Meeting-Protokoll, das jemand pflichtschuldig abspeichert und nie wieder öffnet. Genauso gut landet sie ordentlich notiert in einem persönlichen Notizbuch, etwa in Microsoft OneNote, sauber aufgeschrieben und trotzdem nicht geteilt und kaum wiederauffindbar wie im Chatverlauf. Chat, Mail, Protokoll, Notizbuch, es ist letztlich egal, welches Werkzeug die Notiz zuletzt hält: Keins davon schlägt die Brücke in den Alltag, in ein Tool, in dem jemand Anderes später suchen würde.
Das Wiki verwaist nicht, weil die Technik fehlt oder ein Notiz-Tool. Es verwaist, weil das Übertragen von Wissen aus dem Kopf ins System immer ein zusätzlicher, manueller Schritt bleibt, den in der Hektik niemand geht. Am Ende steht Frustration, doppelte Nachfragen, verlorene Zeit. Genau hier setzt dieser Artikel an.
Die Entscheidung: der Agent soll nicht nur lesen, sondern zurückschreiben
Die Notiz zur Lieferfrist stand nirgendwo. Sie lag nur im Kopf des Beraters und in einer E-Mail, die er sich selbst geschickt hatte,. Gesehen hat sie sonst niemand. Genau das ist dem Team im Nachgang aufgefallen: Dieses Muster wiederholt sich ständig. Wissen entsteht im Gespräch, im Meeting, zwischen zwei Tagesordnungspunkten, wird aber nie in etwas überführt, das ein Chatbot später finden könnte.
Wenn niemand manuell nachträgt, dann gibt es eine Option: Der Agent muss das Nachtragen selbst übernehmen. Neue Informationen strukturiert ablegen, statt nur als Chatbot im Moment zu antworten und danach alles wieder zu vergessen. Vom Assistenten, der nur als Chatbot antwortet, zum Agenten, der handelt und Wissen abspeichern kann.
Bild wurde mit Hilfe von KI generiert
Eine Bedingung steht dabei von Anfang an fest: Schreiben ja, aber nicht unkontrolliert. Jeder Eintrag geht zuerst als Vorschlag an einen Menschen. Erst, wenn jemand ihn bestätigt, landet er wirklich in der Wissensdatenbank. Man spricht von einem Agenten mit eigener Wissensdatenbank, also Knowledge Base, denn worauf es ankommt, ist nicht der Schreibakt, sondern das strukturierte Gedächtnis, das dabei entsteht. Damit ist der eigentliche Dreh- und Angelpunkt des Falls gesetzt: Aus dem Frage-Antwort-Bot wird ein Gedächtnis, das dem ganzen Team gehört und das mit jeder bestätigten Notiz ein Stück mitwächst.
Hinter den Kulissen: Chatfenster, Werkzeug-Server und ein Wiki-Gedächtnis nach OKF
Wie genau soll das jetzt funktionieren? Der Berater fragt seinen IT-Kollegen, was eigentlich hinter dem Chatfenster passiert, in das er gerade seine Notiz getippt hat. Wir zeichnen die Antwort in drei einfachen Schritten auf.
Schritt eins: das Chatfenster
Alles beginnt dort, wo das Team ohnehin schon tippt. Ob Langdock oder Microsoft Copilot, spielt keine Rolle. Beide sind einfach „ein Eingabefenster“, über das Menschen mit dem Agenten sprechen. Das Prinzip dahinter bleibt bei beiden gleich.
Schritt zwei: die Information kommt ins System
Ein Sprachmodell kann von sich aus nichts speichern. Es erzeugt nur Text. Damit aus dem Satz „Kunde verschiebt die Frist“ wirklich ein Eintrag wird, braucht das Modell ein Werkzeug. Dieses Werkzeug reicht ihm genau die passende Funktion, etwa eine mit dem Namen „Notiz einordnen“. Fachleute nennen diesen Mechanismus Function Calling. Mehr muss man sich dazu im Moment nicht merken. Wichtig ist nur: Der Agent erkennt, wann so ein Werkzeug gebraucht wird, und ruft es auf. Genau das passiert, als der Berater seine Bemerkung zur Lieferfrist tippt. Damit dieses Werkzeug nicht nur in Langdock, sondern auch in Copilot funktioniert, verständigen sich beide Systeme über einen gemeinsamen Standard: das Model Context Protocol, kurz MCP. Für den Alltag reicht ein Bild: MCP ist wie eine genormte Steckdose anstelle eines eigenen Adapters für jedes Gerät. Ein einmal gebautes Werkzeug lässt sich so in jeder kompatiblen Chatoberfläche nutzen. Niemand muss es zweimal programmieren. Am Beispielfall zeigt sich: Der Werkzeug-Server, an den Langdock oder Copilot angebunden ist, bietet die Funktion „Notiz einordnen“ an. Das Modell erkennt, dass sie jetzt gebraucht wird, und ruft sie auf.
Schritt drei: wo das Wissen landet
Jetzt kommt der eigentlich entscheidende Schritt. Hier zeigt sich, ob aus der Notiz wirklich Wissen wird oder nur ein Eintrag, den nie wieder jemand ansieht. Statt einer komplizierten Datenbank führt der Agent eine Sammlung einfacher, miteinander verlinkter Textseiten. Jede trägt ein paar Kopfdaten, etwa wer was wann bestätigt hat. Diese Idee geht auf Andrej Karpathys Vorschlag eines „LLM-Wiki“ zurück. Google hat sie vor Kurzem unter dem Namen Open Knowledge Format, kurz OKF, zu einem offenen Standard gemacht. Der Vorteil für das Unternehmen: Diese Textseiten kann jedes Modell lesen. Es entsteht kein Lock-in an einen einzelnen Anbieter. Wechselt das Team später die Chatoberfläche oder das Werkzeug, bleibt das gesammelte Wissen einfach transportabel.
Damit der Agent aber wirklich schreiben darf, fehlen noch zwei Dinge: eine Bestätigung durch den Menschen, bevor etwas gespeichert wird, und eine Identität, unter der er handelt. Beide Themen greifen wir in den nächsten Abschnitten auf. Schon jetzt lässt sich sagen: Die Berechtigung des Nutzers wird vom Agenten über das MCP an die jeweilige Funktion weitergegeben. Dort lässt sich dann prüfen, ob der Nutzer überhaupt auf die Wissensdatenbank zugreifen und schreiben darf. Es findet also bei jedem Schreibversuch eine echte Berechtigungsprüfung statt, kein Freifahrtschein für den Agenten. Praktisch bedeutet das für den Alltag: Der Nutzer loggt sich einfach mit seinem gewohnten Microsoft-Konto per Single Sign-on an. Ein eigenes, neues Berechtigungssystem braucht es dafür nicht. Die meisten Unternehmen haben ohnehin schon Microsoft-Konten für ihre Mitarbeitenden eingerichtet.
Bild wurde mit Hilfe von KI generiert
Nachvollziehbar und konform: Identität, Berechtigung und Datenspeicherung
Im Tool taucht die Aufgabe aus dem Statusmeeting also nicht als anonymer Bot-Eintrag auf. Sie steht dort als von der Person angelegt, die den Vorschlag zuvor bestätigt hat. Der Grund dafür: Der Agent handelt nicht in seinem eigenen Namen, sondern im Namen der angemeldeten Person. Das Firmen-Login wird bis in die Datenbank durchgereicht, einen anonymen Sammel-Account, unter dem alle möglichen Änderungen verschwinden, gibt es nicht.
Warum das mehr ist als Formalie, zeigt sich erst später, wenn jemand nachfragt, wer eine Aufgabe wann angelegt hat: Jede Änderung hängt an einer echten Person und einem Zeitpunkt, das macht die Antwort des Agenten nachvollziehbar und im Zweifel auditierbar, nicht nur bequem. Weil sich der Nutzer mit seinem gewohnten Microsoft-Konto per SSO anmeldet, bleiben auch die Daten selbst dort, wo sie ohnehin schon liegen: innerhalb der Compliance-Grenze von Microsoft, so wie ein Unternehmen seinen SharePoint pflegt, mit EU-Datenstandort und denselben ISO- und SOC2-Nachweisen, die für die übrigen Microsoft-365-Daten längst gelten.
Was der Agent jetzt tatsächlich kann: Notiz, Aufgabe, Statusbericht, Rückfrage
Die Notiz aus dem Statusmeeting durchläuft genau diese Kette. Der Agent liest sie nicht nur und quittiert sie mit einem höflichen Satz, sondern schlägt vor, wie sie einzuordnen ist, etwa als neuer Punkt im Projekt-Wiki unter „offene Risiken“, direkt verknüpft mit dem betroffenen Kunden oder zu einem Projekt. Aus derselben Notiz leitet er eine Aufgabe ab: verantwortliche Person, Frist, kurze Beschreibung. Gespeichert ist sie damit noch nicht, sie liegt als Entwurf da, bis sie jemand bestätigt.
Auf Zuruf zieht der Agent aus genau diesen Einträgen einen Statusbericht: was seit dem Meeting dazugekommen ist und wer was entschieden hat. Niemand muss dafür Mails durchsuchen oder sich an Details erinnern, die längst wieder verblasst sind. Wochen später fragt ein Kollege beiläufig, was mit Kunde X eigentlich vereinbart wurde. Diesmal antwortet der Agent, und zwar nicht aus dem Kurzzeitgedächtnis eines einzelnen Chats, sondern aus der Wissensdatenbank, die genau diese Notiz vorher aufgenommen, geprüft und bestätigt hat.
Bild wurde mit Hilfe von KI generiert
Vier Fähigkeiten, mehr nicht. Notiz einordnen, Aufgabe anlegen, Bericht erzeugen, Rückfrage beantworten. Das ist der komplette Werkzeugkasten für den Anfang. Der Agent wird nicht dadurch nützlich, dass er möglichst viel kann, sondern dadurch, dass genau diese vier Schritte zuverlässig funktionieren. Zehn Tools auf einmal hätten an dieser Stelle nur für Verwirrung gesorgt, ohne dass irgendjemand im Team hätte sagen können, welches Werkzeug wann greift.
Was beim Bauen schiefgehen kann
Vier Punkte, die man beim Aufbau des Systems beachten sollte:
- Zu viele Werkzeuge auf einmal: Ein Agent mit zehn Funktionen verwirrt eher, als dass er hilft. Besser, man startet mit den vier Fähigkeiten aus dem Fall und erweitert erst, wenn die sich im Alltag bewährt haben.
- Schreibrechte ohne Bestätigungsschritt: Jede automatische Speicherung ohne Prüfung untergräbt genau das Vertrauen, das der Fall mühsam aufgebaut hat, und zwar sofort beim ersten falschen Eintrag.
- Wissen in einem proprietären Format ohne Exportweg: Offene Textdateien nach OKF-Muster lassen sich jederzeit in ein anderes System übertragen. Ein geschlossenes Ablageformat wie PDF oder Word dagegen bindet das Team an einen Anbieter, ob gewollt oder nicht.
- Fehlende Tests für Werkzeugaufrufe: Ungetestet kann ein falsch interpretierter Aufruf eine Aufgabe an die falsche Person hängen oder einen Eintrag verfälschen. Dies fällt erst auf, wenn sich jemand auf genau diese falsche Antwort verlässt.
Vier Punkte, die auf den ersten Blick banal wirken. Genau das macht sie gefährlich: Sie werden nicht durch fehlendes Fachwissen übersehen, sondern durch Eile beim Aufbau.
Klein anfangen: ein Team, ein Anwendungsfall
Wochen nach dem Statusmeeting stellt ein Teammitglied genau die Rückfrage, die früher tagelanges Mail-Wühlen bedeutet hätte. Der Agent zieht die Antwort direkt aus der damaligen Notiz, inklusive der Info, wer sie erfasst und bestätigt hat. Aus einer einzigen bestätigten Notiz ist damit mehr geworden als eine beantwortete Frage. Es ist ein nachvollziehbarer Wissensbaustein entstanden, der auch in drei Monaten noch trägt.
Bild wurde mit Hilfe von KI generiert
Andere Teams im Haus hören davon und wollen denselben Effekt. Die Versuchung liegt nahe, gleich das große Wissensprojekt aufzusetzen, alle Abteilungen, alle Dokumente, ein Rollout an einem Stichtag. Genau das wäre der falsche Schluss aus diesem Fall. Die eigentliche Lehre ist, klein zu bleiben: ein Anwendungsfall, ein Team, und erst, wenn sich das im Alltag bewährt hat, weitere Fähigkeiten und weitere Teams dazunehmen.
Ein Big-Bang-Rollout über alle Abteilungen gleichzeitig überfordert eher, als dass er überzeugt, und bringt Akzeptanzprobleme statt des schnellen Vertrauens, das die Teammitglieder in wenigen Wochen aufgebaut haben.
Gerne schauen wir uns Ihren Fall an und ermitteln gemeinsam, ob sich bei Ihnen eine Wissensdatenbank aufbauen lässt. Buchen Sie dafür einfach einen Workshop oder eine Demo, in der wir Ihren ersten Anwendungsfall identifizieren.
Wer über diesen Anwendungsfall hinaus wissen möchte, was AI-Agenten sonst noch für den Arbeitsalltag leisten können, findet im Geschäftsbereich AI Transformation von CubeServ weitere Anregungen.
