> ## Documentation Index
> Fetch the complete documentation index at: https://docs.m9tz.de/llms.txt
> Use this file to discover all available pages before exploring further.

# Agenten-Workflows: Wie ein Agent eine SOP ausführt

> Verstehen Sie, was ein Agenten-Workflow ist, wie wir ihn vor dem Build dokumentieren und freigeben lassen und was eine Aktualisierung nach dem Go-live erfordert.

Ein Workflow ist die vollständige, dokumentierte Abfolge von Schritten, die Ihr Agent vom Eingang einer Eingabe bis zum Abschluss des Prozesses durchläuft. Betrachten Sie ihn als eine schriftliche SOP – eine Anweisung, die der Agent genau in der von Ihnen genehmigten Reihenfolge ausführt, ohne Schritte zu überspringen oder zu improvisieren. Jeder von uns entwickelte Agent wird durch einen oder mehrere dokumentierte Workflows unterstützt, die Sie vor Beginn der Build-Arbeit prüfen und freigeben.

Ein Workflow ist keine Schlusskette oder ein offener Entscheidungsprozess. Er ist ein definiertes Verfahren mit einem festen Startpunkt, einer geordneten Schrittfolge, expliziten Verzweigungsbedingungen und dokumentierten Eskalationspunkten. Tritt eine Situation auf, die der Workflow nicht abdeckt, rät der Agent nicht – er eskaliert. Unter [Scope & Grenzen](/de/consulting/scoping) erfahren Sie, wie wir den richtigen Verantwortungsbereich definieren, bevor ein Workflow dokumentiert wird.

## Struktur eines Workflows

Jeder Workflow besteht aus denselben strukturellen Elementen. Wenn Sie diese kennen, können Sie einen Entwurf-Workflow prüfen und etwaige Abweichungen von Ihren tatsächlichen Geschäftsprozessen identifizieren.

<Steps>
  <Step title="Auslöserereignis">
    Die Bedingung, die den Workflow startet. Sie entspricht direkt einer der konfigurierten Eingabequellen des Agenten – ein neues Element in einem gemeinsamen Posteingang, eine Datei in einem überwachten Ordner, eine Formularübermittlung, ein zeitgesteuerter Auslöser oder ein Ereignis aus einem verbundenen System.

    Ein Workflow hat genau einen Auslöser. Wenn dasselbe Verfahren aus mehreren Eingabetypen heraus gestartet werden soll, wird jede Eingabe als separater Auslöser konfiguriert, der auf denselben Workflow zeigt.
  </Step>

  <Step title="SOP-Schritte">
    Die geordnete Abfolge von Aktionen, die der Agent nach dem Auslöser durchführt. Jeder Schritt ist explizit dokumentiert: was der Agent tut, welches System er liest oder beschreibt und was er dabei erzeugt. Schritte können sequenziell oder bedingt sein oder einen Abfragevorgang vor der weiteren Ausführung beinhalten.

    Kein Schritt ist implizit. Wenn der Agent einen Datensatz lesen muss, bevor er handelt, ist dieser Lesevorgang ein eigenständig dokumentierter Schritt. Wenn er auf eine Antwort warten muss, sind die Wartebedingung und der Timeout im jeweiligen Schritt festgehalten.
  </Step>

  <Step title="Verzweigungsbedingungen">
    Punkte im Workflow, an denen der Agent eine Bedingung auswertet und einen von zwei oder mehr definierten Pfaden einschlägt. Die Bedingung, die Optionen und die jeweils ausgeführte Aktion werden vor Beginn des Builds vollständig spezifiziert.

    Bedingungen basieren auf Daten, die der Agent abgerufen oder empfangen hat – nicht auf einer offenen Einschätzung. Beispiel: „Wenn der eingereichte Wert oberhalb des definierten Schwellenwerts liegt, folge Pfad A; wenn er darunter oder gleich ist, folge Pfad B."
  </Step>

  <Step title="Eskalationspunkte">
    Schritte, an denen der Agent angehalten ist, den Vorgang an einen Menschen zu übergeben. Eskalationspunkte werden durch die in den [Eskalationsregeln](/de/agent-structure/components) des Agenten definierten Bedingungen ausgelöst – Kompetenzschwellenwerte, Beschwerdeauslöser, nicht erkannte Eingabetypen oder obligatorische Freigabeanforderungen.

    Wenn eine Eskalation ausgelöst wird, bündelt der Agent den aktuellen Stand des Vorgangs – was er empfangen hat, welche Schritte er abgeschlossen hat und welche Bedingung die Eskalation ausgelöst hat – und leitet ihn mit diesem Kontext an die zuständige Person oder Warteschlange weiter.
  </Step>

  <Step title="Abschlussschritt">
    Der letzte Schritt, der den Workflow als abgeschlossen kennzeichnet. Dies kann eine Systemschreiboperation sein (Aktualisierung eines Statusfeldes, Schließen eines Datensatzes), eine ausgehende Nachricht (Versand einer Bestätigung, Ablage eines Berichts) oder eine Dateiausgabe (Ablage eines fertiggestellten Dokuments in einem festgelegten Ordner). Jeder Workflow hat für jeden möglichen Durchlaufpfad genau einen definierten Abschlusszustand.
  </Step>
