Warum die meisten KI-Agenten weit unter ihrem Potenzial laufen

Ob KI-Tools bescheidene oder substanzielle Ergebnisse liefern, hängt von der Architektur ab, die das Modell umhüllt. Steve Yegge stellte Anfang 2026 fest, dass Entwickler mit KI-Coding-Agenten auf geeigneten Aufgaben spürbare Produktivitätssteigerungen erzielen. Die gemeldeten Zahlen variieren stark je nach Methodik und Aufgabentyp. Gleiche Modelle, gleiche Grundintelligenz. Die entscheidende Variable ist die Struktur.

In einer einzigen Woche im April 2026 veröffentlichten fünf unabhängige Entwickler Frameworks zur Agenten-Architektur. Garry Tan (Y Combinator), Andrej Karpathy, Viv Trivedy, Daniel Miessler und ein Community-Repository mit 19.700 GitHub-Sternen kamen alle zur selben Kernthese: Intelligenz gehört in portable Markdown-Dateien, die Orchestrierungs-Infrastruktur bleibt so schlank wie möglich, das Modell übernimmt das Reasoning. Dieser Artikel schlüsselt auf, worin sie übereinstimmen, wo sie sich unterscheiden, und was das für alle bedeutet, die mit KI entwickeln.

Die Kernaussagen im Überblick

• Intelligenz gehört in Markdown-Skill-Dateien, nicht in Framework-Code. Skills sind portabel, versionierbar und verbessern sich automatisch, wenn das Modell besser wird.
• Das Harness sollte genau vier Dinge tun, nicht mehr. Modell in einer Schleife ausführen, Dateien lesen und schreiben, Kontext verwalten, Sicherheit durchsetzen. Jedes Feature darüber hinaus frisst Kontext und verlangsamt das Reasoning.
• Fünf Entwickler veröffentlichten dieselbe These innerhalb von drei Tagen (12. bis 15. April 2026). Garry Tan, Andrej Karpathy, Viv Trivedy, Daniel Miessler und ein Community-Repo mit 19.700 Sternen. Konvergenz aus unabhängigen Quellen ist ein starkes Signal dafür, dass ein Architekturmuster trägt.
• LangChain sieht das anders und hat Benchmarks als Beweis. Harrison Chase argumentiert, das Harness sei das Produkt. Die Antwort hängt möglicherweise davon ab, ob Consumer-Tools oder Enterprise-Pipelines gebaut werden.
• Prescriptive Instructions verfallen. Kontext nicht. Jedes Schritt-für-Schritt-Rezept für eine KI verliert mit dem nächsten Modell-Release seinen Wert. Kontext über Identität und Ziele kumuliert sich.

Die Architektur ist kompakt

Öffentliche Diskussionen über produktive Agenten-Runtimes konzentrieren sich zunehmend auf eine kompakte Architektur: Modell-Loop, Tools, Kontext-Management und Sicherheitskontrollen. Garry Tan beschrieb dieses Muster als Produktivitätstreiber, den er seit Monaten bei Y Combinator lehrte: Der Produktivitätsunterschied entsteht durch das, was das Modell umhüllt.

Tan destillierte die Architektur in drei Schichten:

Das Prinzip ist klar gerichtet: Intelligenz nach oben in die Skills, Ausführung nach unten in deterministische Tools, das Harness so schlank wie möglich. 90 Prozent des Werts liegt in der Skill-Schicht. Das Harness ist ein Dirigent, der Dateien liest. Es besitzt sie nicht.

Tans eigene Erfahrung belegt das anschaulich. Seine persönliche CLAUDE.md begann mit 20.000 Zeilen: jede Eigenheit, jede Konvention, jede Lektion dokumentiert. Das Ergebnis: Die Aufmerksamkeit von Claude Code nahm messbar ab. Das Modell bat ihn buchstäblich, zu kürzen. Seine Lösung waren 200 Zeilen Verweise auf Dokumente, die bei Bedarf nachgeladen werden. Die vollen 20.000 Zeilen Wissen existieren weiterhin, laden aber nur dann, wenn sie relevant sind, statt bei jedem Turn das Kontextfenster zu belasten.

Wer KI-gestützte Tools oder Workflows für sein Unternehmen aufbaut, für den entscheidet die richtige Architektur von Anfang an darüber, ob am Ende ein beeindruckender Demo oder ein produktives Live-System steht.

Fünf Konzepte, die leistungsstarke KI-Builds unterscheiden

Die Architektur stützt sich auf fünf Konzepte. Fehlt eines davon, bleibt das System hinter seinen Möglichkeiten.

1. Skill-Dateien

