Wir haben unseren KI-Agenten immer wieder neu gebaut. Das hat überlebt – Fuad Ali, Arize AI

Highlights

• Das interne Produktteam von Arize AI hat den produktinternen Produktions-Agenten Alex über einen Zeitraum von zwei Jahren entwickelt und dabei fast die gesamte Logik im Harness-Code statt in externen Agent-Frameworks abgebildet.

• Ein erster Prototyp von Alex Ende 2023 lieferte etwa 50 Prozent Halluzinationen und 50 Prozent nützliche Ergebnisse, wobei sich die Leistung durch verbesserte Modelle und architektonische Anpassungen deutlich steigerte.

• Für das Langzeitgedächtnis erwies sich eine einfache Markdown-Datei pro Benutzer mit einer Begrenzung von 8.000 Zeichen als effektiver und stabiler als komplexe Wissensgraphen oder Vektor-Retrieval-Systeme.

• Anstatt auf zahlreiche spezialisierte Sub-Agenten zu setzen, wechselte das Team zu einem einzigen Agenten, der bei Bedarf spezifische Skills und Werkzeuge dynamisch lädt.

• Produktionssitzungen und Live-Traces dienen direkt als Regressionsdatensätze, um das Verhalten des Agenten kontinuierlich zu testen und zu verbessern.

Timeline

1. 00:00 - 06:19

   Entwicklung und Evolution von Alex

   Der Vortrag beleuchtet die zweijährige Entwicklung des internen Agenten Alex bei Arize AI. Begonnen als einfacher Prototyp mit Modellen der 3.5-Ära, wurde die Logik schrittweise angepasst und Berechnungen vom Modell in den Code verlagert. Der Relaunch als Alex 2.0 im Februar 2026 etablierte Sonnet 4.5 als Standardmodell, gefolgt von der Zusammenlegung zu einem einzigen Agenten im Juni 2026.

   • Alex fungiert als interner Agent zur Analyse von Traces, Erstellung von Evals und Ausführung mehrstufiger Aufgaben.
   • Die Architektur wurde von einem einfachen Skill-Router über iterative Tool-Calling-Schleifen bis hin zu einem zentralen Agenten mit Langzeitgedächtnis weiterentwickelt.
   • Das Team verwendet kein externes Agent-Framework, sondern kontrolliert die Schleife, Pläne und Abbrüche vollständig über eigenen Harness-Code.
2. 06:19 - 13:33

   Architekturentscheidungen: Planung, Abschluss und Gedächtnis

   Bei der Planung und Ausführung stieß das Team auf typische Fallstricke von Sprachmodellen, wie etwa eifrige To-Do-Listen ohne echten Fortschritt. Durch die Verwaltung des Status im Harness und die Vorgabe klarer Abschlussregeln konnte die Zuverlässigkeit erhöht werden. Für das Langzeitgedächtnis erwies sich eine minimalistische Markdown-Datei pro Benutzer als überlegen gegenüber komplexen Architekturen.

   • To-Do-Listen wurden schrittweise in den Harness verlagert, um zu verhindern, dass das Modell übermäßig viele Ressourcen für die reine Listenpflege aufwendet.
   • Ein expliziter Finish-Aufruf, der bei offenen Planelementen mehrfach zurückgewiesen wird, erzwingt ein sauberes Ende der Runde.
   • Große Tool-Ergebnisse werden als Datei gespeichert und mittels Code-Werkzeugen wie JQ im Kontext durchsucht, anstatt den Speicher zu sprengen.
3. 13:33 - 19:57

   Spezialisierung, Modellwahl und Testing in der Produktion

   Der Übergang zu einem einzigen Agenten mit dynamischem Skill-Lading vereinfachte die Architektur erheblich. Das Team nutzt Live-Traces aus der Produktion intensiv als Testumgebung, wobei Softwaremetriken und automatisierte Tools wie Signal helfen, qualitative Fehler zu erkennen. Trotz technischer Metriken bleiben grundlegende Entscheidungen über Geschwindigkeit und Qualität menschliche Aufgaben.

   • Das System ging von zehn verschiedenen Spezialisten wieder zu einem einzigen Agenten über, der Skills bedarfsweise lädt.
   • Live-Produktionssitzungen werden als Traces aufgezeichnet und bilden die Grundlage für Regressionsdatensätze und automatisierte Auswertungen.
   • Menschliche Expertise bleibt unverzichtbar für die Definition goldener Datensätze und die Abwägung zwischen Latenz und Antwortqualität.