</Steps>

## Workflow-Muster

Die meisten realen Workflows kombinieren mehr als eines dieser grundlegenden Muster. Wenn Sie das jeweilige Muster kennen, können Sie in der Designphase präziser kommunizieren, was Sie benötigen.

<CardGroup cols={2}>
  <Card title="Linear" icon="arrow-right">
    **Schritt 1 → Schritt 2 → Schritt 3**

    Schritte werden in fester Reihenfolge ausgeführt. Geeignet, wenn der Prozess jedes Mal identisch ist und keine Entscheidungen erforderlich sind.

    *Beispiel: Eingabe empfangen → Pflichtfelder prüfen → Datensatz erstellen → Bestätigung senden → Ende*
  </Card>

  <Card title="Bedingt" icon="code-branch">
    **Wenn Bedingung X → Pfad A; andernfalls → Pfad B**

    Der Agent wertet eine definierte Bedingung aus und ergreift je nach Ergebnis unterschiedliche Maßnahmen. Geeignet, wenn unterschiedliche Eingaben unterschiedliche Ausgaben erzeugen sollen.

    *Beispiel: Wenn der Vorgang die Genehmigungskriterien erfüllt → als genehmigt protokollieren und Antragsteller informieren; wenn nicht → an den Vorgesetzten von Abteilung A eskalieren*
  </Card>

  <Card title="Schleife" icon="rotate">
    **Wiederholen bis Bedingung erfüllt oder Limit erreicht**

    Der Agent wiederholt einen Schritt in einem festgelegten Intervall, bis eine Bedingung erfüllt ist oder eine maximale Anzahl von Versuchen erreicht wurde. Geeignet für die Abfrage eines externen Systems oder das Warten auf eine Antwort.

    *Beispiel: Alle vier Stunden prüfen, ob eine Lieferbestätigung eingegangen ist – nach drei erfolglosen Prüfungen eskalieren*
  </Card>

  <Card title="Parallel" icon="table-columns">
    **Schritt A und Schritt B gleichzeitig ausführen**

    Zwei oder mehr Schritte werden gleichzeitig ausgeführt; der Workflow wird fortgesetzt, sobald beide abgeschlossen sind. Geeignet, um die Gesamtdauer zu reduzieren, wenn Schritte voneinander unabhängig sind.

    *Beispiel: Den neuen Datensatz gleichzeitig in das Auftragsverwaltungssystem schreiben und die Eingangsbestätigung per E-Mail versenden*
  </Card>
</CardGroup>

## Dokumentation von Workflows

In der Designphase wird jeder Workflow in zwei Formaten dokumentiert, damit sowohl technische als auch nicht-technische Stakeholder ihn klar prüfen und freigeben können.

<Tabs>
  <Tab title="Beschreibung in Klartext">
    Eine Klartextbeschreibung führt durch jeden Schritt in einfacher Prosa – ohne Fachbegriffe, ohne Code. Sie beschreibt, was der Agent tut, welches System er bei jedem Schritt liest oder beschreibt, welche Bedingungen er auswertet und was an jedem Eskalationspunkt geschieht.

    Dies ist das primäre Format, das Sie bei Design-Reviews verwenden werden. Sie müssen kein Diagramm lesen, um einen Workflow freizugeben – die schriftliche Beschreibung enthält alles Wesentliche.

    **Beispiel (Workflow für eingehende Anfragen in Abteilung A):**

    > Wenn eine neue Nachricht im gemeinsamen Posteingang von Abteilung A eingeht, liest der Agent die Nachricht und prüft, ob Betreff und Inhalt einem erkannten Anfragekategorie entsprechen. Passt die Nachricht zu einer bekannten Kategorie, schlägt der Agent den zugehörigen Datensatz im Auftragsverwaltungssystem nach, erstellt eine standardisierte Eingangsbestätigung auf Basis des aktuellen Datensatzstatus und sendet die Antwort. Anschließend protokolliert er die Interaktion gegen den Datensatz und markiert den Schritt als abgeschlossen. Entspricht die Nachricht keiner bekannten Anfragekategorie, hält der Agent sie in der Prüfungswarteschlange zurück und sendet eine Benachrichtigung an den Teamleiter von Abteilung A – einschließlich der ursprünglichen Nachricht und eines Hinweises darauf, dass keine Klassifizierung möglich war.
  </Tab>

  <Tab title="Flussdiagramm">
    Jeder Klartextbeschreibung beigefügt ist ein visuelles Flussdiagramm. Es verwendet ein einfaches, standardisiertes Format – Rechtecke für Prozessschritte, Rauten für Verzweigungsbedingungen, doppelt umrandete Rechtecke für Eskalationspunkte –, damit Sie jeden möglichen Pfad durch den Workflow auf einen Blick nachverfolgen können.

    Flussdiagramme sind besonders nützlich für:

    * Die Erkennung von Randfällen, die in der schriftlichen Beschreibung möglicherweise nicht sofort auffallen
    * Die vergleichende Prüfung von Verzweigungsbedingungen nebeneinander
    * Die Kommunikation des Workflows an Teammitglieder, die nicht an der Designsitzung teilgenommen haben

    <Note>
      Workflow-Diagramme werden als gemeinsam nutzbare Dokumente bereitgestellt, die Ihr gesamtes Team einsehen und kommentieren kann, ohne ein spezifisches Tool zu benötigen.
    </Note>
  </Tab>
