ETCLOVG: Die Sieben-Schichten-Taxonomie für Agenten-Frameworks, abgebildet auf eine Produktions-Runtime

Die Zuverlässigkeit von Agenten ist eine Eigenschaft sowohl des Modells als auch des Systems, das es umgibt. Eine Studie aus dem Jahr 2026 von Forschern der Carnegie Mellon, Yale, Amazon und anderen Institutionen schlägt ETCLOVG – Execution, Tooling, Context, Lifecycle, Observability, Verification und Governance – als Taxonomie für dieses umgebende System, den sogenannten Agent-Harness, vor.

Die Autoren ordnen mehr als 170 Open-Source-Projekte diesen sieben Schichten zu und identifizieren sowohl ausgereifte Bereiche als auch operative Lücken. Dieser Beitrag fasst die Taxonomie zusammen und bildet sie auf das Agent-Harness von TrueFoundry ab – wobei native Runtime-Funktionen von angrenzenden Mustern und Integrationen unterschieden werden.

Priyanka, eine Head of Platform, hatte ein Zuverlässigkeitsproblem, für das sie keinen Namen fand. Ihre Teams betrieben fünf Produktions-Agenten, und wenn einer davon nicht wie gewünscht funktionierte, gab es bei den Post-Mortem-Analysen nie Einigkeit darüber, was behoben werden musste. Einer schob es auf das Modell und forderte ein Upgrade. Einer schrieb den Prompt um. Einer fügte einen Retry-Mechanismus hinzu. Einer wollte eine Sandbox. Jeder Lösungsansatz war plausibel, jeder adressierte eine andere Schicht, und keiner bot ein gemeinsames Vokabular, um zu benennen, welche Schicht tatsächlich versagt hatte – also drehten sich die Meetings im Kreis. Was Priyanka brauchte, war kein besseres Modell oder eine lautere Meinung; es war eine Landkarte: eine Möglichkeit, auf einen Agenten zu zeigen und zu sagen: „Dieser Fehler liegt im Lifecycle, nicht im Modell“ oder „Wir haben überhaupt keine Verification-Schicht.“ ETCLOVG ist diese Landkarte, und dieser Beitrag ist der Wegweiser durch sie – zuerst die Taxonomie, wie die Autoren sie entwickelt haben, dann jede Schicht im Kontext einer Produktions-Runtime, wobei zwischen nativen Funktionen und angrenzenden Workflows sowie Integrationen unterschieden wird, unabhängig davon, ob diese explizit so benannt werden oder nicht.

1. Warum es überhaupt eine Harness-Taxonomie gibt

Die zentrale These der Studie ist eine Abwertung der Modelle zugunsten der Infrastruktur: Der schnelle Einsatz von LLM-Agenten hat gezeigt, dass die Zuverlässigkeit der Ausführung weniger vom Basismodell abhängt als von dem Harness, das es umschließt. Die Belege dafür sind teilweise historischer Natur. Die ReAct-Ära von 2022–23 umschloss eine einzelne Modellschleife mit einer While-Schleife, einem Prompt-Template und einer kleinen Tool-Dispatch-Tabelle; AutoGPT und BabyAGI legten dann die Fehlerquellen dieses dünnen Wrappers offen – unkontrollierte Ausführung, Kontext-Überlastung, Zustandsverlust, unüberwachte Seiteneffekte – als Infrastruktur -Probleme statt als Prompt-Probleme. Die Jahre seitdem waren für das Fachgebiet ein langsamer Aufbau der fehlenden Infrastruktur, die erst kürzlich benannt wurde.

