Alle fragen: „Sollten wir Agenten einsetzen?“ Die eigentliche Frage lautet: „Wann sollten wir es nicht?“

Ich sehe immer wieder Teams, die einen Agenten anflanschen, weil das Thema gerade heiß ist, und dann feststellen, dass sie eine Zustandsmaschine nachgebaut haben, die sich schlechter debuggen lässt. Agenten lösen ein Problem nicht dadurch, dass es sie gibt. Sie sind ein Mechanismus, um Entscheidungen auf die Laufzeit zu verschieben. Wenn Ihre Eingaben, Werkzeuge und Fehlerfälle gut verstanden sind, bringt Ihnen dieser Aufschub nichts außer Nichtdeterminismus.

Die Architekturfrage lautet nicht „LLM oder nicht“. Sie lautet: Wo liegt die Grenze, an der geurteilt wird?

Drei Stellen, an denen die Grenze liegen kann

Ein einzelner Agent ist ein Programm. Für eine klar umrissene Aufgabe mit bekannten Werkzeugen brauchen Sie überhaupt keine Schleife. Sie brauchen eine deterministische Pipeline, in der das LLM eine Komponente ist und nicht der Orchestrator.

Sobald Sie eine Schleife brauchen, bauen Sie eine Laufzeitumgebung. Und die ist etwas grundlegend anderes. Sie braucht Beobachtbarkeit, Werkzeugberechtigungen, Kosten- und Ratenlimits und eine Möglichkeit, im Nachhinein zu erklären, was sie getan hat. Das ist nicht „mehr KI“. Das sind verteilte Systeme mit einem Sprachmodell als kognitiver Schicht.

Der teure Fehler ist eine Fähigkeit, die Sie nie bestellt haben. Agenten bringen Dinge hervor, für die Sie nicht entworfen haben: offene Werkzeugaufrufe, unbeabsichtigte Nebenwirkungen, eine Größenordnung, die Budgets oder Prüfpflichten sprengt. Hier zeigt sich Reife, nicht in der Raffinesse des Modells, sondern in den Einschränkungen um es herum: Berechtigungen, Freigaben, Beobachtbarkeit und Evaluierungen, die den Fehlerpfad abdecken und nicht nur den Idealfall.

Das Warnsignal

Vieles, was Teams „Agentenarchitektur“ nennen, ist eine Entscheidungsgrenze an der falschen Stelle, überdeckt von weiteren Schichten. Wenn Sie zu einem Framework, einem Orchestrator oder einer Laufzeitumgebung greifen, halten Sie inne und fragen Sie, was Sie eigentlich aufschieben und ob dieser Aufschub etwas bringt oder das System nur schwerer zu debuggen macht.

Einige Faustregeln, die ich vor dem Bauen anwende:

  • Lässt sich die Aufgabe als Schritte in bekannter Reihenfolge beschreiben? Dann eine Pipeline mit dem LLM als einem Schritt, kein Agent.
  • Ruft der Agent bekannte Werkzeuge mit erwarteten Ergebnissen auf? Dann ein einzelner, kontrollierter Agent, dünn über einem deterministischen Kern.
  • Müssen Sie mitten in der Aufgabe in unerwartete Zustände verzweigen? Erst dann eine echte Laufzeitumgebung, und nur, wenn Sie deren Beobachtbarkeit, Limits und Prüfpfad als vollwertige Arbeit übernehmen.
  • Ist der Fehler nicht rückgängig zu machen? Dann gehört gar kein Agent in die Schleife. Ein falscher Werkzeugaufruf innerhalb einer Laufzeitumgebung kann Ihnen schneller schaden, als es ein langsamerer deterministischer Weg je würde.

Erst begrenzen, dann automatisieren. Der Agent sieht cooler aus; er ist in drei Monaten aber auch viel schwerer zu erklären.

Also: Wenn Sie ein neues System planen, was lässt Sie zu einer deterministischen Pipeline greifen statt zu einem Agenten, oder umgekehrt? Mich interessieren die Regeln, nach denen Teams tatsächlich arbeiten, nicht die aus Konferenzvorträgen.