Context Management einführen: Prozess, Skill und Wissen verbinden

Beginnt mit dem fachlichen Ablauf von der eingehenden Anfrage bis zum bearbeiteten Servicefall. In unserem Beispiel meldet eine Kundin, dass ihre Waschmaschine nicht startet. Der Customer Service nimmt die vorhandenen Angaben auf. Die Aktivität „Serviceübergabe vorbereiten“ soll ein Agent übernehmen; anschließend prüft ein Mensch den Entwurf und gibt ihn an den technischen Service weiter. Dort wird der Fall fachlich bearbeitet und abgeschlossen.

Im Prozessmodell ordnet ihr die Aktivitäten den ausführenden Rollen zu, etwa in eigenen Lanes für Customer Service, Agent und technischen Service. Für die ausgewählte Agentenaktivität werden Eingang und erwartetes Ergebnis beschrieben: Aus den bisher vorliegenden Angaben soll eine Fallnotiz entstehen, die Fehlendes kenntlich macht und die verwendete Wissensgrundlage nennt. Die folgende vereinfachte Darstellung zeigt diese Einordnung und die Verbindung zur externen Umsetzung.

Für diesen ersten Schritt entscheidet der Agent weder über eine Reparatur noch über einen Servicetermin. Er liefert einen prüfbaren Entwurf zurück. Eine ungeklärte Modellkennung bleibt als Rückfrage sichtbar; ergänzte Angaben können anschließend erneut in die Vorbereitung eingehen. Die Rollen im Prozess zeigen dabei, wer welche Arbeit übernimmt. Technische Zugriffsrechte und der Aufruf des Agenten müssen bei der Umsetzung gesondert eingerichtet werden.

Die gemeinsame Arbeitssitzung braucht die Perspektiven der Erstaufnahme, der weiteren Bearbeitung und der fachlichen Verantwortung für die Anleitung. Wer die Agentenaktivität umsetzt, klärt zusätzlich den Aufruf und die benötigten Anbindungen. Nutzt einen geeigneten anonymisierten Fall oder einen ausdrücklich fiktiven. Unser Beispiel entwickelt die Trennung zwischen Kontext, KI-Unterstützung und Fachanwendung aus meinem Beitrag „Wenn KI mitarbeitet“ weiter.

Die Ausgangsnotiz enthält das Anliegen, lässt aber offen, welche Informationen die weitere Bearbeitung benötigt. Geht den Fall mit der Person durch, die ihn nach der Übergabe übernehmen soll. Sobald sie eine Rückfrage stellen müsste, haltet fest, wofür die Antwort gebraucht wird. Damit legt ihr die Anforderungen an das Ergebnis der Aktivität fest, bevor ihr die internen Arbeitsschritte des Agenten beschreibt.

Im Beispiel fehlt zunächst die Modellbezeichnung, ohne die sich die passende Serviceanleitung nicht zuverlässig zuordnen lässt. Auch die Aussage „startet nicht“ muss genauer beschrieben werden, bevor der technische Service sie einordnen kann. Welche Rückfragen die Erstaufnahme stellen soll, legt der Service anhand seiner gültigen Anleitung fest. Ihr Ergebnis bleibt eine bessere Beschreibung des Falls; eine technische Ursache ist damit noch nicht festgestellt.

Für die Aktivität „Serviceübergabe vorbereiten“ werden nun die fachlichen Wissensquellen zugeordnet. Im Zielbild sind die passende Serviceanleitung und die Regel für die weitere Übergabe mit dieser Aktivität in PULSE verbunden. So können sowohl die Mitarbeitenden als auch eine entsprechend angebundene KI erkennen, welche Grundlagen an dieser Stelle verwendet werden sollen. Die Auswahl richtet sich zusätzlich nach dem Fall, beispielsweise nach der Modellreihe.

Die Verknüpfung mit der Aktivität beschreibt die Verwendung des Wissens. Sie sollte genauer sein als eine lose Sammlung aller Dokumente zum Thema Service. Eine Anleitung für Wartungsarbeiten kann fachlich richtig sein und trotzdem nicht zur Störungsaufnahme durch den Customer Service passen. Die verantwortlichen Personen müssen deshalb klären, für welche Tätigkeit, Zielgruppe und Modellreihe die zugeordnete Anleitung gilt.

Die Kundenmeldung bleibt dagegen Teil des einzelnen Vorgangs. Sie wird dem Agenten für diesen Auftrag mitgegeben oder über einen dafür eingerichteten Zugang abgerufen. PULSE muss dafür nicht jede Fallakte übernehmen. Der gemeinsam gepflegte Unternehmenskontext und die aktuellen Fallangaben kommen erst bei der Bearbeitung der konkreten Aktivität zusammen.

