Agenten-Entwicklungszyklus: Von der Idee zum verlässlichen Betrieb

KI-Agenten sind keine klassische Software mit festen Klickpfaden. Sie sind zielorientierte Systeme, die natürliche Sprache verstehen, Entscheidungen treffen und über Tools Aktionen ausführen – von CRM-Updates über Ticketing bis hin zu Telefonie. Genau diese Flexibilität ist der große Hebel, aber sie macht Entwicklung und Betrieb auch anspruchsvoller als bei deterministischen Apps.

Im klassischen Software Development Life Cycle (SDLC) planen Teams Features, implementieren Code, testen deterministisch und deployen. Bei Agenten ist das Verhalten ein Produkt aus Prompting/Policies, Daten (Knowledge Base, RAG), Tool-Verträgen, Modellversionen und Laufzeit-Umgebung. Schon kleine Änderungen – ein neues Modell, ein geänderter API-Response, ein neues Produktdokument – können das Ergebnis spürbar verschieben. Wer im DACH-Raum oder international skaliert, bekommt zusätzlich Variablen wie Datenschutz, Sprachvarianten, Compliance und unterschiedliche Kundenerwartungen.

Warum der klassische SDLC für Agenten nicht reicht

Agenten brechen gleich mehrere Grundannahmen klassischer Softwareentwicklung. In der Praxis sieht man vor allem diese Unterschiede:

• Nicht-Determinismus: Gleicher Input kann unterschiedliche, dennoch plausible Antworten erzeugen. Das ist kein Bug, sondern Teil des Systems – aber ohne Guardrails riskant.
• Unendlicher Eingaberaum: Nutzer sprechen frei (Text/Voice). Man kann nicht alle Varianten vorab in Formulare pressen.
• Teure und langsame Inferenz: LLM-Aufrufe kosten Geld und Zeit. Performance ist Produkt-Feature und Kostenfaktor zugleich.
• Abhängigkeiten jenseits von Code: Prompt, Policies, Wissensbasis, Model-Version, Retrieval, Tool-Schemas – alles sind “Dependencies”.
• Upgrades ohne Change-Management: Ein Modell-Upgrade kann Tonalität, Tool-Nutzung oder Entscheidungslogik verändern. Ohne Regression-Suite ist das Roulette.

Die Konsequenz: Agenten brauchen einen eigenen Entwicklungszyklus – mit klaren Spezifikationen, reproduzierbaren Releases, kontinuierlicher Qualitätssicherung und Observability im Betrieb.

Der Setio Agent Development Life Cycle (ADLC) – Überblick

Wir nutzen einen pragmatischen Lebenszyklus, der sich wie ein Loop verhält: Spezifizieren → Bauen → Evaluieren → Testen → Releasen → Beobachten → Verbessern. Jede Phase erzeugt Artefakte, die später die Qualität sichern (z. B. Tests, Policies, Logs). Der entscheidende Punkt: Agenten werden wie Produkte betrieben – nicht wie einmalige Implementierungen.

Phase 1: Discovery & Spezifikation (Outcome statt Feature)

Ein Agent-Projekt scheitert selten an “zu wenig KI” – sondern an unklaren Erwartungen. Darum starten wir mit einer Spezifikation, die Agenten-typisch ist: nicht nur Funktionen, sondern Outcomes, Risiken und Eskalationsregeln.

• Use Case auswählen: Ein klarer, wiederholbarer Prozess mit hohem Volumen (z. B. Terminierung, Statusabfragen, First-Level-Support) ist ideal.
• Definition of Done: Was ist ein “gelöster” Fall? Was ist “teilgelöst”? Wann muss der Agent abgeben?
• Risikoklassen: Welche Themen sind sensibel (Zahlungen, Verträge, medizinische Aussagen)? Dort gehören harte Regeln und oft Human-in-the-Loop hin.
• KPIs: Lösungquote, Eskalationsrate, Zeit bis Lösung, Kosten pro Kontakt, CSAT/QA-Score, Conversion (je nach Use Case).

Ein praktischer Tipp: Formuliere die Spezifikation als Journey-Katalog. Jede Journey enthält: Eingangsbedingungen, Pflichtfragen, zulässige Aktionen, verbotene Aktionen, Eskalationsgründe und Output-Format. Das klingt formal, spart aber später Wochen an Debugging.

Wichtig: Für DACH und internationale Deployments definieren wir auch Sprach- und Compliance-Anforderungen (z. B. Tonalität pro Markt, Datenschutz-Hinweise, Logging-Policy, Aufbewahrungsfristen).

