Agent oder Workflow? Trennung von Reasoning und Ausführung in UnternehmenskI

Agierende KI ist der Schlagwort des Moments. Geben Sie einer großen Sprachmodell eine Reihe von Werkzeugen, fügen Sie Speicher hinzu, verbinden Sie es mit Unternehmenssystemen und lassen Sie es entscheiden, was als Nächstes getan werden soll – das Ergebnis wird dann als KI-Agent bezeichnet. Es gibt jedoch einen Haken: Unternehmenssysteme können nicht ausschließlich auf probabilistischen Entscheidungen basieren. Wenn eine KI auf Lieferantendaten, Finanzprozessen, ERP-Daten, Genehmigungen oder anderen kritischen Abläufen zugreift, können manche Entscheidungen flexibel bleiben, während andere es nicht können.

Ein Projekt zur Lieferantenverwaltung, das auf RAG, LangGraph, MCP, menschlicher Genehmigung sowie Amazon Bedrock basiert, führte zu einer zentralen Leitidee: Der Agent sollte entscheiden, was getan werden muss, und die Anwendung sollte kontrollieren, wie dies geschieht. Alles Weitere in der Konzeption folgt aus dieser Trennung.

Warum der Agent nicht alles erledigen sollte

Stellen Sie sich einen Antrag auf Onboarding eines Lieferanten vor: Diesen Lieferanten erstellen, seine Angaben überprüfen, die Beschaffungspolitik prüfen und den Antrag an SAP senden. Ein vollständig autonomer Agent könnte theoretisch den Antrag interpretieren, interne Dokumente durchsuchen, die Daten überprüfen, entscheiden, ob eine Genehmigung erforderlich ist, sich mit SAP verbinden, die Datensätze erstellen und bei Fehlern erneut versuchen.

Das ist technisch möglich, architektonisch jedoch problematisch. Ein LLM arbeitet probabilistisch – derselbe Eingabedatensatz kann leicht unterschiedliche Denkwege einschlagen, und Modelle, Anfragen sowie Kontexte verändern sich ständig. Diese Flexibilität ist hervorragend, um zu verstehen, was eine Person meint, eignet sich aber schlecht für die Ausführung kritischer Geschäftstransaktionen. Ein Modell sollte nicht entscheiden, ob eine Datenbanktransaktion bestätigt wird, eigene Strategien zum erneuten Versuch entwickeln, beurteilen, ob eine Autorisierung übersprungen werden kann, oder SAP-Zugangsdaten besitzen. Dadurch werden Denkprozesse und Ausführung voneinander getrennt.

Abläufe versus Agenten

Die beiden Begriffe werden oft vertauscht, doch der Unterschied ist wichtig. Ein KI-Ablauf folgt in der Regel einem im Voraus definierten Pfad:

Request
   ↓
Validate
   ↓
Retrieve Policies
   ↓
Evaluate
   ↓
Approval
   ↓
Create Supplier
   ↓
Publish Integration Event

Die Anwendung kennt jeden Zustand und jede Übergangsmöglichkeit. Ein KI-Agent hat mehr Freiheit, zu entscheiden, was als Nächstes geschieht:

User Request
      ↓
     LLM
      ↓
Reason about intent
      ↓
Choose next capability
   ↙    ↓     ↘
Search Validate Request Approval

Diese Freiheit hat Wert, wird jedoch riskant, wenn der Agent auf die transaktionale Infrastruktur zugreift. Das bevorzugte Design kombiniert beide Modelle.

Aggressives Reasoning oben, deterministische Ausführung unten

Auf höherer Ebene sieht die Architektur so aus:

USER
                      │
                      ▼
                 FastAPI API
                      │
                      ▼
                 LangGraph
                Agent Workflow
                      │
          ┌───────────┼───────────┐
          ▼           ▼           ▼
        RAG        Reasoning     Tools
          │
          ▼
   Amazon OpenSearch
          │
          ▼
     AWS Bedrock
                      │
                      ▼
                MCP Boundary
                      │
                      ▼
               Application API
                      │
                      ▼
              Domain / Use Cases
                      │
              ┌───────┴───────┐
              ▼               ▼
          PostgreSQL         AWS SQS
                                │
                                ▼
                               SAP

Eine Grenze fällt besonders auf: Das LLM befindet sich über der Anwendungs Schicht. Es kann Anfragen interpretieren, logisch denken, Wissen abrufen, Handlungen empfehlen und nach Werkzeugen fragen. Es besitzt jedoch nicht die Kontrolle über die Transaktion.

Wo Agenten ihren Platz finden

Probabilistisches Denken ist an einigen spezifischen Stellen von Vorteil.

Verständnis der Absicht

Menschen schreiben keine perfekt strukturierten API-Aufrufe. Ein Benutzer könnte sagen, er müsse ACME für eine brasilianische Geschäftstätigkeit einbinden und möchte wissen, ob alles den Vorschriften entspricht. Dieser Satz enthält Absichten, Kontexte und Unklarheiten – ein LLM ist sehr gut darin, daraus etwas zu erstellen, das die Anwendung verarbeiten kann:

