Als Anthropic Ende 2024 Building Effective Agents veröffentlichte, tat sie etwas für die Branche Seltenes: Sie gab Ingenieuren ein gemeinsames Vokabular. Anstatt eines weiteren Manifests über künstliche allgemeine Intelligenz bot der Leitfaden sechs klare Muster für die Strukturierung von LLM-Systemen. Eineinhalb Jahre später, im Jahr 2026, sieht die Landschaft radikal anders aus. Das Model Context Protocol ist zu einem universellen Standard geworden. Claude hat neue Fähigkeiten gewonnen. Die meisten Unternehmen betreiben mittlerweile mindestens einen Agenten in der Produktion. Vor diesem Hintergrund stellt sich die berechtigte Frage, ob diese sechs Muster noch von Bedeutung sind oder ob sie im Archiv neben den Modellgewichten des letzten Jahres gelandet sind.

Um das herauszufinden, habe ich alle sechs Muster in einem Neben-Repository gegen ein lokales Modell getestet. Die Antwort lautet: Ja. Sie halten immer noch stand. Aber nicht, weil sie unumstößliche Gesetze sind. Sie halten stand, weil die letzten achtzehn Monate an Praxiserfahrung die Kernlogik des Frameworks validiert haben.

Was uns das Framework tatsächlich gebracht hat

Die sechs Muster sind es wert, sich genau zu merken: Prompt Chaining, Routing, Parallelization, Evaluator-Optimizer, Orchestrator-Workers und Autonomous Agents. Letzteres ist im Wesentlichen eine Schleife, in der das Modell plant, handelt, beobachtet und sich wiederholt, bis eine bestimmte Bedingung erfüllt ist.

Schon bevor der Leitfaden erschien, verknüpften viele Ingenieure Prompts (Prompt Chaining) oder delegierten Aufgaben an Worker-Threads. Was Anthropic lieferte, war eine Taxonomie. Was für die eine Person ein „Agent“ war, war für eine andere ein „Workflow“ und für eine dritte ein „Multi-Step Tool Call“. Der Leitfaden sortierte das Chaos in Kategorien mit klaren Grenzen. Das ermöglichte es, über Kompromisse (Trade-offs) zu diskutieren, ohne aneinander vorbeizureden. In einem Feld, das in Hype versinkt, ist eine präzise Sprache eine Art Infrastruktur.

Die Branche hat darauf aufgebaut, nicht darum herum

Bis 2026 sind diese Kategorien fest in die Art und Weise integriert, wie Teams Systeme entwerfen. Anthropic lehrt sie immer noch in seinen Academy-Kursen. Forschungsarbeiten und Engineering-Blogs verwenden nach wie vor dieselben sechs Kategorien, um neue Architekturen zu beschreiben. Diese Art von Langlebigkeit ist ungewöhnlich für eine Disziplin, die ihren Stack jedes Quartal erneuert.

Der Grund ist simpel. Die Branche hat das Framework nicht ersetzt, sondern darauf aufgebaut. Neue Werkzeuge wie MCP und die neueren Agent Skills-Standards fungieren als „Plumbing“ (Infrastruktur). Sie erleichtern es, ein Modell mit einer Datenbank zu verbinden, ein Tool bereitzustellen oder den Zustand (State) zu verwalten. Aber sie ändern nicht die Logik der Frage, wann man einen Router anstelle eines Orchestrators verwendet. Ein besseres Rohr schreibt keinen neuen Grundriss.

Produktionsdaten aus dem Jahr 2026 bestätigen dies. Das am häufigsten eingesetzte Deployment-Muster ist nach wie vor ein einzelner Tool-Use-Aufruf in Kombination mit einer menschlichen Überprüfung. Das zweithäufigste ist ein mehrstufiger Workflow mit genau einer Übergabe an einen Menschen. Beide sind direkte Nachfahren von Prompt Chaining und Routing. Vollautonome Schleifen bleiben in Live-Systemen die Ausnahme und nicht die Regel.

Zurückhaltung hat den Markt gewonnen

Der beste Rat des ursprünglichen Leitfadens war auch der Rat, der 2024 am häufigsten ignoriert wurde: Verwenden Sie das einfachste Muster, das funktioniert. Setzen Sie keinen vollautonomen Agenten ein, wenn ein fest codierter Pfad die Aufgabe erledigen kann.

Der Markt hat dies endlich verinnerlicht. Die meisten Agenten-Piloten scheitern immer noch, und zwar aus demselben vorhersehbaren Grund. Teams stapeln Abstraktion auf Abstraktion, bis niemand mehr die Entscheidungsgrenzen nachvollziehen kann. Wenn das System driftet, wird das Debugging zur Archäologie. Die Unternehmen, die in der Produktion erfolgreich sind, sind diejenigen, die Zurückhaltung bewiesen haben. Sie haben standardmäßig auf Single-Turn Tool Use gesetzt. Sie haben erst dann eine Routing-Ebene hinzugefügt, nachdem sich der einzelne Prompt als inkonsistent erwiesen hatte. Sie betrachteten Autonomie als eine Haftung, die gerechtfertigt werden muss, und nicht als ein Feature, das gefeiert werden sollte.

Dies ist kein Argument gegen Ehrgeiz. Es ist ein Argument für Komposition. Die Muster funktionieren am besten, wenn man sie bewusst kombiniert, anstatt reflexartig nach der komplexesten Option auf der Speisekarte zu greifen.

Wo die Nähte anfangen zu lecken

Das Framework ist kein Allheilmittel. Es gibt harte Grenzen, die auftreten, sobald man die Prototyping-Phase verlässt.

For high-frequency, low-cost tasks, deterministic code still wins. An LLM should not be normalizing a CSV column when pandas can do it in milliseconds without hallucinating. Avoid autonomous loops if you cannot define a crisp evaluation goal. Without a clear stopping condition, the model will iterate until it invents a reason to stop. For high-stakes decisions that require external grounding, do not rely solely on the model’s internal knowledge. And watch for bottlenecks in data retrieval. Any pattern that depends on vector search or external APIs can choke if your database is slow or your context window is clogged with irrelevant chunks.

These are not hypothetical edge cases. They are the constraints that separate a working demo from a system that survives the weekend.

A Rigid Check and a Wrong Failure

I learned the practical value of this framework while building my test repository. I was implementing the Evaluator-Optimizer pattern. My evaluator started as a hardcoded regex that scanned the model’s output for specific keywords. The model returned a correct, well-reasoned answer that happened to use synonyms instead of the exact words I was hunting. The evaluator flagged it as a failure.

The model was right. My check was too rigid.

Fixing it required more than expanding a word list. I switched the evaluator itself to an LLM-based judgment. That cost extra tokens and a few more milliseconds, but it restored the evaluation to the right level of abstraction. The pattern itself was sound. I had simply chosen the wrong implementation for the task. That is exactly the kind of mistake the framework is meant to prevent. Some evaluations need code. Others need a model. Knowing which is which is the whole point.

How to Use Them Now

Treat these six patterns as a starting point, not absolute law. Begin with a single prompt. If quality is inconsistent across input types, add a routing layer to send different requests to specialized prompts. If you need multiple independent perspectives before making a call, use Parallelization. If the task is large and divisible, try Orchestrator-Workers. Only reach for the full autonomous loop when the problem space is too wide to pre-map and when you have a reliable