12-Factor Agents: Verlässliche LLM-Anwendungen bauen

Der „Agenten“-Rausch der generativen KI versprach Software, die selbstständig schlussfolgern und handeln kann, doch die ersten Ergebnisse blieben hinter dem Hype zurück. Viele Teams stellten fest, dass diese KI-Agenten jenseits eindrucksvoller Demos oft bei 70 bis 80 Prozent Zuverlässigkeit an eine Grenze stießen: Sie liefen in Schleifen, erzeugten fehlerhafte Tool-Aufrufe oder verloren den Überblick über ihren Zustand. Dex Horthy, KI-Engineer und Gründer von HumanLayer, erlebte das aus erster Hand, nachdem er so ziemlich jedes verfügbare Agenten-Framework ausprobiert hatte: Plug-and-Play-Bibliotheken wie LangChain, minimalistische „smol“-Agenten und eher „produktionsreife“ Systeme wie LangGraph und Griptape. Was blieb davon hängen? Die meisten „KI-Agenten“, die in Produktion tatsächlich funktionieren, sind keine magischen autonomen Wesen. Sie sind vor allem gut gebaute klassische Software, in die an den richtigen Stellen gezielt LLM-Fähigkeiten eingestreut sind.

Anfang 2025 verdichtete Horthy diese hart erarbeiteten Erkenntnisse zu einer Sammlung von Best Practices, die er „12-Factor Agents“ nennt. Er stellte sie in einem Vortrag auf der AI Engineer World’s Fair und in einem mittlerweile populären GitHub-Repository vor. Das Regelwerk orientiert sich im Geist an Herokus klassischer 12-Factor-App-Methodik und legt zwölf Prinzipien für LLM-gestützte Software fest, die robust, wartbar und wirklich produktionsreif sein soll. Der Ansatz traf in der Entwicklergemeinde einen Nerv: Der Open-Source-Leitfaden landete rasch auf der Startseite von Hacker News, sammelte Tausende GitHub-Sterne und löste unter KI-Engineers lebhafte Diskussionen darüber aus, wie man „KI-native“ Anwendungen richtig baut. In diesem Artikel sehen wir uns an, was hinter diesen 12 Faktoren steckt, wie sie sich in konkrete Implementierungsmuster übersetzen lassen und wie diese Philosophie im Vergleich zu anderen Agenten-Frameworks auf dem Markt abschneidet.

Warum LLM-Agenten neue Grundregeln brauchen

Horthys 12-Factor Agents ist im Grunde eine Antwort auf die Schwächen der ersten Generation von LLM-Agenten. In den vergangenen zwei Jahren griffen Entwickler begeistert zu Bibliotheken wie LangChain oder experimentellen Projekten wie Auto-GPT, um große Sprachmodelle Tools und mehrstufige Aufgaben orchestrieren zu lassen. In Interviews mit mehr als 100 Startup-Gründern und KI-Engineers hörte Horthy aber immer wieder dieselbe Geschichte: Teams griffen zu einem Agenten-Framework, um schnell voranzukommen, erreichten vielleicht 70 bis 80 Prozent der gewünschten Funktionalität und stießen dann an eine Leistungsgrenze. Ab einem gewissen Punkt begann der Agent, Schritte zu halluzinieren, endlos in Schleifen zu laufen oder auf andere Weise an der Zuverlässigkeit zu scheitern, die echte Nutzer brauchen. Um über diese 80-Prozent-Marke hinauszukommen, mussten Teams oft in die Eingeweide des Frameworks steigen: Prompts per Reverse Engineering rekonstruieren, die versteckte Zustandsverwaltung anpassen, Standardlogik überschreiben. Im Grunde bauten sie die Lösung von Grund auf neu. Wie Horthy anmerkte, stützten sich viele der erfolgreichen KI-Produkte, die er gesehen hat, überhaupt nicht auf fertige Agenten-Frameworks. Sie suchten sich stattdessen einige modulare Techniken aus dem „agentischen“ Ansatz heraus und bauten sie in ihren eigenen Stack ein.