{
  "intent": "supplier_onboarding",
  "supplier": "ACME",
  "country": "BR",
  "requires_policy_validation": true
}

Danach übernimmt die deterministische Software.

Unternehmenswissen mit RAG abrufen

Die Einführung hängt von internen Richtlinien ab: erforderliche Dokumente, Steuervorschriften, landesspezifische Anforderungen, Beschaffungsbeschränkungen sowie Genehmigungsschwelle. Anstatt diese Dokumente in Prompts einzufügen oder jede Regel festzuschreiben, kann das System sie abrufen:

Question
   ↓
Embedding
   ↓
Amazon OpenSearch
   ↓
Relevant Policy Chunks
   ↓
LLM Context
   ↓
Reasoning

Hier gilt eine weitere Grenze. Die Abfrage liefert Kontext und darf keine geschäftlichen Entscheidungen treffen. Es ist hilfreich, eine Richtlinie zu finden, die besagt, dass Lieferanten über einem bestimmten Schwellenwert eine Genehmigung benötigen. Die Durchsetzung dieser Genehmigung muss weiterhin durch gewöhnliche Anwendungslogik erfolgen.

Wo Workflows besser funktionieren

Sobald die Anfrage verstanden wurde, nehmen wir an, dass ein Lieferant erstellt werden muss. Der Prozess kann Schritte wie diese umfassen:

Validate Supplier
      ↓
Check Duplicate
      ↓
Check Authorization
      ↓
Persist Supplier
      ↓
Publish Integration Event
      ↓
Wait for SAP Result

Ein LLM sollte das nicht improvisieren. Der Workflow muss die Ausführungsgarantien festlegen: Validierung, Autorisierung, Idempotenz, Verhinderung von Duplikaten, Wiederholungsversuche, Audit-Logs, Transaktionsgrenzen und Fehlerbehandlung. Das sind Themen der Softwareentwicklung, und Prompt-Engineering hat dazu nichts zu sagen.

Warum LangGraph

Zur Orchestrierung wurde LangGraph gewählt, weil es explizite Zustandsübergänge bietet, anstelle eines offenen Schleifens, in dem ein Agent ständig entscheiden muss, welches Tool als Nächstes aufgerufen werden soll. Konzeptionell sieht das Graphen so aus:

START
  │
  ▼
Understand Intent
  │
  ▼
Retrieve Policies
  │
  ▼
Evaluate Request
  │
  ├───────────────┐
  │               │
  ▼               ▼
Approval Needed?  No Approval
  │               │
  ▼               │
Human Approval    │
  │               │
  └───────┬───────┘
          ▼
     Request Action
          │
          ▼
         END

In den ausgewählten Knoten behält das Modell seine Freiheit zur Abwägung, während der Graph begrenzt, wie weit seine Schlussfolgerungen das System beeinflussen können. Das Ergebnis ist begrenzte Autonomie: Freiheit innerhalb klar definierter architektonischer Grenzen.

Human-in-the-loop hat mehr als eine Bedeutung

In der Diskussion um UnternehmenskI wird oft nur gesagt: „Fügen Sie einfach einen Menschen in den Prozess ein.“ Doch Menschen können aus verschiedenen Gründen eingreifen, und es lohnt sich, mindestens zwei Arten der Freigabe voneinander zu unterscheiden.

Betriebsinterne Freigabe

Selbst der Geschäftsprozess erfordert eine Freigabe – unabhängig davon, ob KI beteiligt ist oder nicht:

Supplier
   ↓
Compliance Check
   ↓
Manager Approval
   ↓
Creation

Zustimmung für KI-Tool

Eine zweite Zustimmung ist erforderlich, weil der Agent eine sensible Aktion ausführen möchte:

Agent
  ↓
"Create supplier"
  ↓
Tool requires confirmation
  ↓
Human approves
  ↓
Application executes

Diese beiden Aspekte unterscheiden sich. Einer gehört zum Bereich der Architektur und der andere zur Steuerung künstlicher Intelligenz. Ihr Vermischen führt zu architektonischer Verwirrung.

Warum MCP wichtig ist

Ein Agent, der mit Unternehmenssystemen arbeitet, benötigt Werkzeuge, doch die direkte Bereitstellung der Infrastruktur an das LLM bringt unnötige Risiken mit sich. Der bessere Weg führt über ein MCP-Werkzeug:

Agent
  ↓
MCP Tool
  ↓
Application API
  ↓
Use Case
  ↓
Domain
  ↓
Infrastructure

und vermeidet es, den Agenten mit einer Datenbank zu verbinden:

Agent
  ↓
PostgreSQL

oder direkt an SAP:

Agent
  ↓
SAP

