02, Agenten
Wie wir Agenten bauen und betreiben
Das Vorgehensmodell in zehn Schritten, die fünf Betriebsmodelle im Vergleich, und die Ursachen, an denen Agentenprojekte typischerweise scheitern.
02.1
Zehn Schritte beim Agentenbau
Die Reihenfolge trägt hier den Inhalt. Wer bei Schritt drei beginnt, holt Schritt zwei später zu einem Vielfachen der Kosten nach.
- 01 Anwendungsfall vor Technologie
- Wir beginnen mit dem Prozess und der messbaren Zielgröße, nicht mit dem Modell.
- 02 Eval-getriebene Entwicklung
- Vor der Implementierung steht fest, wie Erfolg gemessen wird. Testdatensätze und automatisierte Bewertungen laufen von Anfang an mit und begleiten jede Änderung.
- 03 Kontext-Engineering
- Bewusste Steuerung dessen, was der Agent zu welchem Zeitpunkt sieht: Datenanbindung, Abruf relevanter Informationen, Begrenzung des Kontexts.
- 04 Werkzeugdesign
- Agenten sind nur so gut wie ihre Werkzeuge. Klar abgegrenzt, robust, gut dokumentiert, mit definiertem Fehlerverhalten.
- 05 Enger Handlungsrahmen
- Berechtigungen, Guardrails, Validierung der Ausgaben, definierte Abbruchbedingungen. Autonomie wird schrittweise erweitert, nicht vorausgesetzt.
- 06 Human in the Loop
- Freigaben dort, wo Fehler teuer sind. Volle Automatisierung dort, wo sie es nicht sind.
- 07 Observability
- Vollständiges Tracing von Entscheidungen, Werkzeugaufrufen und Kosten. Ohne Beobachtbarkeit kein Betrieb.
- 08 Kosten und Latenz
- Modellwahl pro Teilaufgabe, Caching, kleinere Modelle wo möglich.
- 09 Betrieb und Weiterentwicklung
- Versionierung, Regressionstests bei Modellwechseln, definierter Prozess für Modell-Updates.
- 10 Iterativer Zuschnitt
- Kleine, produktiv nutzbare Ausbaustufe zuerst, dann erweitern. Kein zwölfmonatiges Projekt ohne Zwischenergebnis.
02.2
Betriebs- und Hostingmodelle im Vergleich
Wir betreiben eigene GPU-Infrastruktur und kennen den Betrieb dieser Modelle aus eigener Erfahrung. Keine Variante ist pauschal besser als eine andere.
| Modell | Datenhoheit | Kosten | Modellqualität | Latenz | Betriebsaufwand | Typischer Einsatzfall |
|---|---|---|---|---|---|---|
| Lokal beim Kunden | vollständig | Hardware vorab | offene Gewichte | sehr niedrig | beim Kunden | Daten dürfen das Haus nicht verlassen |
| On-Premise im Rechenzentrum | vollständig | Hardware vorab | offene Gewichte | niedrig | geteilt | Integration in bestehende Betriebsprozesse |
| Gehostet in Deutschland | vertraglich klar | nutzungsabhängig | offene Gewichte | niedrig | bei uns | DSGVO-Klarheit ohne eigene Hardware |
| Cloud oder API | beim Anbieter | pro Anfrage | höchste verfügbare | mittel | minimal | Geschwindigkeit und Modellqualität zuerst |
| Hybrid | nach Datenklasse | gemischt | je Teilaufgabe | gemischt | geteilt | Sensibles lokal, unkritische Last extern |
Zur Beratung gehört die Modellauswahl: offene Gewichte gegen proprietär, Größe gegen Kosten, Feintuning gegen Kontextsteuerung.
02.3
Agenten, die im Betrieb besser werden
Ein Agent, der nach einem Jahr genauso gut ist wie am ersten Tag, hat ein Jahr lang nichts gelernt. Selbstverbesserung ist dabei kein Modell, das sich selbst umschreibt, sondern ein geschlossener Kreis aus Messung, Kandidat, Vergleich und Rückfallebene.
- 01 Jede Episode wird zum Datensatz
- Freigaben, Ablehnungen, Korrekturen und blockierte Zugriffe werden mit Vorzustand, Begründung und Ergebnis gespeichert. Eine abgelehnte Aktion ist dabei der wertvollste Datensatz, weil genau dort der Abstand zwischen Vorschlag und richtiger Antwort steht.
- 02 Korrekturen werden zu Testfällen
- Aus jeder Korrektur entsteht ein Fall mit erwarteter Ausgabe. Der Testdatensatz wächst mit dem Betrieb, statt bei der Abnahme einzufrieren.
- 03 Kandidat statt Eingriff im laufenden System
- Änderungen an Anweisungen, Werkzeugen, Regeln oder Modell entstehen als versionierter Kandidat neben der laufenden Version, nicht in ihr.
- 04 Vergleich auf demselben Datensatz
- Kandidat und laufende Version werden unter gleichen Bedingungen bewertet. Ausgerollt wird nur, was im Zielmaß besser ist und an keiner anderen Stelle schlechter.
- 05 Rückfallebene und Beobachtung
- Die Vorversion bleibt lauffähig. Weichen die Kennzahlen im Betrieb ab, wird automatisch zurückgeschaltet, ohne nächtlichen Eingriff.
- 06 Lücken werden sichtbar, nicht umgangen
- Wiederkehrende Abbrüche und fehlende Werkzeuge landen als Vorlage auf dem Tisch, statt vom Modell kreativ umgangen zu werden.
Selbstverbesserung ohne Testdatensatz ist Drift. Ein System, das sich ohne Messung verändert, wird nicht besser, es wird nur anders, und niemand kann sagen, in welche Richtung.
02.4
Warum Agentenprojekte scheitern
Sechs Ursachen, die wir regelmäßig sehen, und was wir jeweils anders machen. Alle sechs lassen sich vor der ersten Zeile Code adressieren.
Woran es scheitert
- Kein Erfolgsmaß, niemand kann sagen, ob es besser wird
- Zu breiter Zuschnitt, kein produktiv nutzbares Zwischenergebnis
- Keine echte Datenanbindung, nur Beispieldateien
- Keine Beobachtbarkeit, Fehler werden nicht gefunden
- Unkontrollierte Kosten bis zur ersten Rechnung
- Kein Betriebskonzept, nach dem Start ist niemand zuständig
Was wir stattdessen tun
- Erfolgsmaß und Testdatensatz stehen vor der Implementierung fest
- Kleinste produktiv nutzbare Ausbaustufe zuerst, dann erweitern
- Die Anbindung an das echte System ist Teil der ersten Iteration
- Tracing von Entscheidungen, Werkzeugaufrufen und Kosten von Anfang an
- Kosten pro Anfrage sind eine Kennzahl im Monitoring
- Versionierung, Regressionstests und ein definierter Update-Prozess