Im Geist wie im Namen verneigt sich 12-Factor Agents vor den bekannten 12-Factor-App-Richtlinien für Cloud-Anwendungen. So wie die ursprünglichen 12 Faktoren (2011 von Heroku veröffentlicht) einen Bauplan für skalierbare, wartbare Webdienste lieferten, will Horthys Version bewährte Disziplin aus der Softwaretechnik in die ungezügelte Welt der LLM-gestützten Agenten bringen. Wichtig dabei: Es handelt sich nicht um ein fertiges Framework oder SDK, sondern um ein sprachunabhängiges Manifest von Prinzipien, das Architekten in jedem Tech-Stack Orientierung geben soll. „KI-native“ Systeme, so Horthy, sollten nicht Jahrzehnte an Wissen über Modularität, Beobachtbarkeit und Robustheit über Bord werfen. Wir sollten KI-Agenten vielmehr als eine weitere Art von Softwarekomponente behandeln und solide Engineering-Praktiken auf sie anwenden. Ein Entwickler formulierte es so: „Selbst wenn LLMs 100-mal klüger werden, brauchen wir für den Weg in die Produktion weiterhin Kontextkompression, deterministische Steuerung und Schema-Validierung.“ Anders gesagt: Wie leistungsfähig das Modell auch ist, verlässliche Anwendungen brauchen eine Struktur darum herum.

Die 12 Faktoren für verlässliche KI-Agenten

Wie die ursprüngliche 12-Factor App ist auch Horthys Regelwerk 12-Factor Agents in ein Dutzend zentraler Prinzipien gegliedert. Sie behandeln Prompt-Design und Tool-Nutzung ebenso wie Zustandsverwaltung und Skalierung. Die Grundidee: die „große, monolithische KI“ in klar abgegrenzte Teile zerlegen und Entwicklern die volle Kontrolle über jeden Teil des Agentenbetriebs geben. Im Folgenden skizzieren wir jeden Faktor und was er für Teams, die LLM-gestützte Anwendungen bauen, in der Praxis bedeutet. Wer sich an diese Richtlinien hält, kann aus einer unzuverlässigen KI-Demo ein produktionsreifes System machen, dem Entwickler (und CTOs) tatsächlich vertrauen können.

Prompts, Tools und Kontext strukturieren

