Der agent lief in der Demo. Er beantwortete Fragen, rief Tools auf, produzierte strukturierten Output. Zwei Wochen in der Produktion: Er akkumulierte Kontext, bis die Antworten degradierten, rief Tools auf, ohne Inputs zu validieren, verlor den Zustand zwischen Runs, und hatte keinen Mechanismus zur Eskalation, wenn er auf etwas außerhalb seines Trainings stieß. Die Post-mortem-Analyse identifizierte als Grundursache “LLM-Limitierungen.” Die tatsächliche Grundursache: Das Team baute den agent, indem es einem Modell Zugang zu Tools gab, und nannte das ein System.
Es war kein System. Es war ein LLM mit API-Keys.
Der Kategorien-Fehler, der Agent-Versagen verursacht
Wenn ein Enterprise-Team einen agent baut, indem es ein Modell mit Tools verbindet und es auffordert, den Rest herauszufinden, haben sie das System-Design an das Modell delegiert. Das Modell entscheidet, welchen Kontext es beibehält, wann es welches Tool aufruft, was Erfolg ausmacht und wann es aufhört. Es trifft diese Entscheidungen inkonsistent, weil diese Entscheidungen deterministische Regeln erfordern, kein Language-Modeling.
Das 12-Factor-Agents-Framework, entwickelt von Dex Horthy bei HumanLayer, nennt das den Kategorien-Fehler: den LLM als das System zu behandeln statt als eine Komponente in einem System. Die Neuformulierung: Das Modell generiert Tokens (und nichts anderes). Deterministischer Code führt Tools aus, validiert Zustände, verwaltet Kontext, persistiert Ergebnisse und entscheidet, wann zu pausieren oder zu eskalieren ist.
Diese Neuformulierung verändert das, was Sie bauen. Sie verändert auch, wie Sie es debuggen. Wenn ein agent versagt, lautet die Frage nicht mehr “Was hat das Modell falsch gemacht?” Die Frage ist “Welche Komponente hat versagt, und welcher Software-Test hätte es aufgefangen?”
Das Kernprinzip: Besitzen Sie den Loop
Jeder agent ist ein Loop: beobachten, denken, handeln. Beobachten bedeutet Kontext lesen, einschließlich aktuellem Zustand, vorherigen Tool-Ergebnissen, relevantem Gedächtnis und allem anderen, was das Modell zum Urteilen braucht. Denken bedeutet die nächste Aktion angesichts des Ziels und des beobachteten Zustands planen. Handeln bedeutet die Aktion ausführen, ob ein Tool-Aufruf, ein Datei-Schreiben, eine API-Anfrage oder ein Output.
Den Loop besitzen bedeutet, jeden Teil dieses Zyklus explizit und durch Software kontrolliert zu machen, nicht implizit und an das Modell delegiert.
Besitzen Sie, was in das Beobachtungsfenster eintritt. Das Modell urteilt über das, was im Kontextfenster ist. Kontextfensterinhalte sollten durch deterministischen Code zusammengestellt werden, der genau das lädt, was dieser Schritt erfordert. Nicht “hier ist alles, Modell, finde heraus, was wichtig ist.” Framework-Magie, die Gedächtnis, Gesprächshistorie und Tool-Ergebnisse implizit injiziert, produziert Kontextfenster, die in der Produktion unvorhersehbar und beim Degradieren des Modells unmöglich zu debuggen sind.
Besitzen Sie die Struktur des Denkschritts. Chain-of-Thought, Scratchpad-Reasoning, strukturierte Output-Schemas und Output-Validierung sind alles Mechanismen, um den Denkschritt inspizierbare, testbare Outputs produzieren zu lassen. Ein Modell, das unstrukturierten Text schreibt, bevor es handelt, ist schwerer zu validieren als ein Modell, das ein strukturiertes Entscheidungsobjekt produziert.
Besitzen Sie die Einschränkungen für Aktionen. Jedem Tool-Aufruf sollte eine Schema-Validierung vorangehen. Jeder Aktion mit Konsequenzen sollte eine Reversibilitätsklassifizierung vorangehen. Einige Aktionen sollten menschliche Genehmigung vor der Ausführung erfordern. Das sind Software-Komponenten, keine Modell-Verhaltensweisen.
Für Enterprise: Den Loop besitzen bedeutet auch den Audit-Trail besitzen. Welches Kontextfenster welche Entscheidung produzierte, in welchem Schritt, in welchem Run. Das ist eine Compliance-Anforderung in regulierten Branchen, kein Logging-Komfort.
Die nützlichsten Faktoren für die Produktion
Das vollständige 12-Factor-Framework ist im Quellmaterial verfügbar. Die Faktoren, die die in Enterprise-Deployments beobachteten Fehler-Modi am direktesten verhindern:
Prompts Token für Token besitzen. Wissen, was genau in jedem Schritt im Kontextfenster ist. Keine implizite Injektion. Wenn ein Framework Gedächtnis, Historien oder Tool-Ergebnisse ohne explizite Anweisung zum Kontext hinzufügt, ist das ein Produktionsrisiko. “Das Framework verwaltet Kontext” ist ein Satz, der Besorgnis, nicht Beruhigung, produzieren sollte.
Kontext explizit zusammenstellen. Nur das laden, was für diesen Schritt benötigt wird. Ein Rechercheschritt benötigt Web-Such-Ergebnisse und eine Zielaussage. Er benötigt nicht die vollständige Gesprächshistorie, das Benutzerprofil und den Inhalt von drei anderen Dokumenten. Kontext-Bloat verschlechtert Qualität und erhöht Kosten. Das Kontextfenster ist eine Ressource, kein Notizblock für alles, was relevant sein könnte.
Tools als typisierte Schemas plus deterministischen Code behandeln. Eingabe- und Ausgabe-Schemas für jedes Tool definieren. Inputs vor der Ausführung validieren. Tools unabhängig vom agent loop testen. Ein Tool, das in eine Datenbank schreibt, sollte ohne Ausführen des gesamten agent testbar sein. Wenn das Tool nicht unabhängig getestet werden kann, ist es kein Tool. Es ist undifferenzierter Code mit einer API.
Ausführungszustand von Geschäftszustand trennen. Der Fortschritt des agent durch Schritte (in welchem Schritt er sich befindet, welche Tools er aufgerufen hat, welche Outputs er produziert hat) ist Ausführungszustand. Das modifizierte Geschäftsobjekt (eine Bestellung, ein Kundendatensatz, ein Compliance-Befund) ist Geschäftszustand. Diese leben an verschiedenen Orten. Sie zu vermischen macht die Zustandswiederherstellung nach Fehlern komplex und fehleranfällig.
Agents klein halten. Drei bis zehn Schritte mit klaren Eintrittsbedingungen und klaren Austrittsbedingungen. Agents mit 30+ Schritten und offenen Schleifen sind Debugging-Albträume. Wenn die Aufgabe mehr als zehn Schritte erfordert, ist sie fast immer in zwei oder drei kleinere agents mit einem Handoff-Protokoll zerlegbar.
Fehler vor der Reinjektion zusammenfassen. Wenn ein Tool-Aufruf fehlschlägt, verbraucht der rohe Exception-Trace Tokens und verwirrt Modelle häufig. Den Fehler komprimieren: “Tool X schlug fehl weil Y; die letzten drei Versuche produzierten Z.” Dem Modell strukturierte Informationen über Fehler geben, keine Wand aus Stack-Trace.
Menschliche Genehmigung als System-Komponente. Für hochriskante oder irreversible Aktionen ist menschliche Genehmigung kein Ausnahme-Pfad, der hinzugefügt wird, wenn etwas schiefläuft. Es ist ein entworfener Schritt im Workflow, mit einer definierten Genehmigungsschnittstelle, einer definierten Timeout-Richtlinie und einem definierten Eskalationspfad. Vor der ersten Agent-Aktion bauen, die Produktionsdaten berührt.
MCP als governte Tool-Infrastruktur
Model Context Protocol (MCP) ist der Standard für das Exponieren von Tools an agents als governte, versionierte, auditierbare Konnektoren. MCP definiert, wie ein agent Tools entdeckt, aufruft und Ergebnisse erhält, mit Authentifizierung, Schema-Validierung und Audit-Logging eingebaut in die Protokollschicht.
Stand Dezember 2025 wurde MCP der Agentic AI Foundation unter der Linux Foundation gespendet, jetzt co-goverened von Anthropic, OpenAI, Google, Microsoft und AWS. Über 10.000 MCP-Server sind aktiv, mit 97 Millionen monatlichen SDK-Downloads. MCP ist der de-facto-Standard für agent Tool-Konnektivität geworden, keine anbieterspezifische Lösung.
Für Enterprise: MCP verwandelt jedes Tool in eine governte Schnittstelle mit definiertem Scope, Authentifizierung, Rate-Limiting und einem Audit-Log für jeden Aufruf. Statt dass jeder agent direkte API-Aufrufe mit seiner eigenen Auth-Verwaltung und seiner eigenen Fehlerbehandlung macht, bietet MCP eine gemeinsame Infrastrukturschicht. Berechtigungen werden auf der MCP-Schicht verwaltet, nicht per agent repliziert.
Das direkt zu nennende Risiko: MCP ohne Governance ist eine gut beschriftete Angriffsfläche. Jeder MCP-Server, der eine Verbindung zu Produktionssystemen herstellt, benötigt explizites Whitelisting, Authentifizierung und Audit-Logging. Die im April 2026 entdeckte RCE-Schwachstellenklasse im MCP-Protokolldesign bestätigte, dass MCP-Server, wie jede Software-Komponente, Sicherheitsüberprüfung und Patching erfordern. Das Vorhandensein eines Standards ersetzt keine Sicherheitspraktiken.
LangGraph für Enterprise-Agent-Orchestrierung
Für agents, die State-Management, Branching, human-in-the-loop-Schritte und parallele Ausführung erfordern, bietet LangGraph einen expliziten State-Graphen, bei dem jeder State-Übergang sichtbar, pausierbar und fortsetzbar ist.
Die für Enterprise relevante architektonische Unterscheidung: LangGraph ist stateful. Der Ausführungszustand des agent persistiert zwischen Schritten. Wenn ein agent für menschliche Genehmigung pausiert, wird der Zustand bewahrt. Wenn ein agent mitten in der Ausführung versagt, kann der Zustand inspiziert und fortgesetzt werden. Das ist nicht das Standardverhalten der meisten agent Frameworks.
Produktionsadoption umfasst Deployments bei Cisco, Uber, LinkedIn und JPMorgan im Jahr 2026. Die Plattform ist nicht experimentell.
LangSmith, die zugehörige Observability-Plattform, trackt jeden Schritt der agent Ausführung: was im Kontextfenster war, welche Tools aufgerufen wurden, was sie zurückgaben und wie lange jeder Schritt dauerte. Für Enterprise-Deployments, bei denen das Erklären von Agent-Verhalten gegenüber einem Compliance-Team eine Anforderung ist, bietet LangSmith den Trace. Langfuse ist die selbst-gehostete Alternative für Datenresidenz-sensible Umgebungen.
Wann ein agent nicht verwendet werden sollte
Die meisten Aufgaben, die als agent Workflows vorgeschlagen werden, werden besser durch deterministische Automatisierung oder einen einzelnen LLM-Aufruf bedient.
Ein agent ist angemessen, wenn: Die Aufgabe mehrere heterogene Tool-Aufrufe erfordert, bei denen die Sequenz nicht im Voraus festgelegt ist, Zwischenergebnisse darüber informieren, welche Tools als nächste aufgerufen werden, und der Raum möglicher Pfade durch die Aufgabe vor der Ausführung nicht aufzählbar ist.
Ein agent ist falsch, wenn: Die Aufgabe einem festen Verfahren folgt, die Tools immer in derselben Reihenfolge aufgerufen werden, und jede Ausführung denselben Pfad nimmt. Das ist eine Workflow-Automatisierung. Zapier, n8n oder Trigger.dev erledigen das günstiger und zuverlässiger als ein agent. Das Modell fügt Kosten und Nicht-Determinismus ohne Hinzufügung von Intelligenz hinzu.
Die Diagnosefrage des 12-Factor-Frameworks, angewendet als Pre-Build-Gate: Erfordert diese Aufgabe Language-Understanding an Entscheidungspunkten, speziell um zu entscheiden, welche Aktion als nächste zu unternehmen ist? Oder erfordert es nur Automatisierung einer festen Sequenz?
Wenn die ehrliche Antwort Automatisierung ist, Automatisierung bauen. Das agent Framing macht es komplexer zu debuggen, teurer auszuführen und schwieriger zu erklären, wenn etwas schiefläuft.
Multi-agent Architekturen wenden dieselbe Logik eine Ebene höher an: Mehr agents ist nicht mehr Intelligenz. Die Entscheidung liegt darin, ob die Aufgabenstruktur es tatsächlich erfordert.
Für Enterprise-Teams, die bewerten, wo agents echten Wert schaffen versus wo sie Komplexität ohne Rendite hinzufügen, kartiert der AI Opportunity Sprint die Entscheidung.