Die bisherigen Teile dieses Kapitels haben nach innen geschaut: Auf den Aufbau eines KI-Prozesses, auf das deterministische Rückgrat und auf die Frage, wo KI entscheiden darf und wo besser nicht. Dieser Beitrag dreht die Perspektive um und fragt, wie Anwender*innen KI erleben, wenn sie nicht neben der Anwendung läuft, sondern in ihr.
Ein Beispiel aus dem PLM-Alltag: Konstrukteur*innen haben einen Bauteildatensatz geöffnet und fragen in normaler Sprache: „Welche Änderungsanträge betreffen dieses Teil, und welcher ist noch offen?“ Die Antwort erscheint nicht in einem separaten Chatfenster, das sie erst mühsam mit dem geöffneten Objekt abgleichen müssten. Sie entsteht in der Anwendung: Der Agent arbeitet im Kontext genau des Datensatzes, der gerade offen ist. Er findet die verknüpften Anträge, zeigt sie in der Bedienoberfläche an, prüft ihren Status, bereitet das Ergebnis auf und erklärt den Zusammenhang dort, wo die Arbeit ohnehin stattfindet.
Zugriff ist nicht Integration
Dass ein Agent über eine Schnittstelle auf eine Anwendung zugreifen kann, wird zunehmend selbstverständlich. Standards wie MCP machen es leichter, Werkzeuge, Daten und Funktionen einer Anwendung für Agenten bereitzustellen. Das ist wichtig, aber es ist noch keine Produktintegration.
Ein externer Agent bleibt ein externer Agent. Er nutzt die Anwendung als Werkzeug. Die Oberfläche, das Interaktionsmodell, die Laufzeit, die Modellwahl und die Regeln seines Handelns liegen außerhalb des Produkts. Die Anwendung kann Funktionen bereitstellen, aber sie gestaltet den Agenten nicht wirklich.
Der Anspruch der PROSTEP AI Workbench (PAW) und der zugehörigen Sprache APL ist ein anderer. Der Agent soll nicht nur auf die Anwendung zugreifen. Er soll als Teil der Anwendung entworfen werden können, mit passender Oberfläche, kontrollierten Fähigkeiten, beschriebenen Abläufen, klaren Rückfragepunkten, Rechten, Protokollierung und Modellwahl. Er wird damit von einem bloßen Nutzer zu einer Funktion der Software. Der Unterschied liegt also nicht darin, dass der Agent eine Schnittstelle nutzen kann, sondern darin, wer ihn gestaltet und begrenzt.
Der Agent als Teil der Anwendung
Ein Agent, der neben der Anwendung läuft, kann zwar vieles, was auch ein voll integrierter Agent täte. Mit geeigneten Schnittstellen ermittelt er den Anwendungskontext und die Struktur der Bedienoberfläche und nutzt diese Information, um den Anwender*innen zu assistieren. Da hören allerdings dann die Gemeinsamkeiten auf. Schon bei der Frage des Datenschutzes ist für die meisten externen Agenten eine Grenze erreicht, weil sie keine Erlaubnis haben, lokale oder unternehmensspezifische Modelle zu nutzen.
Die gravierendere Einschränkung aber besteht darin, dass die Steuerungsfähigkeit nur in eine Richtung geht, nämlich vom Agenten zur Anwendung. Umgekehrt wird es schwierig – die Anwendung kann den Agenten nur sehr eingeschränkt beeinflussen. Und das unterscheidet den integrierten Agenten grundlegend von einem externen Tool. Einen integrierten Agenten kann man tiefer konfigurieren, man kann in seine internen Abläufe eingreifen lassen, um ein bestimmtes Verhalten zu erzeugen und ihn dazu veranlassen, auf Steuerkommandos der umgebenden Software direkt zu reagieren.
Je nach Anwendung kann diese Integration auch die Spracheingabe und -ausgabe umfassen. Die Anwender*innen können eine Aufgabe diktieren, statt sie in ein Formular oder Chatfenster zu tippen; der Agent kann Rückfragen stellen oder ein Ergebnis vorlesen, wenn das zur Arbeitssituation passt. Sprache ist dabei keine separate Spielerei, sondern eine weitere Bedienform derselben Anwendung, mit demselben Kontext, denselben Rechten und denselben kontrollierten Fähigkeiten.
Für die Anwender*innen heißt das, dass sie in ihrer gewohnten Oberfläche bleiben und ihr Anliegen in natürlicher Sprache formulieren, statt in einer grafischen Oberfläche zu klicken. Der Agent arbeitet im System, so dass kein Wechsel zwischen Werkzeugen und keine manuelle Übertragung von Ergebnissen erforderlich sind. Die Unterstützung sitzt dort, wo die Arbeit stattfindet. Aus Sicht des Produktteams bedeutet das, dass der Agent gestaltbar ist. Sein Verhalten, seine Oberfläche, seine Eingriffstiefe und seine Grenzen sind Teil des Produktentwurfs. Er ist damit mehr als ein persönlicher Assistent der Anwender*innen: Er ist eine auslieferbare Produktfunktion. Zugespitzt kann man sagen, dass Anwendung und Agent miteinander verschmelzen.
Kontrollierte Fähigkeiten statt freier Werkzeugzugriff
Zuverlässig wird ein solcher Agent aber nicht dadurch, dass man ihm einfach eine lange Werkzeugliste gibt: Zugriff auf viele Werkzeuge macht sein Handeln noch nicht zuverlässig. Wenn er selbst frei entscheidet, welches Werkzeug aus einer Liste von einigen hundert er wann, wie oft und in welcher Reihenfolge nutzt, ist das Risiko groß, dass er oft daneben liegt. Es ist also wichtig, ihm eine möglichst kleine, gut gewählte Liste von Werkzeugen zur Verfügung zu stellen, die auf die jeweils gestellte Aufgabe zugeschnitten ist. APL unterstützt genau das: Den Agenten situativ mit ausgewählten Werkzeugen ausstatten, das passende Sprachmodell wählen und ihn damit eine dedizierte, abgegrenzte Aufgabe lösen lassen. Nutzt man dann noch die Fähigkeit von APL, anspruchsvollere Abläufe als KI-Prozedur mit algorithmischen und kognitiven Anteilen zu strukturieren, statt einen Agenten frei improvisieren zu lassen, erhält man eine anforderungsgerechte Skalierung der KI-Integration – von freier Interaktion mit dem Agenten bis zu voll strukturierten APL-Prozeduren für komplexe, KI-lastige Teilaufgaben.
Im Beispiel der Konstrukteur*innen muss der Agent also nicht frei improvisieren, wie er offene Änderungsanträge zu einem Teil findet. Er kann eine dafür vorgesehene Fähigkeit der Anwendung nutzen: Vom geöffneten Bauteil ausgehen, verknüpfte Änderungsanträge suchen, Status prüfen, Quellen sichern, Ergebnis zusammenfassen. Der Agent erkennt die Nutzerabsicht und wählt die passende Fähigkeit aus. Die Ausführung selbst bleibt kontrolliert.
Damit verbinden sich zwei Betriebsarten. Der Agent versteht die offene Nutzerabsicht und den Kontext der Oberfläche, während APL dafür sorgt, dass die Ausführung nicht mit dem freien Lauf des Modells verschwindet, sondern als beschriebener Ablauf sichtbar, begrenzt und wiederholbar bleibt.
Anpassbar auf Oberfläche, Prozess und Modell
Dass der Agent so arbeiten kann, ist kein Zufall, sondern Teil der Architektur, die Anpassungen auf mehreren Ebenen erlaubt:
- Oberfläche und Interaktion: Wie der Agent erscheint, ob er per Text, Sprache oder beidem bedient wird, wo er Rückfragen stellt, wie Vorschläge präsentiert werden und welche Aktionen die Anwender*innen bestätigen müssen.
- Anwendungskontext: Welche Daten, Objekte, Beziehungen und Funktionen der Agent sieht, wird durch die Anwendung bestimmt.
- Prozess: Welche APL-Prozeduren verfügbar sind, welche Grenzen sie haben und welche Ergebnisse nur vorgeschlagen statt direkt geschrieben werden, ist gestaltbar.
- Modell: Welches Sprachmodell den Agenten antreibt, ist eine Entwurfsentscheidung genau wie die Frage, ob es als Cloud-Modell oder lokal betriebenes Modell eingesetzt wird, wenn Daten das Unternehmen nicht verlassen sollen.
Der letzte Punkt ist mehr als ein technisches Detail. In vielen PLM- und Engineering-Umgebungen sind Produktdaten, Konstruktionswissen und Änderungsinformationen hochsensibel. Die Architektur muss deshalb erlauben, Modellwahl, Datenfluss und Ausführung an die eigenen Anforderungen anzupassen. Modellwahl wird damit Teil der Produkt- und Betriebsentscheidung, nicht eine versteckte Vorgabe der Agentenplattform.
Dasselbe Muster über PLM hinaus
Der eingebaute Agent ist kein PLM-Sonderfall. Dasselbe Muster trägt in ganz anderen Anwendungen. Im Präsentationsgenerator erzeugt der Agent nicht nur Text. Er arbeitet an einem gestalteten Artefakt: Folien, Layouts, Platzhalter, fertige Ansichten. Er kann eine Folie erzeugen, das Ergebnis als Bild betrachten und Layoutprobleme erkennen, bevor die Nutzenden sie sehen. Das ist nur möglich, weil der Agent im Werkzeug sitzt und dessen Ausgabe unmittelbar beurteilen kann.
In einem Diagrammwerkzeug bearbeiten Mensch und Agent dieselbe strukturierte Arbeitsfläche. Der Mensch verschiebt ein Element, der Agent ergänzt Beziehungen, schlägt eine Struktur vor oder bereinigt eine Darstellung, und zwar am selben Artefakt und nicht abgekoppelt daneben. Der Agent arbeitet mit den Daten, Funktionen und Ergebnissen der Anwendung. Und er verbindet offene Nutzerabsicht mit kontrollierten Fähigkeiten des Produkts. Die Produktintegration ist der gemeinsame Punkt.
Die Frage der Verlässlichkeit
Der Agent in der Oberfläche ist damit nicht einfach ein Chat mit Zugriff auf Anwendungswerkzeuge, sondern eine gestaltete Produktfunktion. Sie ist sichtbar im Look and Feel der Anwendung, gebunden an ihren Kontext, begrenzt durch ihre Regeln und ausgestattet mit kontrollierten Prozessfähigkeiten. Der Mensch formuliert, was erreicht werden soll. Der Agent versteht den Anwendungskontext und wählt die passende Fähigkeit. APL sorgt dafür, dass die Ausführung sichtbar, begrenzt und wiederholbar bleibt. Heute sprechen wir noch von einem Agenten, der in eine Anwendung integriert wird. Die Entwicklung geht jedoch weiter: Je vollständiger die KI-Fähigkeiten mit den Funktionen des Produkts verschmelzen, desto weniger bleibt ein abgrenzbarer Agent übrig. Am Ende ist die Anwendung selbst agentisch.
Damit stellt sich die nächste Frage, und sie ist die kritischste: Woher weiß man, dass ein solcher Agent seine Aufgabe verlässlich erledigt und nicht nur im Demo-Fall überzeugt? Gerade weil er in der Anwendung läuft und seine Arbeit in beschriebenen Abläufen stattfindet, lässt er sich systematisch beobachten und prüfen. Er ist kein undurchschaubares System, sondern Bestandteil der Anwendung, so dass sein Verhalten sich messen und weiterentwickeln lässt. Darum geht es im nächsten Teil dieses Kapitels.