Faktor 1: Von natürlicher Sprache zu Tool-Aufrufen. Lassen Sie die Ausgaben des Modells nicht zum frei formulierten Joker werden. Der Agent soll Anfragen in natürlicher Sprache in strukturierte, schemakonforme Befehle für Tools oder Funktionen umwandeln. In der Praxis heißt das: Sie definieren eine klare Schnittstelle (oft ein JSON-Schema oder eine Funktionssignatur), die das LLM verwenden muss, wenn es eine Aktion ausführen will. Zwingt man das Modell, einen wohlgeformten „Tool-Aufruf“ statt beliebigen Text zu erzeugen, verhindert man Folgefehler und stellt sicher, dass der nächste Schritt deterministisch ausgeführt werden kann. Statt als Klartext „Ich suche danach“ zurückzugeben, könnte ein Agent zum Beispiel ein JSON-Objekt wie {"action": "WebSearch", "query": "latest sales figures"} ausgeben, das Ihr Code parst und ausführt. Dieses Muster, vergleichbar mit der Function-Calling-API von OpenAI oder JSON-basierten Ausgaben, macht das Verhalten von Agenten deutlich vorhersehbarer und leichter zu debuggen.
Faktor 2: Die Prompts gehören Ihnen. Behandeln Sie Prompts als vollwertigen Code, nicht als Einweg-Strings, die irgendwo in einem Framework vergraben sind. Horthy plädiert dafür, die volle Hoheit über jeden Prompt zu behalten, der ins Modell geht. Konkret sollten Teams ihre Prompts und Prompt-Vorlagen versionieren, sie leicht bearbeitbar machen und undurchsichtige „Prompt-Engineering“-Bibliotheken meiden, die Prompt-Details verstecken. Wenn der Prompt Ihnen „gehört“, können Sie Anweisungen feinjustieren, Leitplanken ergänzen und die Formatierung anpassen, während Ihr Verständnis wächst. Dieser Faktor ist eine Reaktion auf schwere Abstraktion: Statt dem magischen Prompt einer fremden Bibliothek zu vertrauen, schreiben und pflegen Sie genau die Anweisungen, die das LLM sieht. Der Vorteil ist feingranulares Debugging und Optimieren: Gibt der Agent eine schlechte Antwort, gehen Sie in den Prompt und passen ihn an wie ein Stück Code.
Faktor 3: Das Kontextfenster gehört Ihnen. In LLM-Anwendungen ist der Kontext das neue „Gedächtnis“, und ihn gut zu verwalten ist entscheidend. Dieses Prinzip (manche nennen es inzwischen „Context Engineering“) bedeutet, ausdrücklich zu steuern, welche Informationen bei jedem Schritt ins Kontextfenster des Modells gelangen. Statt ganze Transkripte oder Datenbanken in den Prompt zu kippen und zu hoffen, dass das Modell damit zurechtkommt, sollten Entwickler den Kontext gezielt gestalten: lange Verläufe zusammenfassen oder komprimieren, strukturierte Formate für Zwischendaten verwenden und nur das aufnehmen, was für die Aufgabe relevant ist. Indem Teams den Kontext als begrenzten Cache behandeln, haben sie 30 bis 60 Prozent an Token eingespart und die Genauigkeit des Modells verbessert. In der Praxis kann das heißen: eine laufende Zusammenfassung des Gesprächs führen, den Zustand kompakt kodieren (etwa als Schlüssel-Wert-Paare oder in domänenspezifischer Notation) oder Fakten genau dann aus einer Wissensbasis abrufen, wenn sie gebraucht werden. Es geht darum, das „Weltbild“ des Modells in jeder Runde bewusst zusammenzustellen, statt es Rauschen und veraltete Informationen ansammeln zu lassen.
Faktor 4: Tools sind nur strukturierte Ausgaben. Wenn ein LLM ein Tool „aufruft“, erzeugt es unter der Haube eigentlich nur ein Stück Text, das eine Aktion veranlasst. Horthy rät, das zu formalisieren: Definieren Sie Tools als strukturierte Ausgabeschemata und validieren Sie sie streng. Wenn Ihr Agent zum Beispiel eine API ansprechen oder eine SQL-Abfrage ausführen kann, beschreiben Sie das genaue JSON-Format oder die Code-Syntax, die er für diese Aktion erzeugen soll. Behandelt man die Tool-Nutzung als Erzeugung strukturierter Ausgaben, lassen sich fehlerhafte Anfragen (etwa ungültiges JSON oder unsinniges SQL) abfangen, bevor sie Schaden anrichten. Dieser Faktor überschneidet sich mit Faktor 1 und bekräftigt den Gedanken, dass jede LLM-Ausgabe, die eine Ausführung auslöst, einer Spezifikation folgen sollte. Viele Teams nutzen JSON-Schemata oder Funktionsdefinitionen und lassen das Modell die Parameter ausfüllen. Das macht das Verhalten des Agenten verlässlicher und erleichtert es außerdem, diese Tool-APIs im Lauf der Zeit weiterzuentwickeln, ohne das Modell zu verwirren.

Zustand und Kontrollfluss steuern