</Tabs>

## Prüfung und Freigabe

Sie geben jeden Workflow formell frei, bevor der Build beginnt. Nachfolgend erläutern wir, wie dieser Prozess abläuft.

<Steps>
  <Step title="Entwurf wird bereitgestellt">
    Nach Ihrem Discovery-Workshop stellen wir ein Workflow-Entwurfsdokument bereit, das alle geplanten Agentenverhaltensweisen abdeckt – Klartextbeschreibungen und Diagramme für jeden Workflow im Projektumfang.
  </Step>

  <Step title="Asynchrone Prüfungsphase">
    Sie haben fünf Werktage, um den Entwurf mit Ihrem Team zu prüfen. Sie können Kommentare direkt im gemeinsamen Dokument hinterlassen oder Fragen über Ihren bevorzugten Kanal stellen.
  </Step>

  <Step title="Design-Review-Gespräch">
    Wir gehen die Workflows gemeinsam in einem 45-minütigen Gespräch durch. Dies ist der richtige Zeitpunkt, um Randfälle zu identifizieren, Verzweigungsbedingungen anzupassen, Eskalationsregeln zu ergänzen, die im Discovery nicht berücksichtigt wurden, oder Schritte zu korrigieren, die den tatsächlichen Prozessablauf nicht korrekt abbilden.
  </Step>

  <Step title="Formelle Freigabe">
    Sobald Sie zufrieden sind, bestätigen Sie die Freigabe schriftlich. Diese Freigabe fixiert den Projektumfang für die Build-Phase und startet die vereinbarte Lieferfrist.
  </Step>
</Steps>

<Warning>
  Änderungsanforderungen nach der Freigabe können sich auf Ihren Lieferzeitplan auswirken. Geringfügige Anpassungen werden in der Regel ohne Aufpreis berücksichtigt, strukturelle Änderungen jedoch – das Hinzufügen einer neuen Verzweigung, das Ändern des Auslösertyps, das Hinzufügen einer neuen Eskalationsbedingung oder die Anbindung eines neuen Systems – werden als gesonderte Änderungsanforderungen behandelt und eigenständig kalkuliert.
</Warning>

## Workflows nach dem Go-live aktualisieren

Ihre Prozesse werden sich weiterentwickeln, und die Workflows Ihres Agenten sollten entsprechend angepasst werden. Nicht jede Aktualisierung ist gleichartig – manche sind in wenigen Minuten erledigt, andere erfordern einen strukturierten Neuaufbau.

<Accordion title="Einfache Konfigurationsänderungen (schnell – in der Regel noch am selben Tag)">
  Diese Änderungen aktualisieren Werte oder Einstellungen innerhalb einer bestehenden Workflow-Struktur, ohne die Logik zu verändern.

  * Aktualisierung des Textes in einer Standardbestätigung oder Benachrichtigung
  * Anpassung eines Schwellenwerts in einer Verzweigungsbedingung (z. B. Erhöhung eines Genehmigungslimits)
  * Hinzufügen oder Entfernen eines Teammitglieds als Eskalationsziel
  * Änderung des Zeitplans eines zeitgesteuerten Auslösers
  * Aktualisierung des Ordnerpfads oder der Posteingangsadresse einer Eingabequelle
</Accordion>