Ein Skill ist ein wiederverwendbares Markdown-Dokument, das dem Modell den Ablauf für eine Aufgabenkategorie beibringt. Der Nutzer liefert die konkrete Aufgabe, der Skill liefert das Verfahren. Das funktioniert wie ein Methodenaufruf: gleiche Prozedur, unterschiedliche Argumente, radikal verschiedene Ergebnisse.

Tans Beispiel: Ein Skill namens /investigate hat sieben Schritte (Datensatz eingrenzen, Timeline aufbauen, jedes Dokument diarisieren, synthetisieren, beide Seiten argumentieren, Quellen zitieren). Auf einen Sicherheitswissenschaftler und 2,1 Millionen Discovery-E-Mails gerichtet, entsteht ein medizinischer Forschungsanalyst. Auf eine Briefkastenfirma und FEC-Unterlagen gerichtet, entsteht ein forensischer Ermittler. Gleiche sieben Schritte: der jeweilige Kontext der Anwendung definiert die Welt.

2. Resolver

Ein Resolver ist eine Routing-Tabelle für Kontext: Wenn Aufgabentyp X erscheint, wird zuerst Dokument Y geladen. Ohne Resolver ändert ein Entwickler einen Prompt und deployt ihn. Mit Resolver liest das Modell zunächst die Eval-Suite-Dokumentation, führt Benchmarks aus und macht Änderungen rückgängig, wenn die Genauigkeit um mehr als 2 Prozent sinkt. Der Entwickler wusste gar nicht, dass die Eval-Suite existiert. Der Resolver hat den richtigen Kontext zur richtigen Zeit bereitgestellt.

3. Latent vs. deterministisch

Jeder Schritt in einem System ist eines von beiden. Diese Grenze zu verwischen ist der häufigste Fehler im Agent-Design. Ein LLM kann acht Menschen unter Berücksichtigung ihrer Persönlichkeiten an einem Tisch platzieren. Bei 800 Personen halluziniert es einen Sitzplan, der plausibel wirkt, aber vollständig falsch ist: ein deterministisches Problem, das in den Latent Space gezwungen wurde. Die besten Systeme ziehen diese Grenze kompromisslos.

4. Diarisierung

Das Modell liest alles über ein Thema und erstellt ein strukturiertes Profil. Kein SQL-Query erzeugt das. Keine RAG-Pipeline erzeugt das. Das Modell muss lesen, Widersprüche im Kopf halten, Veränderungen und deren Zeitpunkt bemerken und daraus strukturierte Erkenntnisse synthetisieren.

Tans Team entwickelte ein System für YC Startup School, das auf diese Weise 6.000 Gründerprofile verwaltet. Die Diarisierungsausgabe entdeckt Dinge, die keine Keyword-Suche finden würde: eine Gründerin, die sagt "Datadog für KI-Agenten", deren GitHub-Commits jedoch zu 80 Prozent aus Billing-Code bestehen. Sie baut ein FinOps-Tool, das als Observability-Produkt getarnt ist. Diese Lücke zwischen "sagt" und "baut tatsächlich" erfordert, die Commit-Historie, den Antrag und das Advisor-Transkript gleichzeitig zu lesen. Keine Embedding-Ähnlichkeitssuche findet das.

5. Permanente Upgrades

Tans Anweisung an seine KI lautet: "Wenn ich dich bitte, etwas zu tun, das so ist, als würde es wieder vorkommen müssen, kodifiziere es in eine Skill-Datei. Wenn es automatisch laufen soll, richte einen Cron ein. Wenn ich dich zweimal nach derselben Sache fragen muss, hast du versagt." Jeder geschriebene Skill ist ein permanentes Upgrade. Er verfällt nicht. Mit jedem neuen Modell werden alle Skills automatisch besser. Das System kumuliert sich.

Fünf in einer Woche veröffentlichte Frameworks kommen zur selben Schlussfolgerung

Die Konvergenz ist das stärkste Signal. Diese fünf Arbeiten entstanden unabhängig voneinander zwischen dem 12. und 15. April 2026. Keiner dieser Entwickler arbeitete mit den anderen zusammen. Von unterschiedlichen Ausgangspunkten gelangten sie zur selben Architektur.

Tan gelangte dorthin über den Aufbau einer hohen Menge an Produktionscode in zwei Monaten, wobei die Zeilenanzahl ein Durchsatz-Metrik ist und dieser Durchsatz ungewöhnlich war mit gstack (23.000+ GitHub-Sterne in der ersten Woche; Sternzahlen messen Sichtbarkeit, nicht Produktionsreife). Karpathy gelangte dorthin durch das Debuggen der drei persistenten Fehlermodi von KI-Coding-Assistenten. Trivedy durch über 30 iterierte Harness-Design-Versionen. Miessler durch die Anwendung von Richard Suttons Bitter Lesson auf KI-Tooling.