Faktor 5: Ausführungszustand und Geschäftszustand vereinen. In klassischer Software liegen Anwendungszustand (Nutzerdaten, Datenbankeinträge) und Workflow-Zustand (wo man sich in einem Prozess befindet) oft getrennt. Bei KI-Agenten schlägt Horthy vor, beides zu vereinen: Speichern Sie alle Interaktionen des Agenten als Teil Ihres zentralen Anwendungszustands, typischerweise als Event-Log. Jede Eingabe, jede Ausgabe und jeder Zwischenschritt des Agenten lässt sich in einem Append-only-Event-Stream festhalten, der an ein passendes Geschäftsobjekt gebunden ist (etwa ein Support-Ticket, eine Bestellnummer usw.). So steckt das „Gedächtnis“ des Agenten nicht nur im Kopf des LLM oder in einer temporären Variable, sondern in Ihrer Datenbank. Das bringt zwei Vorteile: Sie können vergangene Agenten-Sitzungen für Debugging oder Compliance erneut abspielen und prüfen (weil jede Entscheidung protokolliert ist), und Sie können sich nach Abstürzen erholen, indem Sie den letzten bekannten Zustand aus dem Log laden. Dieses Event-Sourcing-Muster ermöglicht auch horizontale Skalierung: Ein anderer Server kann dort weitermachen, wo der erste aufgehört hat, indem er das Zustands-Log liest. Der Agent wird damit zwischen den Schritten praktisch zustandslos (siehe Faktor 12).
Faktor 6: Starten, pausieren und fortsetzen über einfache APIs. Reale Prozesse sind oft keine einzige durchgehende Schleife, sie müssen unter Umständen auf externe Ereignisse oder menschliche Eingaben warten. Ein produktionsreifer Agent sollte deshalb Steuerungsmöglichkeiten bieten, um seinen Workflow programmatisch zu starten, anzuhalten und fortzusetzen. Horthy rät, die Agentenlogik so zu entwerfen, dass sie an klar definierten Checkpoints gestoppt und sicher wieder aufgenommen werden kann. Muss ein Agent zum Beispiel eine lang laufende Aufgabe erledigen oder auf eine menschliche Freigabe warten (Faktor 7), sollte er seinen Zustand speichern (gemäß Faktor 5), sich beenden und später von diesem Zustand aus weitermachen können. Umsetzen lässt sich das etwa über eine API oder Funktionsaufrufe zum Pausieren und Fortsetzen sowie über ein gespeichertes Resume-Token oder einen Zustands-Snapshot. Der praktische Nutzen ist groß: Sie können Human-in-the-Loop-Prüfungen einbauen, den Agenten asynchron orchestrieren (etwa über eine Job-Queue oder einen Scheduler) und verhindern, dass Arbeit verloren geht, wenn mittendrin etwas abstürzt. Behandeln Sie den Agenten im Grunde wie einen Prozess, den Sie steuern können, denn in Produktion werden Sie diese Kontrolle brauchen.
Faktor 7: Menschen über Tool-Aufrufe kontaktieren. Auch die besten KI-Agenten geraten in Situationen, in denen sie an einen Menschen übergeben sollten, sei es bei einer mehrdeutigen Entscheidung oder einer sicherheitskritischen Aktion. Statt das außerhalb des Agenten zu regeln, schlägt 12-Factor Agents vor, „einen Menschen fragen“ zu einer vollwertigen Aktion der KI zu machen. In der Praxis können Sie dafür ein spezielles Tool oder Ausgabeschema implementieren, das die Eskalation an einen Menschen abbildet. Der Agent könnte zum Beispiel {"action": "HumanApproval", "details": "…"} ausgeben, was Ihr System als Signal erkennt, einen Menschen einzubeziehen (per Benachrichtigung oder Prüfaufgabe). So strukturierte Übergaben an Menschen werden Teil des Event-Streams des Agenten und lassen sich wie jede andere Tool-Nutzung nachverfolgen und prüfen. Dieser Faktor stellt sicher, dass ein Agent, der an die Grenze seines Wissens oder seiner Sicherheit stößt, nicht stillschweigend scheitert oder etwas Leichtsinniges tut, sondern ausdrücklich um menschliche Hilfe bittet. Das Muster ist wichtig für die Zusammenarbeit von Mensch und KI: Der Gesamtablauf kann verlässlich weiterlaufen, mit menschlicher Anleitung dort, wo sie nötig ist.
Faktor 8: Der Kontrollfluss gehört Ihnen. Viele Agenten-Frameworks betreiben eine geschlossene Schleife, in der das LLM entscheidet, wann es aufhört oder wiederholt. Horthys Rat: Behandeln Sie die interne Schleife des Agenten nicht als Blackbox, sondern instrumentieren Sie sie und sichern Sie sie ab. Konkret sollten Entwickler den Kontrollfluss des Agenten im Code implementieren, mit klaren Bedingungen für Schleifen, Wiederholungen und Abbruch, statt sich darauf zu verlassen, dass sich das Modell selbst reguliert. Sie könnten zum Beispiel eine Höchstzahl an Iterationen festlegen oder mit einer Heuristik erkennen, wann der Agent bei einer Lösung „nicht konvergiert“ (etwa indem Sie verfolgen, ob er sich wiederholt, oder abnehmenden Ertrag bewerten). Wer die Schleife selbst in der Hand hat, kann aus dem Ruder laufendes Verhalten (Endlosschleifen) verhindern und in jedem Durchlauf Logging oder Metriken einfügen. Auch eigene Retry-Logik wird möglich: Erzeugt das Modell etwa einen ungültigen Tool-Aufruf, können Sie ihn abfangen (Faktor 4) und entscheiden, ob Sie dem Modell noch eine Chance geben oder auf einen Standardwert zurückfallen. Im Kern geht es bei Faktor 8 darum, die Steuerung des Ablaufs nicht komplett der KI zu überlassen. Sie entwerfen die äußere OODA-Schleife (observe, orient, decide, act) und behalten den Not-Aus-Schalter in der Hand, wie es jedes robuste verteilte System täte.