<Accordion title="Änderungen an der Workflow-Logik (mittel – in der Regel 1–3 Tage)">
  Diese Änderungen verändern das Verhalten des Workflows – durch das Hinzufügen einer neuen Bedingung, das Einfügen eines Schritts oder die Neuordnung von Aktionen.

  * Hinzufügen einer neuen Verzweigungsbedingung (z. B. unterschiedliche Behandlung eines neuen Anfragekategorie)
  * Einfügen eines neuen Schritts in einen bestehenden Ablauf (z. B. Hinzufügen eines Nachschlagevorgang vor einem Schritt, der zuvor ohne diesen Vorgang ausgeführt wurde)
  * Hinzufügen einer neuen Eskalationsregel oder Änderung der Bedingungen einer bestehenden
  * Hinzufügen einer Schleifen- oder Wiederholungslogik, die bisher nicht vorhanden war
</Accordion>

<Accordion title="Strukturelle Neubauten (größer – werden gesondert kalkuliert)">
  Diese Änderungen sind so grundlegend, dass wir sie als Miniprojekt behandeln – mit einem neuen Scoping-Gespräch, aktualisierter Dokumentation und einem erneuten Freigabeprozess.

  * Hinzufügen eines vollständig neuen Auslösertyps oder einer neuen Eingabequelle
  * Anbindung eines neuen Systems, das Autorisierung und Tests erfordert
  * Zusammenführung zweier separater Workflows zu einem kombinierten Prozess
  * Neuarchitektur des Workflows zur Abdeckung eines neuen Geschäftsprozesses außerhalb der bestehenden Rollendefinition
</Accordion>

## Beispiel-Workflow: Eingehende Triage Abteilung A

Nachfolgend ein vollständiges Beispiel des Detailgrads, den wir für jeden Agenten dokumentieren. Dieses Muster ist typisch für abteilungsbezogene Agenten, die einen gemeinsamen Posteingang oder eine Eingangs-Warteschlange bearbeiten.

```
WORKFLOW:   Eingehende Triage Abteilung A
AUSLÖSER:   Neue Nachricht im gemeinsamen Posteingang von Abteilung A

SCHRITT 1 — Eingehende Nachricht lesen und klassifizieren
  - Extrahieren: Absender, Betreff, Nachrichtentext
  - Abgleich mit definierter Anfragekategorie-Liste
  → WENN klassifiziert: weiter zu Schritt 2
  → WENN nicht klassifiziert: weiter zu Schritt 5 (Eskalationspfad)

SCHRITT 2 — Bestehenden Datensatz nachschlagen [ABFRAGE]
  - Auftragsverwaltungssystem anhand der Absender-E-Mail-Adresse abfragen
  → WENN Datensatz gefunden: aktuellen Status und letztes Aktivitätsdatum abrufen
  → WENN kein Datensatz gefunden: neuen Entwurfsdatensatz anlegen (Status: ausstehend)

SCHRITT 3 — Bestätigung erstellen und versenden [PARALLEL]
  3a. Eingangsbestätigung anhand der Standardvorlage für die erkannte Anfragekategorie erstellen
       - Personalisierung mit: Name des Absenders, Anfragekategorie, aktueller Datensatzstatus
       - Antwort über gemeinsamen Posteingang von Abteilung A senden
  3b. Interaktion gegen den Datensatz protokollieren
       - Schreiben: Zeitstempel, Anfragekategorie, durchgeführte Aktion

SCHRITT 4 — Schritt als abgeschlossen markieren
  - Datensatzstatus auf „bestätigt" aktualisieren
  - ENDE (Standardpfad)

SCHRITT 5 — Eskalationspfad [NICHT ERKANNTE EINGABE]
  - Nachricht in Prüfungswarteschlange zurückhalten (keine Antwort senden)
  - Benachrichtigung an Teamleiter von Abteilung A senden
       - Inhalt: ursprüngliche Nachricht, Absender, Eskalationsgrund („Anfragekategorie nicht erkannt")
  - ENDE (Eskalationspfad)
```

<Tip>
  Dieser Workflow verwendet eine Verzweigungsbedingung in Schritt 1, einen Abfragevorgang in Schritt 2 und eine Parallelausführung in Schritt 3. Der Eskalationspfad in Schritt 5 ist ein Beispiel für eine Nicht-erkannte-Eingabe-Eskalationsregel in der Praxis – der Agent hält den Vorgang zurück, anstatt auf Basis unvollständiger Informationen zu handeln.
</Tip>

## Nächste Schritte

<CardGroup cols={2}>
  <Card title="Komponenten" icon="puzzle-piece" href="/de/agent-structure/components">
    Verstehen Sie die einzelnen Bausteine – Eingabequellen, SOP-Logik, Eskalationsregeln und ausgehende Schnittstellen – von denen jeder Workflow-Schritt abhängt.
  </Card>

  <Card title="Integrationen" icon="plug" href="/de/agent-structure/integrations">
    Erfahren Sie, wie Workflow-Schritte mit den Auftragsverwaltungssystemen, gemeinsamen Posteingängen und anderen Plattformen verbunden werden, auf denen Ihr Unternehmen bereits betrieben wird.
  </Card>
</CardGroup>