Konvergenz aus mehreren unabhängigen Quellen ist eines der stärksten Signale dafür, dass ein Architekturmuster tragfähig ist.

LangChain widerspricht, und hat Benchmarks als Beweis

Harrison Chase (CEO von LangChain) veröffentlichte Deep Agents in derselben Woche und argumentierte das Gegenteil: Das Harness sei das Produkt. Eingebaute Aufgabenplanung, Sub-Agent-Spawning, Middleware, Hooks, vollständige Orchestrierungs-Infrastruktur. Sein Beleg: Allein durch den Wechsel des Harness stieg LangChains DeepAgent auf TerminalBench 2.0 von außerhalb der Top 30 in die Top 5.

LangChain verarbeitet täglich Millionen von Agenten-Aufrufen, weshalb dieser Einwand ernst genommen werden muss. Die Benchmarks sind öffentlich. Die eigentliche Spaltung: Tans Position ist, dass jedes Stück Logik im Harness das Reasoning begrenzt, das das Modell selbst hätte leisten können. Je besser das Modell wird, desto schlanker sollte das Harness sein. Chases Position ist, dass Harness-Engineering die Modellkapazität erweitert, anstatt sie zu ersetzen.

Beide Positionen können für unterschiedliche Kontexte zutreffen. Consumer- und persönliche Agenten, bei denen Portabilität und Langlebigkeit zählen, bevorzugen ein schlankes Harness. Enterprise-Pipelines, bei denen Zuverlässigkeit und Nachvollziehbarkeit im Vordergrund stehen, rechtfertigen möglicherweise ein fettes Harness. Dass Skills fett sein sollten, bestreitet keine Seite. Die entscheidende Frage für jedes Projekt ist, auf welcher Seite der Grenze der eigene Anwendungsfall liegt.

Die meisten Unternehmen, die erstmals KI-Features entwickeln, sollten schlank starten und Infrastruktur nur dann hinzufügen, wenn konkrete Zuverlässigkeitsgrenzen erreicht werden. Unklar, wo Ihr Projekt steht? webvise berät, welche Architektur passt.

Ihre Anweisungen verfallen. Ihr Kontext nicht.

Daniel Miessler veröffentlichte die schärfste Diagnose der Woche: das Bitter-Lesson-Engineering-Audit, benannt nach Richard Suttons Beobachtung von 2019, dass allgemeine Ansätze, die mit Rechenleistung skalieren, handcodierte Ansätze langfristig durchgängig schlagen.

Auf KI-Tools angewendet: Schlechtes Harness-Engineering bedeutet prescriptive Instructions: Zuerst diese Datei kopieren, dann das laden, dann dieses tun, dann jenes. Schritt-für-Schritt-Mikromanagement der KI-Ausführung. Dieser Ansatz verschlechtert sich, je intelligenter Modelle werden, denn übermäßig starre Schritte verhindern, dass das Modell sein eigenes Reasoning anwendet.

Gutes Harness-Engineering ist kontextuell. Wer man ist, woran man arbeitet, was erreicht werden soll, was gut und schlecht aussieht. Identität, Geschmack, Standards, Ziele. Das Modell findet selbst den Weg.

Miesslers Diagnose ist einfach: Liest sich die Konfiguration wie ein Rezept (Schritt 1, Schritt 2, Schritt 3), ist das schlechtes Harness-Engineering. Liest sie sich wie ein Briefing-Dokument (wer ich bin, was zählt, welche Tools vorhanden sind), ist das gutes Harness-Engineering. Kontext über die eigene Identität verfällt nie. Prescriptive Instructions werden mit jedem Modell-Update obsolet.

Die Architektur selbst ist nicht kompliziert: Fat Skills, Thin Harness, kompromisslose Trennung von latentem und deterministischem Arbeitsanteil. Das Schwierige ist die Disziplin: Urteilsvermögen in wiederverwendbare Skills kodieren statt One-off-Arbeit zu leisten, das Harness schlank halten, wenn die Versuchung lockt, Features hinzuzufügen, und dem Modell vertrauen, das Wie zu finden, wenn man ihm das richtige Was und Warum gibt.

webvise entwickelt KI-gestützte Systeme nach diesen Architekturprinzipien. Ob Agent-Workflow, automatisierte Pipeline oder produktionsreife KI-Integration: Die Architektur entscheidet mehr als das Modell.