Agenten klein und zustandslos halten

Faktor 9: Fehler kompakt in den Kontext aufnehmen. Wenn ein Schritt des Agenten fehlschlägt, etwa weil ein Tool einen Fehler zurückgibt oder die Antwort des Modells falsch ist, lässt ihn der naive Ansatz entweder blind weiterlaufen oder bricht ab. Dieses Prinzip empfiehlt einen klügeren Mittelweg: Fehler zusammenfassen und für den nächsten Schritt in den Kontext des Modells zurückspielen. Anders gesagt: Der Agent darf im laufenden Betrieb aus seinen Fehlern „lernen“. Gibt ein API-Aufruf zum Beispiel einen 400-Fehler zurück, könnte der nächste Prompt des Agenten einen knappen Hinweis enthalten wie „Der vorherige Schritt ist fehlgeschlagen, weil die Abfrage fehlerhaft war.“ So kann das Modell seinen Plan anpassen oder um Klärung bitten, statt denselben ungültigen Aufruf zu wiederholen oder ohne Erkenntnis aufzugeben. Wer Fehler kompakt im Kontextfenster kodiert, bringt das Modell dazu, überflüssige Versuche zu vermeiden und sich womöglich selbst zu korrigieren. Das ähnelt einem menschlichen Programmierer, der eine Fehlermeldung liest und es beim nächsten Durchlauf anders macht. Der Faktor knüpft an robuste Fehlerbehandlung an: Statt endloser Wiederholungen oder fataler Abbrüche machen Sie aus Fehlern informativen Kontext und lassen die KI mit diesem Wissen einen neuen Versuch starten (und protokollieren diese Ereignisse gemäß Faktor 5 für die spätere Analyse).
Faktor 10: Kleine, fokussierte Agenten. Das vielleicht grundlegendste Umdenken besteht darin, die Lösung aus mehreren spezialisierten Agenten zusammenzusetzen statt aus einem Generalisten. Horthy und andere beobachteten, dass ein „einzelner großer Agent“, der einen komplexen Workflow von Anfang bis Ende abwickeln soll, tendenziell fragil ist. Bessere Ergebnisse bekommen Sie, wenn Sie das Problem in kleinere Teilaufgaben zerlegen und jeder einen eigenen Mini-Agenten oder LLM-Aufruf geben, der darauf spezialisiert ist. Statt eines KI-Agenten, der eine E-Mail liest, eine Datenbank abfragt und eine Antwort entwirft, könnten Sie zum Beispiel eine Komponente haben, die nur die wichtigsten Fakten aus der E-Mail extrahiert, eine zweite, die die Datenbankabfrage formuliert, und eine dritte, die mit diesen Ergebnissen die Antwort erzeugt. Jedes Teil ist einfacher und leichter zu optimieren. In der Praxis kann Faktor 10 bedeuten, mehrere LLM-Aufrufe oder Agenten-Instanzen über ein übergeordnetes Skript oder eine Workflow-Engine zu orchestrieren (nicht unähnlich Microservices in der klassischen Architektur). Als Vorteile werden höhere Zuverlässigkeit genannt (spezialisierte Agenten erreichen bei ihrer fokussierten Aufgabe über 90 Prozent Erfolg, während ein monolithischer Agent in mehr als 20 Prozent der Fälle scheitert), einfacheres Debugging, wenn etwas schiefgeht, und sogar Leistungsgewinne unter Last (kleinerer Kontext pro Agent = schnellere Inferenz). Berichte aus der Community stützen das: Ein CTO erzählte, dass sein Team einen komplexen Prozess in klare, deterministische Workflows mit LLM-“Assistenten“ an bestimmten Knoten zerlegt und damit Ergebnisse auf menschlichem Niveau erreicht habe, die „dicke, fette Agenten“ nicht schafften.