Mit der ersten Form kontrolliert die Anwendung weiterhin Authentifizierung, Autorisierung, Validierung, Geschäftsregeln, Auditing, Transaktionen und Idempotenz. MCP wird zur Grenze zwischen dem künstlichen Intelligenz-Verfahren und den Unternehmensfähigkeiten. Der Agent drückt Absichten aus, während die Anwendung für die Ausführung verantwortlich ist.

SAP sollte nicht von der ständigen Verfügbarkeit des LLM abhängen

Außensysteme versagen. SAP kann ausfallen, das Netzwerk kann unterbrechen, ein nachgelagerter Dienst kann eine Zeitüberschreitung melden, und auch der LLM-Anbieter kann offline gehen. Die synchronische Ausführung aller Abläufe innerhalb eines Agentenzyklus erschwert die Widerstandsfähigkeit. Deshalb wird asynchrone Kommunikation mit AWS SQS verwendet. Anstelle dessen:

Agent
  ↓
SAP
  ↓
Wait...
  ↓
Timeout

der Fluss wird wie folgt:

Agent
  ↓
Application
  ↓
Persist State
  ↓
AWS SQS
  ↓
Integration Worker
  ↓
SAP

Die Geschäftsabwicklung muss nicht mehr darauf warten, dass SAP sofort antwortet. Ein Mitarbeiter kümmert sich um Wiederholungsversuche, Zeitverzögerungen, Dead-Letter-Queues, Überwachbarkeit sowie idempotenten Prozessablauf – und diese Garantien stammen von deterministischem Software-Design und nicht von einem Modell.

Eine hybride Architektur

Sobald diese Grenzen festgelegt sind, passt es nicht mehr, das System einfach als einen KI-Agenten zu bezeichnen. Es handelt sich um eine hybride Lösung:

┌─────────────────────────────┐
│     PROBABILISTIC LAYER     │
│                             │
│ LLM                         │
│ RAG                         │
│ Intent Understanding        │
│ Reasoning                   │
│ Tool Selection              │
└──────────────┬──────────────┘
               │
        Controlled Boundary
               │
┌──────────────▼──────────────┐
│     DETERMINISTIC LAYER     │
│                             │
│ Application Use Cases       │
│ Domain Rules                │
│ Authorization               │
│ Validation                  │
│ Transactions                │
│ Idempotency                 │
│ Messaging                   │
│ Integrations                │
└─────────────────────────────┘

Diese Unterscheidung ist für unternehmensweite agierende KI unerlässlich.

Die Softwarearchitektur ist weiterhin wichtig

Ein häufiger Fehler bei generativer KI besteht darin, anzunehmen, dass traditionelle Architekturen keine Bedeutung mehr hätten. Im Gegenteil: Sie sind noch wichtiger. Ein System, das dynamisch denken und Aktionen auswählen kann, benötigt strengere Grenzen dafür, was diese Aktionen tun dürfen. DDD, CQRS, hexagonale Architektur, Authentifizierung, Autorisierung, Messaging, Überwachbarkeit, Widerstandsfähigkeit und Idempotenz gelten weiterhin. KI beseitigt keine dieser Aspekte – sie fügt lediglich einen weiteren probabilistischen Bestandteil hinzu, der sicher neben ihnen laufen muss.

Agent oder Workflow?

Die Antwort lautet beides. Verwenden Sie Agenten dort, wo Unsicherheit und logisches Denken Wert schaffen, und deterministische Workflows dort, wo Vorhersehbarkeit und Garantien entscheidend sind. Ein praktisches mentales Modell:

AI AGENT
                 │
                 │ decides WHAT
                 ▼
        ┌─────────────────┐
        │ Controlled Tool │
        │    Boundary     │
        └────────┬────────┘
                 │
                 │ requests
                 ▼
          APPLICATION
                 │
                 │ decides HOW
                 ▼
             DOMAIN
                 │
                 ▼
        INFRASTRUCTURE

Das LLM sollte nicht zur Architektur werden. Es sollte daran teilnehmen.

Wo Autonomie sich auszahlt

Die wichtige Frage ist nicht, wie viel Autonomie einem Modell gegeben werden kann. Vielmehr geht es darum, wo Autonomie Wert schafft. Autonomie eignet sich zum Interpretieren einer vagen Anfrage, zum Durchsuchen großer Mengen an internen Dokumenten, zum Abwägen von Kontextfaktoren und zur Vorschlagstellung der nächsten Aktion. Sie eignet sich jedoch nicht dazu, Geschäftsregeln zu überschreiben, Transaktionen zu verwalten oder Zugangsdaten zu Produktionsdatenbanken zu nutzen.

Ziel ist kontrollierte Autonomie, was in Unternehmenssystemen bedeutet, probabilistisches KI-Reasoning mit deterministischer Ingenieurskunst zu kombinieren. Die nächste Frage ergibt sich logisch: Wenn ein Agent auf SAP oder eine Datenbank zugreifen muss, wie sollte diese Grenze eigentlich aussehen?