Use-Case Pillar · Agenten

    KI-Agenten im Unternehmen — Praxis-Leitfaden

    2026 sind KI-Agenten erste produktive Realität — aber nur in eng definierten Workflows. Wann sie funktionieren, wann nicht, wie man sie sauber baut und welche Halluzinations-Schutzmaßnahmen Pflicht sind.

    30 Tage
    zum ersten Pilot
    Ø 40 %
    weniger manuelle Arbeit
    100 %
    Hosting in Deutschland
    DSGVO + EU AI Act
    konform implementiert

    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?

    Tabelle horizontal scrollen
    Agent vs. einfaches RAG vs. klassische Automatisierung
    Kriterium
    Agent passt
    Empfehlung
    RAG reicht
    weniger Aufwand
    RPA/Skript besser
    deterministisch
    Mehrere Quellsysteme abzufragen
    Sprachverstehen nötig (E-Mail, PDF)
    Bedingte Logik / Verzweigungen
    Schreibende Aktionen (mit Approval)
    Reine Frage-Antwort
    Streng deterministische Regel
    Hochfrequente Massendaten (Mio./Tag)

    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)

    1. 1Schritt 1

      Anfrage parsen (LLM)

      E-Mail/PDF mit strukturierter Ausgabe parsen — JSON-Schema-Output erzwungen.

      • Strukturierte Positionsliste
      • Kunde identifiziert
    2. 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
    3. 3Schritt 3

      Konditionen (deterministisch)

      Vertragsdaten, Mengenrabatte, Margenregeln. Pure Python/SQL-Logik.

      • Position-Preise
    4. 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:

    1. Strukturierte Ausgabe erzwingen: JSON-Schema-Constraint im LLM-Aufruf. Keine Freitext-Antworten.
    2. Validierung vor Werkzeug-Aufruf: Argumente werden gegen Schema und Geschäftsregeln geprüft.
    3. Deterministisches Skelett: LLM trifft keine Geschäftsentscheidungen — Preise, Konditionen, Geschäftsregeln aus deterministischer Logik.
    4. 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

    1. Zu viele Werkzeuge. Mehr als 7–10 Werkzeuge führen zu Verwirrung beim LLM. Wenn nötig: Werkzeug-Hierarchien (sub-Agenten).
    2. Freie LLM-Entscheidung über Geschäftslogik. Preise, Konditionen, Compliance-Entscheidungen niemals über LLM. Immer deterministisch.
    3. Keine strukturierte Ausgabe. Freitext-LLM-Outputs sind in Produktion nicht parsebar zuverlässig. JSON-Schema ist Pflicht.
    4. Schreibende Aktionen ohne Approval. Auto-Versand, Auto-Buchung, Auto-Vertrag — Akzeptanz-Killer und Risiko-Multiplikator.
    5. Zu viel Magie im Framework. Frameworks mit hoher Auto-Logik sind in Produktion schwer debuggbar. Bei Komplexität lieber selbst bauen.
    6. Eval erst nach Roll-out. Eval-Set sollte vor dem ersten Live-Tag stehen.
    7. 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

    5
    produktive Agenten in Live-Betrieb
    7
    Ø Werkzeuge pro Agent
    100 %
    mit Mensch-im-Loop bei schreibenden Aktionen
    92 %
    Ø Eval-Genauigkeit

    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.

    Häufig gestellte Fragen

    Was ist der Unterschied zwischen Chatbot und Agent?
    Ein Chatbot beantwortet Fragen aus einem Wissensbestand. Ein Agent führt Aktionen aus — er ruft Werkzeuge auf, liest und schreibt in Systeme, trifft Entscheidungen über das nächste Werkzeug. Ein RAG-Bot ist kein Agent, ein System, das auf Anfrage in ERP nach Verfügbarkeit prüft, im PIM nach Datenblatt sucht und ein Angebot generiert, ist ein Agent.
    Sind Agenten 2026 wirklich produktiv einsetzbar?
    Ja, aber nur in eng definierten Workflows. Offene 'AGI-Agenten', die alles machen, sind 2026 weiterhin unzuverlässig. Eng begrenzte Agenten mit 3–7 klar definierten Werkzeugen funktionieren produktiv. Wir haben mehrere agentische Workflows produktiv im Live-Betrieb — z. B. Angebotserstellung, siehe Case Study.
    Welche Frameworks setzt KBD ein?
    Häufig: LangGraph (Open Source, gute Kontrolle über State), eigene Lightweight-Setups in TypeScript/Python (für komplexere Anforderungen), gelegentlich Vercel AI SDK für UI-nahe Agenten. Wir vermeiden bewusst Frameworks mit hoher Magie (zu viel Auto-Logik = schwer debuggbar in Produktion).
    Wie verhindere ich, dass der Agent Schaden anrichtet?
    Vier Schutzmaßnahmen: (1) Werkzeuge nur lesend, schreibende Aktionen explizit Mensch-freigabepflichtig. (2) Sandboxing für Werkzeug-Aufrufe (z. B. Datenbank-Reader mit eingeschränkten Rechten). (3) Audit-Logging jedes Werkzeug-Aufrufs. (4) Notfall-Stop bei wiederholten Fehl-Verhaltensweisen.
    Welche LLMs eignen sich für Agenten?
    GPT-4-Klasse, Claude 3.5+ Sonnet, Mistral Large. Diese Modelle haben gutes Instruction-Following und Werkzeug-Aufruf-Fähigkeit. Open-Weight Llama 3.1 70B+ funktioniert ebenfalls, aber mit höherem Engineering-Aufwand. Für einfache Agenten reicht oft Mistral Small oder Claude 3.5 Haiku.
    Wie messe ich Agent-Qualität?
    Eval-Sets mit End-to-End-Tests: Eingangsanfrage → erwartetes Endergebnis. Pro Test: erfolgte alle Werkzeug-Aufrufe korrekt? Ergebnis korrekt? Logging vollständig? Wir bauen typisch 100+ Test-Cases pro produktivem Agent und lassen die Eval mindestens wöchentlich laufen.
    Können Agenten gelernt agieren?
    In sehr engem Sinne ja (Memory, Persistente Conversation), in dem 'lernt von Erfahrung'-Sinne nein. Agenten 'lernen' durch explizite Prompt-Anpassungen und Werkzeug-Aktualisierungen, nicht durch eigenständiges Selbst-Training. Diese Disziplin ist im Mittelstands-Kontext gut — keine ungeplanten Verhaltens-Änderungen.
    Was kostet ein produktiver Agent?
    Pilot 24.900–39.900 €, Implementation 79.000–149.000 €, Managed Service 5.500–9.900 €/Monat. LLM-Kosten höher als bei einfachen RAG-Bots (mehrere LLM-Aufrufe pro Anfrage), typisch 800–3.500 €/Monat.

    Kostenfreie KI-Potenzialanalyse

    30 Minuten Strategiegespräch mit einem KBD-Berater. Konkret, ehrlich, ohne Verkaufsdruck — wir sagen Ihnen offen, ob KI für Ihren Use Case lohnt.

    • Analyse Ihrer 3 wichtigsten Prozesse
    • Konkrete Roadmap mit Aufwandsschätzung
    • Indikative ROI-Rechnung für Ihren Case

    Ergänzend lesenswert