Eine komplexe Aufgabe auf mehrere spezialisierte Mikro-Agenten aufzuteilen, kann verlässlichere Ergebnisse liefern als ein einziger ausufernder Agent. Jeder kleine Agent übernimmt als Teil einer größeren Pipeline eine fokussierte Aufgabe (etwa Zusammenfassung, Klassifikation oder Berechnung), was das Gesamtsystem leichter zu debuggen und zu skalieren macht. In diesem Beispieldiagramm löst ein erstes Ereignis eine Abfolge zweckgebundener LLM-Agenten aus, statt dass ein monolithischer Agent alles zu erledigen versucht.
Faktor 11: Von überall auslösen, Nutzer überall erreichen. Klassische Agenten sind oft als Chatbots oder Anwendungen mit einer einzigen Oberfläche gebaut. Faktor 11 ermutigt Entwickler, die Agentenlogik von jeder einzelnen Oberfläche zu entkoppeln und sie aus jedem Kontext aufrufbar zu machen. In der Praxis heißt das: Die Kernfunktion Ihres Agenten sollte über eine API erreichbar sein, damit sie von einer Web-Oberfläche, einer mobilen App, einem geplanten Job, einem eingehenden Webhook oder jeder anderen Ereignisquelle ausgelöst werden kann. Ebenso sollte er über mehrere Kanäle antworten oder handeln können: nicht nur eine Chat-Antwort schicken, sondern bei Bedarf auch eine Datenbank aktualisieren, eine E-Mail senden oder in Slack posten. Die Idee ist, „die Nutzer dort abzuholen, wo sie sind“. Wenn Ihre Kunden über Text, Sprache, E-Mail usw. interagieren, sollte sich Ihr Agent in diese Kanäle einklinken, ohne dass Sie für jeden eine komplett eigene KI brauchen. Umsetzen lässt sich das etwa mit einer ereignisgesteuerten Architektur oder einer Middleware-Schicht, die verschiedene Eingabequellen in den Agenten leitet und seine Ausgaben passend weiterroutet. Wer Agenten unabhängig vom Auslöser entwirft, schafft Omnichannel-KI-Dienste und ein einheitliches Nutzungserlebnis über alle Plattformen. Der Faktor zielt auch auf Flexibilität: Der Agent wird zu einer wiederverwendbaren Komponente, die sich überall einsetzen lässt, wo Automatisierung oder Intelligenz gebraucht wird, statt ein Einzelstück-Bot zu sein, der nur auf Ihrer Website lebt.
Faktor 12: Machen Sie Ihren Agenten zum zustandslosen Reducer. Das letzte Prinzip greift ein Konzept aus der funktionalen Programmierung auf: Behandeln Sie den Agenten wie eine reine Funktion (Reducer), die einen Eingabezustand + Ereignis entgegennimmt und einen Ausgabezustand liefert, ohne dazwischen versteckten Zustand mitzuschleppen. Praktisch heißt das: Entwerfen Sie Ihren Agenten so, dass er in jeder Runde nur auf Basis des ausdrücklich übergebenen Kontexts handelt (Faktor 3) und ein explizites Ergebnis erzeugt, das sich dann speichern oder weiterreichen lässt. Alles, was der Agent aus früheren Schritten wissen muss, sollte über den bereitgestellten Kontext kommen (etwa aus dem Event-Log gemäß Faktor 5). Wenn Sie sich nicht auf internen, impliziten Zustand verlassen, erreichen Sie Zustandslosigkeit: Sie könnten mehrere Instanzen des Agenten hinter einem Load Balancer hochfahren oder sich nach einem Absturz durch erneutes Laden des Kontexts erholen, ohne Inkonsistenzen zu bekommen. Das macht das horizontale Skalieren deutlich einfacher und das Testen geradliniger (Sie können dem Agenten einen bestimmten Kontext geben und bei sonst gleichen Bedingungen ein deterministisches Ergebnis erwarten). Faktor 12 führt im Grunde mehrere frühere Faktoren (Kontext, Logging, kleine Einheiten) zu einer Philosophie zusammen, nach der sich ein LLM-Agent wie eine reine Funktion von Eingabe zu Ausgabe verhalten sollte. Zu 100 Prozent lässt sich das vielleicht nicht erreichen (LLMs haben durchaus verborgene Gewichte und Zufälligkeit), aber das System so zu behandeln, ist ein Leitbild, das Fehler und Überraschungen minimiert. Nicht zufällig spiegelt das die zustandslose, horizontal skalierbare Natur von 12-Factor-App-Diensten.

