Skip to main content
Ein Agent im M9TZ Agent Blueprint ist kein Allzweck-Chatbot. Er ist ein Software-Dienst, der an eine einzelne Abteilung oder Geschäftsfunktion gebunden ist, vordefinierte Standard-Arbeitsanweisungen (SOPs) ausführt und an einen Menschen eskaliert, wann immer ein Fall außerhalb seines definierten Geltungsbereichs liegt. Jede Entscheidung des Agenten lässt sich auf einen Schritt in einer dokumentierten Verfahrensanweisung zurückführen — nicht auf offene Schlussfolgerungen.

​
Definition

Ein Agent ist:
  • Prozessgebunden — auf eine Abteilung oder Funktion begrenzt (beispielsweise die Buchhaltungsfunktion, die Auftragsverarbeitungsfunktion oder einen compliance-relevanten Eingangsworkflow). Er handelt nicht über Grenzen hinaus, die ihm nicht zugewiesen wurden.
  • SOP-gesteuert — er folgt einem dokumentierten, versionskontrollierten Satz von Arbeitsanweisungen. Die Verfahren legen die genauen Schritte fest, die Entscheidungskriterien an jedem Verzweigungspunkt, die Handlungsgrenzen des Agenten und die Bedingungen, unter denen er stoppen und an einen Menschen übergeben muss.
  • Eskalation als Standard bei Unsicherheit — wenn eine Eingabe keinem in den SOPs behandelten Fall entspricht, improvisiert der Agent nicht. Er bündelt die verfügbaren Informationen, macht den Fall für die zuständige Person oder Eskalations-Warteschlange sichtbar und handelt erst wieder, wenn eine Entscheidung getroffen wurde.

​
Warum dieses Design für prozesskritische Workflows wichtig ist

Allgemeine KI-Systeme sind auf Breite und Kreativität optimiert. Das ist für offene Aufgaben nützlich. Bei Workflows, in denen die Organisation konsistente, nachvollziehbare Ergebnisse erfordert — Buchhaltungsabgleich, Auftrags-Ausnahmebehandlung, compliance-gepflegte Genehmigungen und ähnliche Funktionen — ist es ein Risikofaktor. Das Modell „Agent als SOP-Ausführer” bietet einen anderen Satz von Garantien:
  • Vorhersagbarkeit — bei identischer Eingabe folgt der Agent stets demselben Verfahren. Es wird keine Varianz durch probabilistische Improvisation eingeführt.
  • Nachvollziehbarkeit — da jede Handlung auf einen konkreten SOP-Schritt zurückführbar ist, können Sie exakt rekonstruieren, was der Agent getan hat und warum.
  • Kontrollierte Handlungsbefugnis — die Handlungsgrenzen des Agenten sind in seiner Rollendefinition deklariert, nicht zur Laufzeit abgeleitet. Der Agent weiß, was er tun darf, was er eskalieren muss und was er unter keinen Umständen tun darf.
  • Sicheres Versagen — wenn ein Fall außerhalb des Geltungsbereichs liegt, ist das Ergebnis eine Eskalation, keine bestmögliche Schätzung. Unsicherheit wird sichtbar gemacht, statt sich fortzupflanzen.
Bei Workflows, bei denen eine falsche Handlung regulatorische, finanzielle oder geschäftsbeziehungsbezogene Konsequenzen hat, ist Eskalation statt Improvisation der richtige Standard.

​
Woraus ein Agent besteht

Jeder Agent im Blueprint hat vier generische Bestandteile, unabhängig von der Abteilung, der er dient.

​
Rollendefinition

Die Rollendefinition legt die Identität des Agenten im System fest:
  • Zugewiesene Funktion — die Abteilung oder der Geschäftsprozess, für den der Agent verantwortlich ist (zum Beispiel „Rechnungsverarbeitung für die Buchhaltungsfunktion” oder „eingehende Auftragssortierung”).
  • Aufgabenliste — die spezifischen Aufgaben, zu deren Ausführung der Agent befugt ist, beschrieben in der Granularität, die für das Schreiben einer testbaren SOP erforderlich ist.
  • Handlungsgrenzen — die Handlungen, die der Agent autonom vornehmen darf, die Handlungen, die eine Mitgenehmigung erfordern, und die Handlungen, die grundsätzlich außerhalb seines Geltungsbereichs liegen.
  • Eskalationsregeln — die Bedingungen, unter denen der Agent einen Fall übergeben muss, das Format der Eskalationsnachricht und der Kanal oder die Warteschlange, an die er weiterleitet.

​
Eingaben, die der Agent überwacht

Ein Agent überwacht eine oder mehrere definierte Eingabequellen. Der Eingabetyp hängt von der Funktion ab:
  • Ein gemeinsamer Posteingang (E-Mail oder ein Nachrichtenkanal), der von einer Abteilung genutzt wird
  • Ein Dateiablageort oder eine Eingangswarteschlange in einem Back-Office- oder ERP-System
  • Ein strukturierter Ereignis-Feed aus einem vorgelagerten System (zum Beispiel ein neu erstellter Datensatz in Ihrem Auftragsverwaltungssystem)
  • Ein zeitgesteuerter Auslöser (der Agent wird in definierten Intervallen aktiv, um in der Warteschlange stehende Arbeit zu verarbeiten)