Phase 2: Architektur – Skills, Tools, Daten (LLM ist nur ein Teil)

Ein verlässlicher Agent entsteht aus Komponenten, die man gezielt testbar macht:

• Skills/Workflows: Wiederkehrende Abläufe werden als Schritte modelliert (z. B. “Identifizieren → Prüfen → Aktion → Bestätigen”).
• Tool-Verträge: APIs werden “agentensicher” gemacht: klare Inputs/Outputs, idempotente Actions, Timeouts, Fehlertypen, Rate Limits.
• Wissensschicht: RAG/Knowledge Base mit Governance: Quellen, Aktualität, Freigaben, und ein Plan für Updates.
• Policy-Layer: Harte Regeln (z. B. Rückgabefristen, Berechtigung, Preislogik) werden deterministisch durchgesetzt.

Ein praktischer Grundsatz: Behandle das LLM wie einen kreativen, aber unzuverlässigen Mitarbeiter. Es darf Vorschläge machen – aber Aktionen müssen über sichere Tools, Regeln und Validierungen laufen.

In der Praxis bewährt sich ein “Read/Write”-Prinzip: Der Agent darf vieles lesen (z. B. Status, Verfügbarkeit), aber schreibende Aktionen (Buchung, Storno, Änderung von Kundendaten) passieren nur nach expliziter Bestätigung, häufig mit zusätzlicher Validierung und Audit-Log.

Phase 3: Build – Prompting, Orchestrierung, Gesprächsdesign

In dieser Phase wird der Agent “lebendig”. Gute Ergebnisse entstehen meist nicht durch einen langen Prompt, sondern durch saubere Orchestrierung:

• System-Prompt & Stil: Rolle, Tonalität, Ziel und Grenzen. Für Voice Agents zusätzlich: kürzere Sätze, klare Rückfragen, “nicht zu viel reden”.
• Tool-Entscheidung: Wann wird ein Tool aufgerufen? Welche Daten werden benötigt? Was passiert bei fehlenden Daten?
• Bestätigungsschritte: Für riskante Aktionen (Storno, Planwechsel, Datenänderungen) arbeiten wir mit expliziter Bestätigung.
• Fallbacks: Wenn Retrieval keine Treffer liefert oder Tools fehlschlagen, muss der Agent sauber eskalieren statt zu raten.

Hier entstehen auch die ersten Golden Conversations: realistische Beispiel-Dialoge, die später als Tests dienen. Sie sind das Agenten-Pendant zu Unit-Tests – nur eben als Gespräche.

Ein weiterer “Make or break”-Punkt ist Fehlertoleranz: Tools fallen aus, Daten sind unvollständig, Nutzer wechseln das Thema. Ein guter Agent stellt Rückfragen, erklärt kurz das nächste Vorgehen und bleibt handlungsfähig – statt sich in langen Entschuldigungen zu verlieren.

Agenten-Security: Prompt Injection, Datenabfluss und Rechte

Sobald Agenten Tools und Datenzugriffe haben, werden sie zu einem Security-Thema. Typische Angriffe sind nicht “Hacker-Console”, sondern subtile Aufforderungen in natürlicher Sprache: Nutzer versuchen, Policies zu umgehen, interne Prompts zu extrahieren oder private Daten anzufragen.

• Least Privilege: Tools erhalten nur die minimal nötigen Rechte, getrennt nach Lesen/Schreiben.
• Allowlists: Der Agent darf nur definierte Aktionen ausführen und nur auf definierten Ressourcen.
• PII-Handling: Maskierung/Redaktion in Logs, klare Regeln für Speicherung und Zugriff.
• Injection-Resilience: System-Prompt + Policy-Layer + Tool-Validierung verhindern, dass Sprache zu “Root-Zugriff” wird.

Gerade im DACH-Raum ist Governance hier entscheidend: Wer darf Transkripte sehen, wie lange werden sie gespeichert, welche Daten dürfen im Agent-Context landen? Diese Fragen gehören in die Spezifikation – nicht erst in den Audit.

Phase 4: Qualitätssicherung – Human Review als Superkraft

Ob ein Agent “richtig” gehandelt hat, ist häufig eine fachliche Frage. Darum gehört strukturierte menschliche Bewertung in den Prozess – nicht als einmaliger Abnahmetest, sondern als kontinuierliche Routine.

Wir arbeiten typischerweise mit einem Review-Schema, das pro Gespräch markiert:

• Outcome: gelöst / teilweise / eskaliert / abgebrochen
• Policy: eingehalten / verletzt / unklar
• Tooling: korrekt genutzt / falsches Tool / fehlender Call / Fehlerbehandlung
• Wissen: Antwort korrekt / Wissenslücke / Retrieval-Problem
• Tonalität: on-brand / zu lang / zu defensiv / zu forsch

Der Mehrwert: Jedes markierte Problem wird ein Ticket und (sofern möglich) ein Testfall. So entsteht eine Regression-Suite, die mit dem Agenten mitwächst.

Damit Reviews wirklich helfen, brauchen sie ein gutes Sampling: nicht nur “schlimme Fälle”, sondern auch repräsentative, typische Gespräche. Außerdem lohnt sich ein kurzer Abgleich zwischen Reviewer:innen (“Was ist ein Policy-Verstoß?”), damit Bewertungen konsistent sind – besonders, wenn mehrere Teams oder Länder beteiligt sind.

Phase 5: Tests – Von Tool-Unit-Tests bis Conversation Regression

Agenten-Tests müssen zwei Ebenen abdecken: deterministische Komponenten (Tools/Policies) und probabilistisches Verhalten (LLM). Ein robustes Setup nutzt mehrere Testarten:

• Tool-Tests: Validierung von Schemas, Error-Codes, Timeouts, Idempotency. Hier ist klassische QA möglich.
• Policy-Tests: Harte Regeln werden wie Business-Logik getestet (z. B. “Rückgabe nur 30 Tage”).
• Conversation Tests: Gesprächs-Snapshots laufen gegen Mock-APIs, damit Reproduktion möglich ist.
• Regression Suite: Alle kritischen Fälle, die jemals schief liefen, werden dauerhaft abgedeckt.
• Load/Cost Tests: Vor Go-Live prüfen wir Latenz, Token-Kosten und Skalierung – besonders wichtig bei Voice.

Wichtig: Bei LLM-Tests hilft “LLM-as-a-judge” manchmal – aber nur kalibriert und ergänzt durch menschliche Stichproben. Sonst optimiert man am Ende auf den Judge statt auf den Nutzer.

Ein praktisches Muster ist die Test-Pyramide für Agenten: viele günstige, deterministische Tests (Tools/Policies), ergänzt um eine kleinere Anzahl teurer Conversation-Tests, plus ein Set adversarialer Fälle (Injection, PII, Grenzfälle). So bleibt die Suite schnell genug für tägliche Iterationen.

Messung: Was „Qualität“ bei Agenten wirklich heißt

“Gute Antwort” ist zu vage. In der Praxis trennen wir Qualitätsmetriken in mehrere Dimensionen:

• Task Success: Wurde das Ziel erreicht (Termin gebucht, Ticket erstellt, Status geliefert)?
• Correctness: Stimmt die Information – und ist sie auf die richtige Quelle zurückzuführen?
• Tool Correctness: Hat der Agent das richtige Tool zur richtigen Zeit genutzt, mit korrekten Parametern?
• Safety/Compliance: Keine Policy-Verstöße, keine unzulässigen Zusagen, kein PII-Leak.
• Experience: Tonalität, Länge, Klarheit, Umgang mit Rückfragen.

Diese Dimensionen lassen sich teilweise automatisiert messen (z. B. Tool-Calls, KPIs), teilweise nur über Reviews. Wichtig ist, dass man die Metriken vor dem Go-Live definiert – sonst optimiert man nach Bauchgefühl.

Phase 6: Release – Immutable Snapshots, Rollback und Experimente

Damit Änderungen kontrollierbar bleiben, behandeln wir einen Agenten-Release wie ein “Snapshot”. Ein Snapshot enthält nicht nur Code, sondern auch Prompt/Policies, Modellversion, Tool-Versionen und eine definierte Wissensbasis.

Warum ist das wichtig?

• Reproduzierbarkeit: Man kann erklären, warum ein Agent gestern anders reagiert hat als heute.
• Rollback: Wenn ein Release regressiert, kann man sofort zurück.
• Vergleichbarkeit: A/B-Tests zwischen Releases zeigen, ob ein Update wirklich die KPIs verbessert.

Gerade bei Modell-Upgrades ist das essenziell: Statt “Upgrade und hoffen” läuft ein neuer Snapshot durch die Regression-Suite und startet als Canary/Partial Rollout.

Upgrade-Playbook: Modelle, Prompts und Daten sicher aktualisieren

In der Realität ändert sich alles: Modelle werden besser, Preise ändern sich, Dokumentation wächst, Tool-Schemas entwickeln sich weiter. Ein Update ohne Playbook führt fast immer zu Überraschungen. Ein bewährter Ablauf:

1. Änderung isolieren: Modellwechsel oder Promptwechsel oder Datenupdate – nicht alles gleichzeitig.
2. Regression laufen lassen: Golden Conversations + bekannte Fehlerfälle + Adversarial Set.
3. Canary: kleiner Traffic-Anteil, striktes Monitoring, schneller Rollback.
4. Freigabe: Erst wenn KPIs stabil oder besser sind, erfolgt der Rollout.

So bleibt die Entwicklung schnell – aber kontrolliert. Das ist besonders relevant, wenn mehrere Sprachen oder Märkte unterstützt werden: Ein Update kann in Sprache A funktionieren, in Sprache B aber Tonalität oder Begrifflichkeiten verschieben.

Phase 7: Betrieb – Observability, Kostenkontrolle, Governance

Im Live-Betrieb entscheidet sich, ob ein Agent ein Produkt wird. Dafür braucht es Observability, die über “Antworten anschauen” hinausgeht:

• Tracing: Welche Tools wurden aufgerufen? Welche Daten wurden genutzt? Wo ist der Agent abgebogen?
• KPIs: Lösungquote, Eskalationen, wiederholte Kontakte, CSAT/QA, Conversion.
• Safety Metrics: Policy-Verstöße, PII-Leaks, unzulässige Aussagen, Halluzinations-Indikatoren.
• Cost & Latency: Tokens pro Kontakt, Zeit bis Antwort, Ausreißer, Budget-Limits.

Für Voice Agents kommen zusätzliche Signale dazu: Abbruchraten, Latenz pro Turn, Unterbrechungen, “dead air” und Übergabequalität an Menschen.

Ein unterschätzter Punkt ist Incident Response: Was passiert, wenn ein Tool 30 Minuten down ist? Wenn ein Retrieval-Index fehlerhaft ist? Wenn ein Agent plötzlich häufig eskaliert? Ein guter Betrieb hat Runbooks: klare Maßnahmen, Verantwortlichkeiten, und einen Plan für Downgrade/Failover.

Beispiel: Voice Agent für Terminbuchungen (End-to-End)

Ein typischer Einstieg für Unternehmen im DACH-Raum ist ein Voice Agent, der Anrufe annimmt, Anliegen erkennt und Termine bucht. Der ADLC sieht hier konkret so aus:

1. Spezifikation: Welche Terminarten? Welche Standorte? Welche Daten müssen erfragt werden? Wann eskalieren?
2. Tooling: Kalender/CRM-API mit klaren Slots, Validierung (Öffnungszeiten), und idempotenten Buchungen.
3. Conversation Design: Kurze Fragen, klare Bestätigungen (“Ich buche am Dienstag um 10:30 – stimmt das?”).
4. QA: Review von echten Transkripten: Hat der Agent richtig zugeordnet? War die Tonalität passend?
5. Regression: “Doppelte Buchung”, “kein Slot verfügbar”, “falscher Name”, “Dialekt/Umgangssprache”.
6. Release: Canary auf einem Standort oder einer Terminart, dann Rollout.
7. Monitoring: Abbruchraten und Kosten pro gebuchtem Termin; laufende Optimierung.

In vielen Projekten ist der größte Gewinn nicht “mehr Automatisierung”, sondern konstantere Qualität: ein sauberer Gesprächsleitfaden, weniger Wartezeit, weniger Weiterleitungen – und klar definierte Übergaben an Menschen, wenn es komplex wird.

Häufige Stolperfallen (und wie man sie vermeidet)

• Zu großer Scope: lieber ein Journey sauber lösen als zehn halb.
• Tools ohne Guardrails: ein “updateCustomer” ohne Validierung ist ein Risiko.
• Keine Regression: jedes gelöste Problem muss als Testfall überleben.
• Kein Ownership: Agenten brauchen Produktverantwortung und ein Backlog.

Checkliste: Vor dem Go-Live

• Klare Policies für riskante Aktionen und Datenzugriffe
• Regression Suite aus Golden Conversations + bekannten Fehlerfällen
• Mock-APIs für reproduzierbare Conversation Tests
• Monitoring (KPIs, Safety, Kosten) + Alerting
• Rollback-Plan mit Snapshot-Versionen
• Human Escalation sauber definiert (wann, wie, an wen)

Ein guter Agent ist kein einmaliges Projekt, sondern ein Produkt mit klaren Qualitätszyklen.

Wer den Agenten-Entwicklungszyklus konsequent umsetzt, bekommt Systeme, die nicht nur beeindruckend klingen, sondern verlässlich liefern – im DACH-Raum und international.