Reaktionen und Alternativen im Agenten-Ökosystem

Horthys 12-Factor Agents traf zeitlich und inhaltlich genau den richtigen Punkt. Der Start des Repositorys zog schnell Aufmerksamkeit auf sich, inzwischen sind es über 10.000 GitHub-Sterne, Tendenz steigend. Auf Hacker News löste das Konzept eine ausführliche Diskussion unter KI-Entwicklern aus, von denen viele zustimmend nickten und eigene Kriegsgeschichten im Kopf hatten. „Ich hatte nach ein paar Jahren mit diesem Zeug meine eigene Liste an Erkenntnissen“, schrieb ein Kommentator und stimmte zu, dass es entscheidend sei, die Planungsschleife auf unterer Ebene selbst in der Hand zu haben und mit Heuristiken zu erkennen, wann ein Agent feststeckt. Ein anderer Leser spottete, „verlässliche LLM-Anwendungen“ klinge auf den ersten Blick wie ein Oxymoron, ähnlich wie „Jumbo-Shrimps“, was die gesunde Skepsis in der Community widerspiegelt. Andere antworteten, Verlässlichkeit sei möglich, „sobald man [das LLM] richtig festnagelt und seine Erwartungen senkt“. Sie verglichen ein LLM mit einer „sich danebenbenehmenden Datenbank“, die passende Einschränkungen braucht (Schemata, Validierungen usw.), statt sie „mit Regex-artiger Intelligenz auf YOLO gehen“ zu lassen. Im Kern gestand die Runde ein, dass sich robuste KI-Agenten bauen lassen, aber nicht, indem man das Modell als unfehlbares Orakel behandelt. Das braucht Leitplanken und gutes altes Engineering.

Bemerkenswert ist, dass sich sogar die Autoren populärer Frameworks diese Lehren zu Herzen genommen haben. Das LangChain-Team etwa empfahl 12-Factor Agents als Lektüre und merkte an, dass viele von Horthys Punkten auf besseres „Context Engineering“ und mehr Kontrolle für Entwickler hinauslaufen. In einem Blogbeitrag stellte es LangGraph vor, ein neues Modul, das die Agenten von LangChain transparenter und besser steuerbar machen soll: Entwickler können ausdrücklich jeden Schritt, jedes Stück Kontext und jeden Tool-Aufruf selbst festlegen, statt das einer versteckten Abstraktion zu überlassen. Diese Wende passt zu Faktoren wie #2 (die eigenen Prompts in der Hand behalten) und #8 (die eigene Schleife in der Hand behalten) und deutet auf eine Annäherung an flexiblere, Framework-unabhängige Ansätze hin.

Unterdessen entstehen weiter alternative Agenten-Frameworks. Projekte wie smol-ai (inspiriert vom Ethos der „minimalen AGI“) versuchten, Agenten auf das Nötigste zu reduzieren, während sich andere wie Griptape oder Dust als „produktionsreife“ Werkzeuge zur Agenten-Orchestrierung vermarkteten. Horthys Erfahrung war jedoch, dass nur wenige davon tatsächlich in großem Maßstab im Einsatz waren. Viele Unternehmen bauten in aller Stille eigene Werkzeuge nach ähnlichen Prinzipien, statt einer Einheitsbibliothek zu vertrauen. Der Hype um vollständig autonome Agenten (beispielhaft dafür der Auto-GPT-Rausch des letzten Jahres) ist einer pragmatischeren Sicht gewichen: Ein LLM mit einem Sack voller Tools frei laufen zu lassen, endet in Produktion selten gut. Die Branche bewegt sich stattdessen in Richtung „KI-Copiloten“ und modularer KI-Dienste, die bestimmte Aufgaben unter enger Aufsicht erledigen. 12-Factor Agents hat diese Haltung auf den Punkt gebracht und ihr einen Namen gegeben.