Diese Benennung ist die Drei-Phasen-Struktur der Studie, die das Harness-Engineering präzise verortet. Prompt Engineering (2022–24): Der Hebel ist der Eingabetext, optimiert für einen einzelnen Aufruf. Context Engineering (2025): Die Frage verschiebt sich zu „Was sollte das Modell bei jedem Schritt sehen?“ – Retrieval, Komprimierung, Ranking von Tool-Ergebnissen, Fenster-Sättigung. Harness Engineering (2026–): Da Modelle leistungsfähig genug für langlebige Aufgaben werden, weitet sich der Fokus auf den gesamten Infrastruktur-Wrapper aus. Jede Phase umfasst die vorherige – Harness beinhaltet Context, Context beinhaltet Prompt – und sie überlappen sich, anstatt sich zu ersetzen. ETCLOVG gibt dieser dritten Phase die architektonischen Grenzen, die die ersten beiden nie benötigten.

2. ETCLOVG, Schicht für Schicht

Die Taxonomie unterteilt sich in einen strukturellen Kern und eine Steuerungsebene. E, T, C und L sind die strukturellen Säulen – sie lassen einen Agenten laufen. O, V und G bilden die Steuerungsebene – sie machen einen laufenden Agenten beobachtbar, bewertbar und sicher. Der bemerkenswerte Schritt der Studie ist die Aufwertung von Observability und Governance zu eigenständigen Schichten, anstatt sie in Lifecycle-Hooks zu integrieren, mit der Begründung, dass jede in der Produktion über ein eigenes Tooling-Ökosystem verfügt und von einem anderen Team verantwortet wird. Hier sind die sieben Schichten, paraphrasiert nach den Definitionen der Studie.

E – Execution Environment (Ausführungsumgebung). Wo der Code und die Aktionen des Agenten tatsächlich ausgeführt werden und was sie begrenzt: verwaltete Sandboxes, MicroVMs, auf Code spezialisierte Runtimes, Computer-Use- und Browser-Umgebungen, Berechtigungsmodelle auf Betriebssystemebene. Dies ist die Schicht für den Schadensradius – was ein Agent berühren kann, wenn er einen Befehl ausführt.

T – Tool Interface and Protocol (Tool-Schnittstelle und Protokoll). Wie externe Funktionen beschrieben, entdeckt und aufgerufen werden: Protokollstandards (MCP, A2A), Tool-Beschreibung und -Auswahl, Tool-gestütztes Training, Sitzungsmanagement. Das Modell kennt Tools nur über diese Schicht.

C – Context and Memory Management (Kontext- und Speichermanagement). Was das Modell über kurzfristige, sitzungsbezogene und dauerhafte Horizonte hinweg sehen kann: Techniken für den Langzeitkontext und Maßnahmen gegen Kontext-Drift. Das Thema der vorangegangenen Entwicklungsphase, jetzt eine von vier Säulen.

L — Lifecycle und Orchestrierung. Der Kontrollfluss, der Zustände liest und schreibt – von der inneren Schleife eines einzelnen Agenten über Multi-Agenten-Muster bis hin zu vollständigen Pipelines von der Problemstellung bis zum Pull Request. Hier findet die eigentliche Ausführung statt.

O — Observability und Operations. Traces, Kosten, Fehler, Zuverlässigkeitssignale – Tracing-Plattformen, agentenspezifische Ops-Tools, Kostenverfolgung, vereinheitlichte Observability. Die Übersicht der Open-Source-Landschaft zeigt, dass diese Ebene im öffentlichen Code vergleichsweise dünn besetzt ist.

V — Verifizierung und Evaluierung. Aufgaben und Traces in Evaluierung, Fehlerzuordnung und Regressionsfeedback umwandeln: Benchmark-Grundlagen, kontrollierte Ausführung, mehrstufige Beurteilung, Evaluierungsschleifen zur Laufzeit. Der Unterschied zwischen „es lief“ und „es war korrekt“.

G — Governance und Sicherheit. Einschränkungen auf Modell-, System- und Organisationsebene: Berechtigungsmodelle, Lifecycle-Hooks, Härtung von Komponenten, deklarative Konstitutionen, Audit-Infrastruktur. Auch hier ist der Open-Source-Bereich laut der Übersicht noch schwach aufgestellt und solche Funktionen finden sich „häufiger in kommerziellen Plattformen“.

‍

‍