Was ist ein KI-Agent?
Ein KI-Agent ist ein System, das mit Hilfe eines LLMs Aktionen ausführt — nicht nur Antworten generiert. Klassischer Chatbot: Frage rein, Antwort raus. Agent: Frage rein, Plan, Werkzeug-Aufruf 1, Werkzeug-Aufruf 2, ggf. Klärfrage, Werkzeug-Aufruf 3, finales Ergebnis raus. Werkzeuge können sein: Datenbank-Lookups, API-Aufrufe, Datei-Operationen, E-Mail-Versand, andere LLM-Aufrufe.
Die Begriffsabgrenzung ist 2026 fließend. „RAG mit Tool-Calls“ überlappt mit „Agent“. Wir verwenden in unserer Praxis folgende Faustregel: Wenn das System für eine Anfrage mehrere deterministische und LLM-basierte Schritte koordiniert, ist es ein Agent. Wenn es nur „retrieve & generate“ macht, ist es RAG.
Wann passen Agenten — und wann nicht?
Faustregel: Agent dann, wenn Sprachverstehen + mehrere Werkzeuge + bedingte Logik zusammenkommen. Bei reiner Frage-Antwort: RAG. Bei deterministischer Regel-Logik: RPA oder klassisches Skript.
Architektur-Pattern: Orchestrierter Agent mit deterministischem Skelett
Wir bauen produktive Agenten fast immer nach dem gleichen Pattern: ein deterministisches Skelett mit fest definierten Schritten, das LLM-Aufrufe nur an den Stellen einsetzt, wo Sprachverstehen oder freie Generierung nötig ist. Dieses Pattern ist deutlich zuverlässiger als „freier Agent“, der selbst entscheidet, welche Werkzeuge er wann nutzt.
Beispiel: Angebots-Agent (vereinfacht)
- 1Schritt 1
Anfrage parsen (LLM)
E-Mail/PDF mit strukturierter Ausgabe parsen — JSON-Schema-Output erzwungen.
- →Strukturierte Positionsliste
- →Kunde identifiziert
- 2Schritt 2
Verfügbarkeit (deterministisch)
ERP-API-Aufrufe pro Position. Kein LLM. Wenn unklar: zurück zu Schritt 1 mit Klärfrage.
- →Verfügbarkeits-Liste
- 3Schritt 3
Konditionen (deterministisch)
Vertragsdaten, Mengenrabatte, Margenregeln. Pure Python/SQL-Logik.
- →Position-Preise
- 4Schritt 4
Anschreiben + PDF (LLM + Template)
LLM nur für Anschreiben-Text, Template für Positionsdetails. Rückversand mit Mensch-Approval.
- →Angebots-PDF zur Freigabe
Wichtig: das LLM trifft keine Preis- oder Konditions-Entscheidung selbst. Das wäre eine Halluzinations-Katastrophe wartend zu passieren. Preise und Konditionen kommen aus deterministischer Logik — das LLM darf nur Text formulieren.
Tools-Design
Tools (Werkzeuge) sind die Aktionen, die der Agent ausführen kann. Gutes Tool-Design ist der größte Erfolgsfaktor:
- Klein und spezifisch: Ein Tool macht eine Sache. „get_customer_conditions(customer_id)“ statt „query_database(sql)“.
- Lesend bevorzugt: Schreibende Tools nur mit Mensch-Approval. Lesende Tools brauchen meist keine Bestätigung.
- Klare Beschreibung: Jedes Tool hat einen Doc-String, der im LLM-Prompt landet — präzise Beschreibung führt zu besserer Tool-Auswahl.
- Strukturierte Ein-/Ausgabe: JSON-Schema für Eingabe und Ausgabe. Kein Freitext.
- Fehler-handling explizit: Tool gibt strukturierten Fehler zurück, nicht Exception. Agent kann darauf reagieren.
- Idempotent (wo möglich): Mehrfachaufruf führt zum gleichen Ergebnis. Reduziert Fehler-Risiken.
Frameworks
2026er Stand bei Agent-Frameworks:
- LangGraph (LangChain Inc., Open Source) — Wir nutzen es am häufigsten. Gute Kontrolle über State und Verzweigungen, anständige Beobachtbarkeit über LangSmith. Magie überschaubar.
- Eigenes Lightweight-Setup — TypeScript/Python, eigene State-Maschine, OpenAI/Anthropic SDK direkt. Wir wählen das, wenn LangGraph zu schwer wird.
- Vercel AI SDK — gut für UI-nahe Agenten in Web-Anwendungen. Streaming-fähig.
- OpenAI Agents SDK — neueres Framework, gut für OpenAI-zentrische Setups.
- CrewAI / AutoGen — höhere Magie, gut für Prototyping, problematisch für Produktion (schwerer debuggbar).
Halluzinations-Schutz
Halluzinationen in agentischen Systemen sind besonders gefährlich, weil sie Aktionen auslösen können. Vier Schutzmaßnahmen:
- Strukturierte Ausgabe erzwingen: JSON-Schema-Constraint im LLM-Aufruf. Keine Freitext-Antworten.
- Validierung vor Werkzeug-Aufruf: Argumente werden gegen Schema und Geschäftsregeln geprüft.
- Deterministisches Skelett: LLM trifft keine Geschäftsentscheidungen — Preise, Konditionen, Geschäftsregeln aus deterministischer Logik.
- Mensch im Loop bei schreibenden Aktionen: Standard-Pattern.
Mensch im Loop
Mensch-im-Loop ist 2026 nicht „nice to have“, sondern Standard bei produktiven Agenten im Mittelstand. Drei typische Pattern:
- Pre-Action-Review: Agent generiert Vorschlag, Mensch genehmigt vor Ausführung. Standard für Angebote, E-Mail-Versand, Vertragsänderungen.
- Post-Action-Review: Agent führt aus, Mensch reviewt nachgelagert. Geeignet für lesend-orientierte Aktionen mit niedrigem Risiko.
- Sample-Based-Review: Agent führt automatisch aus, Mensch reviewt zufällig 5–10 % als Qualitätskontrolle. Geeignet für hochfrequente, niedrigem Risiko-Aktionen.
Monitoring
Produktive Agenten brauchen tiefes Monitoring:
- Vollständiges Logging jedes Werkzeug-Aufrufs (Eingabe, Ausgabe, Latenz, Kosten)
- Alerting bei Fehlerquoten, Latenz-Anomalien, Tool-Misuse
- Wöchentliches Eval auf Standard-Test-Set
- Monatliche Stichprobenprüfung tatsächlicher Live-Anfragen
- Kosten-Tracking pro Anfrage (LLM-Tokens × Preis)
Tools: LangSmith (für LangGraph-Setups), Langfuse (Open Source), Helicone, eigene OpenTelemetry-Setups.
Häufige Fehler
- Zu viele Werkzeuge. Mehr als 7–10 Werkzeuge führen zu Verwirrung beim LLM. Wenn nötig: Werkzeug-Hierarchien (sub-Agenten).
- Freie LLM-Entscheidung über Geschäftslogik. Preise, Konditionen, Compliance-Entscheidungen niemals über LLM. Immer deterministisch.
- Keine strukturierte Ausgabe. Freitext-LLM-Outputs sind in Produktion nicht parsebar zuverlässig. JSON-Schema ist Pflicht.
- Schreibende Aktionen ohne Approval. Auto-Versand, Auto-Buchung, Auto-Vertrag — Akzeptanz-Killer und Risiko-Multiplikator.
- Zu viel Magie im Framework. Frameworks mit hoher Auto-Logik sind in Produktion schwer debuggbar. Bei Komplexität lieber selbst bauen.
- Eval erst nach Roll-out. Eval-Set sollte vor dem ersten Live-Tag stehen.
- Kein Audit-Logging. Bei Compliance-Audit später nicht rekonstruierbar.
Echte Beispiele aus laufenden Mandaten
- Angebots-Agent (B2B-Großhandel, 240 MA): ERP + CRM + Vertrag + Angebot-PDF. 4 Min Bearbeitungszeit, +18 % Hit-Rate. Vollständige Case Study.
- Wissens-Recherche-Agent (Steuerkanzlei, 75 MA): Recherche-Agent für Mandanten-Anfragen. Sucht in DATEV, Beck-Online und intern, erstellt strukturierten Recherche-Bericht. Zeitersparnis 40 % je Recherche.
- Reklamations-Agent (Konsumgüter-Großhandel, 180 MA): Eingehende Reklamationen klassifizieren, Standard-Fälle vorbereiten, komplexe Fälle eskalieren. Reduziert Sachbearbeiter-Last um 35 %.
- Recruiting-Vorbereitungs-Agent (HR-Dienstleister, 95 MA): CV-Sichtung, Pre-Screening-Fragen vorbereiten, Match-Scoring (mit Mensch-Approval, Hochrisiko-System unter EU AI Act).
Agent-Mandate KBD 2025–2026
Wenn Sie einen agentischen Use Case erwägen, ist der einfachste Schritt ein kostenfreies Erstgespräch. Wir teilen unsere Erfahrungen aus den oben genannten Mandaten und prüfen, ob Ihr Workflow agentisch tragfähig ist — oder ob ein einfacheres RAG- oder RPA-Setup besser passt.