Dabei ist 12-Factor Agents selbst keine starre Doktrin. Der Open-Source-Leitfaden auf GitHub entwickelt sich weiter (eine Version 1.1 mit Beiträgen aus der Community ist in Arbeit), und Entwickler ergänzen eigene Verfeinerungen. Manche schlugen zusätzliche „Faktoren“ vor, etwa die Identität und Rollen eines Agenten ausdrücklicher zu definieren oder im Entwurf eines Agenten deterministische von probabilistischen Fähigkeiten zu unterscheiden. Andere diskutieren, wie weit man die Jagd nach Verlässlichkeit treiben soll: Werden künftige KI-Modelle so viel besser, dass manche dieser Vorsichtsmaßnahmen überflüssig werden? Oder entstehen neue Abstraktionsschichten, die diese Muster in einfacher nutzbarer Form kapseln (so wie höhere Programmiersprachen Maschinencode kapseln)? Vorerst argumentieren Horthy und Gleichgesinnte, dass wir bei der Architektur „KI-nativer“ Software noch ganz am Anfang stehen. Eine großartige LLM-Anwendung zu bauen, heißt 2025 oft, das Modell an seine Grenzen zu treiben und es mit so viel schützendem Gerüst zu umgeben, wie für konsistente Ergebnisse nötig ist. In Horthys Worten: „Wirklich beeindruckende KI-Erlebnisse baut man nur, indem man etwas genau an der Grenze dessen findet, was das Modell kann, und das dann konsistent richtig hinbekommt.“ Das verlangt zwangsläufig sorgfältiges Engineering.

Fazit

Für Softwareentwickler und CTOs, die auf die Versprechen der KI schielen, kommt 12-Factor Agents als Realitätscheck zur rechten Zeit. Verlässliche LLM-Anwendungen zu entwickeln hängt demnach weniger an geheimer Prompt-Würze oder All-in-one-Frameworks als daran, solide Architekturprinzipien auf diese fremdartigen neuen Komponenten anzuwenden. Die Begeisterung für einen KI-Agenten, der „es im laufenden Betrieb herausfindet“, muss sich mit der ernüchternden Wahrheit vertragen, dass darunter weiterhin Software steckt, und Software braucht Struktur. Horthys Regelwerk schlägt im Grunde die Brücke zwischen moderner KI und klassischer Softwaretechnik und drängt Teams, ihre KI-Agenten wie jeden anderen kritischen Dienst zu behandeln: Zuständigkeiten abgrenzen, klare Schnittstellen geben, Zustandsübergänge verwalten, das Verhalten überwachen und das Unerwartete einplanen.

Ob die „12-Factors“ so ikonisch werden wie ihr Heroku-Vorbild oder nicht, sie prägen schon jetzt, wie Praktiker über KI-Systeme reden. Wir sehen eine Bewegung von den Ad-hoc-Agentenskripten des letzten Jahres hin zu robusten KI-Architekturen, die Konzepte aus Microservices, funktionaler Programmierung und DevOps übernehmen. Mit der Zeit werden Bibliotheken auf höherer Ebene diese Ideen wohl aufnehmen, oder es entstehen neue Entwicklungsmuster (sogar Programmiersprachen) speziell für KI-Orchestrierung. Bis dahin bietet der 12-Factor-Agents-Leitfaden einen Bauplan, den Entwickler schon heute anwenden können, mit welchen Werkzeugen auch immer. Die Botschaft ist klar: LLMs liefern das Hirn, aber das Gerüst müssen wir selbst bauen. Oder wie das Mantra der Community lautet: „LLMs liefern Intelligenz. Die 12 Faktoren liefern Verlässlichkeit.“

Aus dem Englischen übersetzt: zum Originalbeitrag