Wenn zwei Quellen für dieselbe Tätigkeit und Modellreihe unterschiedliche Regeln vorgeben, muss die fachliche Verantwortung diese Zuordnung klären. Die zusätzliche technische Anbindung kann festhalten, welche Quellen gefunden wurden; sie entscheidet dadurch noch nicht, welche widersprüchliche Regel im Unternehmen gelten soll.

Ein Skill in Claude Code enthält Anweisungen, die der Agent für eine bestimmte Aufgabe verwenden kann. Er kann auch auf ergänzende Dateien oder Skripte verweisen. Die Ausführung übernimmt der Agent mit seinen Werkzeugen. Wenn wir hier von einem Wissensabruf „durch den Skill“ sprechen, ist also der Abruf gemeint, den der Agent unter Anleitung des Skills ausführt.

Für unser Beispiel würde der Skill beschreiben, wie aus der Eingangsmeldung der Entwurf einer Serviceübergabe entsteht. Er könnte den Agenten anweisen, die Aktivität zuzuordnen, ihre benötigten Wissensquellen abzurufen und mit den Angaben des Falls abzugleichen. Anschließend soll er eine Fallnotiz vorbereiten, fehlende Informationen offenlassen und die verwendeten Quellenstände nennen.

Der Skill kann intern mehrere Schritte enthalten, ohne dass ihr jeden davon in der fachlichen Prozessübersicht darstellt. Ein BPMN-Task beschreibt Arbeit auf der gewählten Detailebene; ein zugeklappter Teilprozess verweist auf einen fachlich untergliederten Ablauf. Die Existenz eines Skills allein legt deshalb nicht fest, welche dieser Darstellungen passend ist.

Für die Zusammenarbeit reicht zunächst eine nachvollziehbare Zuordnung: Welche Agentenumsetzung bearbeitet diese Aktivität, welchen Skill verwendet sie und welches Ergebnis soll zurückkommen? Ein Skill kann auch für mehrere Aktivitäten nutzbar sein. Dann muss er jeweils erkennen können, in welchem fachlichen Zusammenhang er gerade eingesetzt wird.

Der Agent braucht für einen gezielten Abruf eine eindeutige Zuordnung zum Prozess und zur Aktivität. In unserem Beispiel soll er nicht allgemein nach allem suchen, was zur Waschmaschine vorhanden ist. Er benötigt die Quellen, die für „Serviceübergabe vorbereiten“ vorgesehen sind, und daraus die für den konkreten Fall geltenden Inhalte. Prozess- und Aktivitätsreferenz sowie gegebenenfalls die Modellreihe müssen deshalb beim Auftrag oder beim Abruf bekannt sein.

MCP, das Model Context Protocol, kann den technischen Zugang zwischen der KI-Anwendung und den bereitgestellten Informationen herstellen. Welche Inhalte zur Aktivität gehören und wie die KI sie anschließend verwendet, ergibt sich aus der fachlichen Zuordnung und der Implementierung des Abrufs; das Protokoll legt dies nicht selbst fest.

Für das Zielbild muss die Anbindung also die Aktivitätsbezüge und die benötigten Wissensinhalte zugänglich machen. Eine Verknüpfung in der Benutzeroberfläche allein genügt dafür noch nicht. Prüft konkret, ob der eingerichtete Zugang den benötigten Umfang unterstützt und welche Informationen er innerhalb der jeweiligen Zugriffsrechte zurückgibt. Dazu gehören nachvollziehbare Quellen und Fassungen, damit das Ergebnis später überprüft werden kann.

Ist die Modellkennung unbekannt oder keine passende Quelle zugänglich, gehört diese Lücke in den Entwurf. Der Agent soll dann nicht eine beliebige Anleitung auswählen, nur um eine vollständige Notiz zu erzeugen. Im Musterfall weiter unten verwenden wir ausdrücklich die fiktive Anleitung SA-07 für WM-DEMO in Version 2. Welche Fassung tatsächlich gilt, muss der Abruf für den jeweiligen Fall ergeben; eine Versionsnummer wird nicht dauerhaft im Skill festgeschrieben.

Das Ergebnis der Agentenaktivität geht an den Customer Service zurück. Die Mitarbeiterin prüft, ob die Notiz die vorhandenen Angaben korrekt wiedergibt und offene Fragen kenntlich macht. Für unseren ausgefüllten Musterfall nehmen wir an, dass die Kundin inzwischen die Modellkennung genannt und ihre Beobachtung genauer beschrieben hat. Nach der Prüfung könnte die Fallnotiz so aussehen; sie ist ein konstruiertes Beispiel und keine Ausgabe eines durchgeführten Agententests.

Die Fallnotiz unterscheidet die Beobachtung der Kundin vom fachlichen Befund. „Display dunkel“ wird nicht in „Elektronik defekt“ umgeschrieben. Auch aus einer angefragten Serviceleistung entsteht noch kein bestätigter Termin.

