Ein Sprachmodell wird nicht dadurch zum Agenten, dass es längere Antworten schreibt. Ein Agent erhält Werkzeuge, kann Zustände lesen und darf innerhalb enger Grenzen Aktionen auslösen. Genau diese Grenze — welche Daten sichtbar sind, welche Werkzeuge erlaubt sind und wann ein Mensch freigeben muss — ist der eigentliche Kern des Systems.
Ich baue keine diffuse „KI-Initiative“, sondern einen abgegrenzten Workflow mit messbarem Eingang, Ergebnis und Eskalationsweg.
So ist ein Agenten-Workflow aufgebaut
- Deterministischer Rahmen: n8n, eigener TypeScript-/Python-Code oder eine bestehende Workflow-Engine steuert Trigger, Zustände, Wiederholungen und Fehlerpfade. Das Modell ist ein Baustein, nicht der gesamte Ablauf.
- Modellschicht: OpenAI, Anthropic, geeignete EU-Anbieter oder lokal bereitgestellte Modelle über Ollama oder vLLM. Eine Routing-Schicht kann Aufgaben nach Qualität, Latenz oder Kosten verteilen.
- Strukturierte Entscheidungen: JSON-Schemas und validierte strukturierte Ausgaben verhindern, dass freie Modelltexte ungeprüft als Systembefehle behandelt werden.
- Werkzeuge: Function Calling verbindet den Agenten mit freigegebenen CRM-, E-Mail-, Kalender-, Ticket- oder Datenbankfunktionen. Jeder Aufruf wird serverseitig autorisiert und validiert.
- Kontext: RAG, Sitzungszustand und gezielt geladene Geschäftsdaten liefern nur den Kontext, der für den jeweiligen Vorgang nötig ist.
- Kontrollpunkte: Freigaben, Betrags- und Mengenlimits, Idempotenzschlüssel, Zeitlimits und ein manueller Übergabepfad begrenzen Fehlerfolgen.
Beispiel: Support-Triage ohne Autopilot
Eine neue Anfrage wird aus dem Ticketsystem übernommen. Klassische Regeln prüfen Kunde, Vertrag und Priorität. Das Modell klassifiziert das Anliegen, ruft bei Bedarf freigegebene Wissensquellen ab und erzeugt einen strukturierten Antwortentwurf. Nur risikoarme Fälle können automatisch vorbereitet werden; Versand, Gutschriften oder Kontenänderungen bleiben bei den festgelegten Freigaben. Ergebnis, Quellen, Tool-Aufrufe und Übergabegrund werden protokolliert.
Evaluation und Betrieb
- repräsentativer Testsatz aus echten, bereinigten Vorgängen
- Kennzahlen für korrekte Klassifikation, valide Tool-Aufrufe, Eskalationsquote, Latenz und Kosten
- Regressionstests für Prompt-, Modell- und Workflow-Änderungen
- Traces pro Lauf, ohne unnötige personenbezogene Inhalte in Logs zu vervielfältigen
- Timeouts, Wiederholungen, Rate Limits, Fallback-Modell und Dead-Letter-Pfad
- Monitoring und Alerts für technische Fehler sowie auffällige Qualitätsänderungen
Typische Anwendungsfälle
- Lead-Qualifizierung mit CRM-Abgleich und sauberer Übergabe
- Support-Triage und belegte Antwortentwürfe
- Dokumentenprüfung und Extraktion in ein festes Schema
- vorbereitende Termin-, Bestell- oder Freigabeprozesse
- interne Recherche über mehrere Wissensquellen
Was enthalten ist
- Anwendungsfall, erlaubte Aktionen und messbare Erfolgskriterien definieren
- Architektur und Modell-/Werkzeugauswahl anhand realer Beispiele
- Integrationen und serverseitig validierte Tool-Funktionen umsetzen
- Prompts, Schemas, RAG-Zugriff und Freigabepunkte entwickeln
- Evaluationssatz, Regressionstests, Tracing und Betriebsalarme einrichten
- Datenflüsse, Rechte, Fehlerpfade und Betrieb schriftlich dokumentieren
Klare Grenze
Keine unbeaufsichtigte Vollautomatisierung für rechtlich, finanziell, medizinisch oder sicherheitskritisch relevante Entscheidungen. Fine-Tuning ist nicht automatisch Teil des Projekts; häufig bringen bessere Daten, Retrieval, Schemas und Evaluation zuerst den größeren Nutzen.