Besteht der Agent den Alltagstest?

Nehmen wir als Beispiel einen Maschinenhersteller. Der Service bekommt eine Ersatzteilanfrage mit Maschinennummer und Fehlerbeschreibung. Ein Agent soll passende Unterlagen finden und ein Angebot entwerfen; freigeben und versenden soll es weiterhin der Service. Vor der Vorführung legt eine fachkundige Person die erwarteten Ergebnisse fest: Welches Teil passt, wann muss jemand nachfragen und welche Unterlagen darf der Agent verwenden? Ohne diese Antworten lässt sich schwer beurteilen, ob ein flüssig geschriebener Entwurf auch stimmt.

Stellen Sie eine kleine Testmappe zusammen: ein eindeutiger Standardfall, eine unvollständige Maschinennummer, widersprüchliche Dokumentstände und ein Fall ohne passende Teileinformation. Halten Sie fest, welche Fassung der Unterlagen jeweils gilt. Prüfen Sie zuerst die Teilezuordnung, dann die Formulierung. Eine falsche Teilenummer wird durch eine gute Begründung nicht richtig. Sicherheitskritische Auswahlentscheidungen und Eingriffe in Anlagen bleiben außerhalb dieses Beispielauftrags. Der Leitfaden liefert dafür keine Freigabe.

Nutzen Sie freigegebene Testdaten in einer Umgebung, in der Sie die Folgen kontrollieren können. Das ausführende Konto bekommt nur die vorgesehenen Rechte. Lassen Sie den Agenten auf ein erlaubtes und auf ein gesperrtes Dokument zugreifen. Danach muss erkennbar sein, welche Quelle zur Teilezuordnung führte und was als Nächstes geschehen soll. Prüfen Sie den gesperrten Fall auch im Entwurf, in Zusammenfassungen und im Protokoll: Dort darf der verborgene Inhalt nicht wieder auftauchen. Führen Sie das als eigenen Test.

Glean sagt, dass Quellsystemrechte beim Lesen und Schreiben gelten und Aktionen auf die Freigabe eines Menschen warten können. Copilot Studio beschreibt Wissensantworten für angemeldete Nutzer, die nur auf deren zugängliche Inhalte zurückgreifen.^1,2,3

Lassen Sie sich diese Fragen für den ganzen Ersatzteilablauf beantworten. Ein Agent darf vielleicht ein Dokument lesen, aber deshalb noch nicht ins ERP schreiben. Auch eine Schaltfläche mit „Freigeben“ reicht allein nicht. Der Service muss sehen, an wen das Angebot geht und welche Position und Menge es enthält. Ändern Sie diese Angaben nach einer Freigabe probeweise. Wird vor der Ausführung erneut gefragt? Genau das sollte aus der Vorführung hervorgehen.

Vereinbaren Sie gezielte Störungen mit dem Anbieter. Die Quelle ist nicht erreichbar, die Freigabe bleibt offen oder das ERP liefert keine eindeutige Antwort. Den letzten Fall kann ein Testadapter nachbilden, der die Verbindung unterbricht. Prüfen Sie danach zuerst im ERP, was tatsächlich geschehen ist, bevor Sie erneut starten. Akzeptabel wäre eine eindeutig einmalig ausgeführte Aktion oder ein angehaltener Vorgang, für den jemand zuständig ist. Einfach noch einmal aufzurufen, ohne den Zustand zu kennen, löst diese Frage nicht.

UiPath beschreibt Abläufe, die auf Dokumente oder Freigaben warten und danach weiterlaufen. Unsichere Entscheidungen gehen mit den zugehörigen Informationen an einen Menschen. Auch Nexus beschreibt die Übergabe unsicherer Fälle samt Kontext.^4,5,6

Greifen Sie diese Aussagen in der Vorführung mit Ihren Fällen auf. Lassen Sie den Bearbeiter wechseln, eine Freigabe ablehnen und einen offenen Vorgang erneut aufrufen. Die übernehmende Person muss sehen, was bereits passiert ist, welche Quelle fehlt und was sie als Nächstes entscheiden darf. Eine Meldung allein hilft wenig, wenn sie den Fall erst aus mehreren Systemen zusammensuchen muss. Prüfen Sie, ob sie anhand der übergebenen Angaben sicher weiterarbeiten kann.

Eine Zeile im Abnahmeprotokoll könnte so aussehen: „Fall: doppelte Ersatzteilanfrage. Erwartet: vorhandenen Vorgang erkennen, keinen zweiten Entwurf zur Ausführung freigeben. Beobachtet: tatsächlicher Stand im Zielsystem mit Verweis auf das Protokoll. Ergebnis: bestanden oder Nacharbeit. Zuständig: benannte Person.“ Ergänzen Sie die geprüfte Version, die verwendeten Datenstände und offene Punkte. Halten Sie fachliche Fehler, falsche Rechte und Bedienprobleme getrennt fest. Das hilft, die passende Korrektur zu beauftragen.

Nexus nennt die Freigabe von Datenfluss, Zugriffsrechten und Protokollierung durch die IT-Leitung als Bedingung für den Start. Copilot Studio beschreibt Freigabeschritte zwischen Entwicklung, Test und laufendem Betrieb.^7,8

Dazu kommt Ihre fachliche Entscheidung anhand der vorher festgelegten Ergebnisse. Sind Rechte ungeklärt oder doppelte Aktionen möglich, bleibt die betroffene Funktion gesperrt. Sie können einen engeren Umfang freigeben, etwa erfolgreich geprüfte Entwürfe ohne Versand. Die Verantwortlichen müssen genau diesen Umfang abzeichnen; ein allgemeines „abgenommen“ wäre missverständlich. Nach einer Korrektur wiederholen Sie den fehlgeschlagenen Fall und die benachbarten Fälle, auf die dieselbe Änderung wirken kann.