Die eigentliche Übergabe erfolgt anschließend in der Serviceanwendung beziehungsweise über die dafür eingerichtete Ausführung. Eine vorbereitete Notiz bedeutet noch nicht, dass der technische Service den Vorgang bereits übernommen hat. Für den Gesamtprozess muss erkennbar sein, wann der Entwurf geprüft, der Fall weitergegeben und die nächste Bearbeitung aufgenommen wurde. Diese Zustände gehören zum laufenden Vorgang.

Prüft zuerst, ob die Fallnotiz für die nächste Person fachlich brauchbar ist. Danach betrachtet ihr die technische Unterstützung entlang derselben Aktivität: Hat der Agent den richtigen Prozessbezug erhalten, die passende Wissensquelle tatsächlich abgerufen und ihre Aussagen im Entwurf richtig angewendet? Eine gut formulierte Notiz allein zeigt noch nicht, ob sie auf den vorgesehenen Grundlagen beruht.

Verwendet dafür einen vollständigen Fall, eine fehlende Modellkennung und eine widersprüchliche Quellenlage. Betrachtet jeweils den Eingang, die abgerufenen Quellen mit ihren Fassungen und den zurückgegebenen Entwurf. Bei fehlenden Angaben sollte eine passende Rückfrage entstehen. Bei einem ungeklärten fachlichen Widerspruch muss sichtbar bleiben, was vor der Weiterbearbeitung geklärt werden muss.

Ob ihr die Umsetzung mit einem dynamisch arbeitenden Agenten oder mit einem stärker vorgegebenen Ablauf baut, hängt von der Aufgabe ab. Anthropic unterscheidet solche Agenten von festgelegten Workflows. Eine klar begrenzte Sprachaufgabe innerhalb des Serviceprozesses erfordert nicht automatisch, dass die KI auch den Gesamtprozess steuert.

Vergleicht die neue Bearbeitung mit der bisherigen Übergabe einschließlich Rückfragen, Prüfung und Korrekturen. So wird sichtbar, ob die Unterstützung den folgenden Prozessschritt erleichtert oder lediglich zusätzliche Arbeit an anderer Stelle erzeugt. Das Ergebnis dieser Prüfung entscheidet, welche Teile des Vorgehens oder der Wissensgrundlage angepasst werden sollten.

Die fachlich Verantwortlichen benötigen eine verständliche Oberfläche, um die Wissensseiten und ihre Verwendung im Prozess zu prüfen. In PULSE können sie die gemeinsame Wissensgrundlage pflegen und in ihrem Zusammenhang betrachten. Im Zielbild sollte von der Agentenaktivität aus erkennbar sein, welche Anleitung benötigt wird und wer eine offene fachliche Frage dazu klärt. Diese Orientierung hilft auch den Menschen, die die Entwürfe kontrollieren.

Die Verantwortung für den externen Skill betrifft dagegen das Vorgehen des Agenten, die Anbindungen und das erwartete Ergebnis. Fachliche Regeln, die zentral in PULSE gepflegt werden, müssen dann nicht zusätzlich als Kopie in jedem Skill stehen. Ändert eine neue Anleitung jedoch die erforderlichen Arbeitsschritte oder das Ausgabeformat, muss auch die Umsetzung überprüft werden. Ein zentraler Wissensstand erspart daher doppelte Inhaltspflege, aber nicht jede Abstimmung.

• Ein Prozessmodell mit der zugewiesenen Agentenaktivität, ihren Eingängen, Ergebnissen und menschlichen Übergabepunkten.
• Eine fachlich geklärte Zuordnung der Wissensquellen zur Aktivität einschließlich Geltung und Verantwortung.
• Eine dokumentierte externe Umsetzung mit Skill und einem überprüften Zugang zum benötigten Kontext.
• Beispielfälle und klare Prüfanlässe, etwa eine neue Modellreihe, eine geänderte Anleitung oder ein anderer Übergabeweg.

Für einen offenen Punkt sollte feststehen, wer ihn klärt und woran die Klärung erkennbar ist. Ob der derzeitige MCP-Zugang alle benötigten Aktivitätsbezüge und Wissensinhalte liefert, ist beispielsweise eine konkrete technische Frage. Ob eine Anleitung für die Erstaufnahme gelten soll, ist eine fachliche Entscheidung. Diese Trennung hält die Arbeitssitzung auch dann handhabbar, wenn noch nicht alle Teile umgesetzt sind.

Die Inventur hilft dabei, Quellen mit ihrer Verwendung an einem Prozessschritt zu erfassen. Tragt dort die Wissensbezüge eurer ausgewählten Aktivität ein. Die Zuordnungen in der Inventur festhalten