Der Satz der Eingaben ist in der Konfiguration des Agenten deklariert. Der Agent überwacht keine Quellen, die ihm nicht zugewiesen wurden.

​
Die ausgeführten SOPs

SOPs bilden den Kern des Agenten. Jede SOP ist ein nummeriertes, verzweigendes Verfahren, das Folgendes festlegt:
  1. Die Auslösebedingung — welcher Eingabezustand oder welches Ereignis dieses Verfahren startet
  2. Die Schritte in Reihenfolge — was der Agent in jeder Phase liest, extrahiert, berechnet oder nachschlägt
  3. Die Entscheidungsverzweigungen — welche Kriterien bestimmen, welchen Pfad der Agent einschlägt
  4. Die Ausgaben oder Handlungen an jedem Endschritt — was der Agent schreibt, sendet oder aktualisiert
  5. Die Eskalationsausgänge — an welchen Punkten der Agent stoppen und übergeben muss, und welche Informationen er in der Übergabe einschließen muss
SOPs werden vor dem Aufbau des Agenten verfasst und als Teil des Designprozesses überprüft. Ein Agent nimmt keine Handlungen vor, die in keiner SOP spezifiziert sind.

​
Ausgehende Nachrichten und Schnittstellen

Nach Ausführung eines Verfahrens kommuniziert der Agent Ergebnisse in eine von zwei Richtungen:
  • An andere Abteilungsagenten — strukturierte Nachrichten (in der Regel JSON-Nutzdaten), die an einen definierten Kanal oder eine Warteschlange gesendet werden und dem agentenübergreifenden Nachrichtenvertrag der Bereitstellung folgen. Ein nachgelagerter Agent einer anderen Funktion verarbeitet diese Nachrichten und handelt innerhalb seines eigenen Geltungsbereichs.
  • An Menschen — Eskalationshinweise, Genehmigungsanfragen, Statusupdates oder Ausnahmeberichte, die an den zuständigen Posteingang, die Warteschlange oder den Benachrichtigungskanal weitergeleitet werden.
Format und Routing jedes ausgehenden Nachrichtentyps sind in der Rollendefinition des Agenten deklariert.

​
Modellierung mehrerer Rollen innerhalb einer Abteilung

Eine häufige Designfrage ist, ob man einen Agenten pro Rolle innerhalb einer Abteilung erstellt oder mehrere Rollen in einer einzigen Agenten-Laufzeitumgebung zusammenfasst. Das allgemeine Prinzip des Blueprints: Mehrere Rollen innerhalb einer Abteilung können als mehrere SOPs modelliert werden, die von derselben Agenten-Laufzeitumgebung verarbeitet werden — und nicht als separate eingesetzte Instanzen. Die Begründung:
  • Rollen innerhalb derselben Abteilung teilen Kontext (sie greifen auf dieselben Daten und internen Werkzeuge zu und operieren unter derselben Handlungsbefugnis). Die Zusammenfassung in einer Laufzeitumgebung vermeidet die Duplizierung dieses Kontexts und reduziert den Aufwand für agentenübergreifende Koordination bei Arbeit, die von Natur aus abteilungsintern ist.
  • Die Trennung in eigenständige Agenten-Instanzen ist an Abteilungs- oder Funktionsgrenzen sinnvoll, wo sich Handlungsbefugnisse, Werkzeugzugang und Eskalationspfade wesentlich unterscheiden. Innerhalb einer einzelnen Funktion erreicht die SOP-Trennung in einer Laufzeitumgebung dieselbe logische Isolation zu geringeren Betriebskosten.
  • Die SOP-Struktur selbst erzwingt die Rollengrenze. Jede SOP hat ihren eigenen Auslöser, ihre eigenen Handlungsgrenzen und ihren eigenen Eskalationspfad. Die Aufteilung in eine separate Instanz erhöht nicht die Sicherheit — sie erhöht Latenz und Koordinationskomplexität.
Dieses Prinzip hält die Agentenzahl proportional zur Anzahl der eigenständigen Abteilungen oder Funktionen im Geltungsbereich — nicht zur Anzahl der Teilaufgaben innerhalb jeder einzelnen.

​
Beziehung zur übergeordneten Architektur

Agenten sind die Arbeitseinheit in einer gestuften, abteilungsbasierten Architektur. Jeder Agent:
  • Besitzt eine Domäne des gesamten Geschäftsprozesses
  • Kommuniziert mit anderen Agenten ausschließlich über definierte Nachrichtenstrukturen (nicht durch gemeinsamen internen Zustand oder direkte gegenseitige Aufrufe)
  • Hat einen klaren vorgelagerten Teil (was ihn auslöst) und einen klaren nachgelagerten Teil (was er produziert oder wen er benachrichtigt)
Das Ergebnis ist ein System, in dem die Automatisierung jeder Abteilung unabhängig verständlich, unabhängig testbar und unabhängig wartbar ist — während die Abteilungen durch die Nachrichtenebene dennoch als verbundenes Ganzes koordinieren.
Die Einführungsseite behandelt die übergeordnete gestufte Architektur und wie Abteilungsagenten zusammenpassen. Diese Seite behandelt, was ein einzelner Agent ist und wie er definiert wird. Die Komponenten, aus denen ein Agent auf Implementierungsebene besteht, finden Sie unter Agentenstruktur.