Alle reden über Context Engineering. Die meisten denken, es bedeutet bessere Prompts zu schreiben. Tut es nicht.
Context Engineering handelt davon, welche Daten den Agent erreichen, in welchem Format, durch welche Leitungen. Es ist API-Design für KI. Und hier ist, was niemand sagt: Das beste Context Engineering entfernt Schichten. Es fügt keine hinzu.
Ich baue seit einem Jahr Agent-Systeme, und die größte Performance-Verbesserung kam nicht von besseren Prompts, schlaueren Modellen oder ausgefeilterem Retrieval. Sie kam vom Entfernen des Frameworks.
Der Grund: Frameworks brauchen Dokumentationsdateien, weil Agents sie nicht verstehen. Bare Metal nutzt Patterns, die der Agent schon aus den Trainingsdaten kennt. Das ist der ganze Insight. Und es gibt mittlerweile Forschung, die das belegt.
Was Context Engineering wirklich bedeutet
Context Engineering ist nicht Prompt Engineering. Prompt Engineering ist, was du dem Modell sagst. Context Engineering ist, was das Modell sehen kann, wenn es anfängt zu arbeiten.
Stell dir das so vor: Prompt Engineering ist die Stellenbeschreibung. Context Engineering ist der Schreibtisch, die Werkzeuge, der Datenzugang, die Systeme, mit denen der Agent arbeitet. Ich habe darüber geschrieben, warum die Umgebung wichtiger ist als der Prompt — Context Engineering ist die praktische Umsetzung dieser These.
Effektive Agents zu bauen beginnt hier. Der Agent ist nur so gut wie der Kontext, den er erhält. Drei Dimensionen zählen:
Welche Daten injizieren. Nicht alles — die richtigen Dinge. Schema, Business Rules, Live-Zustand, Constraints. Die tatsächlichen Daten, die der Agent für diese spezifische Aufgabe braucht, kein allgemeiner Wissens-Dump.
Wann injizieren. Zur Laufzeit, nicht zum Trainingszeitpunkt. Der Agent braucht den Welt-Zustand jetzt, nicht eine gecachte Zusammenfassung von gestern.
Wie strukturieren. Roh, strukturiert, maschinenlesbar. Keine menschenfreundliche Dokumentation — agenten-freundliche Daten. JSON, nicht Prosa. Schema, nicht Beschreibung.
Das ist im Kern ein API-Design-Problem.
Context Engineering ist API-Design
Jede Context-Engineering-Entscheidung ist eine API-Design-Entscheidung. Welche Endpoints exponieren. Welche Daten zurückgeben. Welches Format verwenden. Was einbeziehen, was weglassen.
Gutes API-Design für Agents bedeutet Rohdaten, strukturierte Antworten, keine verlustbehaftete Kompression. Der Agent bekommt das tatsächliche Datenbank-Schema, nicht eine Beschreibung des Schemas. Er bekommt die echte API-Antwort, nicht eine Zusammenfassung dessen, was die API typischerweise zurückgibt.
Schlechtes API-Design für Agents bedeutet zusammengefasste Endpoints, vorgefilterte Ergebnisse und Abstraktionsschichten, die Daten vor dem Agent verstecken. Jede Schicht zwischen dem Agent und den Daten ist Informationsverlust.
Hier scheitern Frameworks. Frameworks fügen Abstraktion by Design hinzu — das ist ihr gesamtes Wertversprechen. Sie abstrahieren Komplexität weg, damit du dich nicht damit befassen musst. Aber wenn der Agent derjenige ist, der die Arbeit macht, wird Abstraktion zum Problem. Der Agent kann nicht über etwas nachdenken, was er nicht sehen kann.
Wie LLM Agents Kontext tatsächlich verarbeiten
Hier ist etwas, das die meisten Framework-Befürworter übersehen: LLM Agents verarbeiten alles im Kontext-Fenster gleich. Sie können nicht zwischen „wichtigem Kontext" und „Framework-Overhead" unterscheiden. Es sind alles Tokens.
Wenn ein Framework seine Routing-Konfigurationen, Schema-Wrapper, Tool-Definitionen, State-Management-Metadaten und Abstraktionsschicht-Anweisungen in den Kontext injiziert — verarbeitet der Agent alles davon. Er denkt über Rauschen nach, zusammen mit dem Signal. Jeder Token, der für Framework-Overhead ausgegeben wird, ist ein Token weniger für das Nachdenken über das eigentliche Problem.
Die ETH Zürich Studie vom Februar 2026 hat das direkt bewiesen. Forscher testeten, ob AGENTS.md-Dateien — Kontext-Dateien, die dem Agent Tools, Frameworks und Projektstruktur erklären — tatsächlich die Performance verbessern. Das Ergebnis: Automatisch generierte Kontext-Dateien reduzierten die Erfolgsrate um etwa 3%, während die Inferenz-Kosten um über 20% stiegen.
Die Agents waren zu gehorsam — sie folgten unnötigen Anweisungen aus Kontext-Dateien, was Aufgaben schwieriger statt einfacher machte. Codebase-Übersichten und Verzeichnislisten — ein Kernbestandteil der meisten Kontext-Dateien — halfen Agents nicht schneller zu navigieren. Die Agents waren bereits gut darin, Dinge selbst herauszufinden, wenn sie mit Patterns arbeiten, die sie verstehen.
Das führt direkt zum Kern-Insight.
Die Framework-Wissenslücke
Hier ist, was niemand sagt: Frameworks wie LangChain, CrewAI und ihre Äquivalente führen ihre eigenen Abstraktionen ein, ihre eigenen APIs, ihre eigenen Patterns. Das LLM hat diese während des Trainings nie gesehen — oder bestenfalls frühe Versionen, die nicht mehr zur aktuellen API passen.
Was machst du also? Du schreibst .md-Dateien. Du schreibst Dokumentation. Du injizierst Anweisungen, die erklären, wie das Framework funktioniert. Du bringst dem Agent eine neue Sprache bei, die er nicht nativ spricht.
Bare Metal — rohe API-Calls, fetch(), direktes HTTP, Standard-Bibliotheken — das kennt der Agent bereits. Das ist in den Trainingsdaten. Das LLM hat Millionen von Beispielen für fetch()-Calls, REST APIs, JSON-Parsing, Standard-Patterns gesehen. Es braucht kein Handbuch. Es braucht keine .md-Dateien, die erklären, wie man sie benutzt.
Das ist der ganze Punkt: Frameworks erzeugen eine Wissenslücke, die du dann mit Kontext füllen musst. Dieser Kontext bläht das Fenster auf. Dieses Aufblähen verschlechtert die Performance. Du gibst Tokens dafür aus, dem Agent beizubringen, wie er dein Framework benutzt, statt ihn über das eigentliche Problem nachdenken zu lassen.
Die ETH Zürich Studie validiert genau das. Kontext-Dateien, die dem Agent Tools und Frameworks beschreiben, schaden mehr als sie nützen. Die best-performenden Setups hielten Kontext-Dateien unter 60 Zeilen. Professionelle Teams halten ihre Kontext-Dateien so klein wie möglich — weil mehr Anweisungen schlechtere Performance bedeuten.
Die Ironie: Framework-Macher sagen dir „es macht das Bauen von Agents einfacher." Dann verbringst du Tage damit, .md-Dateien zu schreiben, die dem Agent das Framework erklären. Wenn du dein Werkzeug der KI erklären musst, ist vielleicht das Werkzeug das Problem.
Wöchentliche Insights zu AI-Architektur. Kein Spam.
Warum Context Bloat Agent-Performance killt
Die Forschung zu Kontext-Fenster-Degradation ist klar und konsistent. Mehr Kontext hilft nicht nur nicht — er schadet aktiv.
Chroma Researchs technischer Report über „Context Rot" testete 18 LLMs und fand, dass Modell-Performance mit steigender Input-Länge sinkt, oft auf überraschende und nicht-uniforme Weise. Das Hinzufügen der vollständigen Konversationshistorie — ungefähr 113.000 Tokens — ließ die Genauigkeit um 30% fallen im Vergleich zu einer fokussierten 300-Token-Version derselben Aufgabe. Der Performance-Abfall ist nicht graduell. Er ist unvorhersehbar, modellspezifisch und oft katastrophal.
Der NoLiMa-Benchmark von Adobe Research testete 12 LLMs, die mindestens 128K Tokens Kontext unterstützen. Bei kurzen Kontexten unter 1.000 Tokens erreichten Modelle wie GPT-4o 99,3% Genauigkeit. Bei 32.000 Tokens fiel das auf 69,7%. Zehn von zwölf Modellen fielen unter 50% ihrer Kurzkontext-Performance bei 32K Tokens.
Die praktische Realität: Ein Modell, das 200.000 Tokens Kontext bewirbt, wird typischerweise um die 130.000 herum unzuverlässig. Die effektive Kapazität liegt bei 60-70% des beworbenen Maximums. Frameworks schieben dich über diese Schwelle, indem sie Overhead-Kontext injizieren — Routing-Konfigurationen, Schema-Wrapper, Tool-Definitionen, State-Management-Metadaten — bevor der Agent überhaupt anfängt, an deinem eigentlichen Problem zu arbeiten.
Bare Metal hält dich unter der Klippe. Wenn der Agent keine Framework-Dokumentation, Routing-Configs oder Abstraktionsschicht-Anweisungen in seinem Kontext-Fenster braucht, hast du mehr Platz für die Daten, die tatsächlich zählen. Ich habe darüber geschrieben, warum die Umgebung, nicht das Modell, Agent-Halluzinationen verhindert — Context Engineering ist, wie du diese Umgebung baust.
Die Bare-Metal-Agent-Architektur
Wie sieht Bare Metal tatsächlich aus? Rohe API-Calls. Direkter Datenzugriff. Keine Abstraktionsschicht zwischen dem Agent und den Systemen, mit denen er arbeitet.
Die Architektur ist geradlinig: Direkte API-Calls + Context Injection. Der Agent ruft APIs direkt auf — dieselben APIs, die du auch manuell aufrufen würdest. Er bekommt rohe JSON-Antworten. Er sieht die tatsächlichen Daten. Kein Framework-Preprocessing. Keine Zusammenfassungsschicht. Keine Abstraktion, die versteckt, was wirklich passiert.
Warum das funktioniert: Der Agent sieht jedes Byte, das durch das System fließt. Volle Sichtbarkeit bedeutet volle Reasoning-Fähigkeit. Der Agent braucht niemanden, der ihm das Datenformat erklärt — er liest JSON nativ. Er braucht keine Dokumentation für REST APIs — er wurde auf Millionen davon trainiert.
Der kontra-intuitive Insight: Bare-Metal-Agents brauchen WENIGER Kontext, weil sie VOLLE Daten-Sichtbarkeit haben. Frameworks zwingen dich, mehr Kontext zu injizieren, um zu kompensieren, was die Abstraktion versteckt. Wenn der Agent mit Patterns arbeitet, die er bereits versteht — Standard-HTTP, JSON, REST — musst du nichts erklären. Du gibst ihm einfach die Daten und lässt ihn arbeiten.
Das verbindet sich damit, wie ich Context Injection als Säule autonomer Agent-Architektur verstehe. Je weniger Overhead zwischen dem Agent und der Realität, desto autonomer kann er sein.
Agent-Koordination funktioniert genauso. Statt Framework-gesteuertem Message Passing zwischen Agents — das Overhead hinzufügt und Daten versteckt — nutze die Umgebung als Message Bus. Event-driven Koordination. Agents reagieren auf Umgebungs-Änderungen, nicht aufeinander. Keine Abstraktionsschicht, die die Konversation managt. Nur geteilter Daten-Zustand.
Agents bauen ohne Frameworks
Wie sieht das Bauen von Agents von Grund auf in der Praxis tatsächlich aus?
Der Stack ist einfach: Rohe API-Calls + Context Injection + Verifikation. Daten rein, Logik, Daten raus. Der kürzeste Pfad zwischen dem Agent und den Daten gewinnt.
Der Vergleich erzählt die Geschichte. 4 Zeilen fetch() versus 200 Zeilen LangChain-Abstraktions-Spaghetti. Beide erreichen dasselbe — einen Prompt mit Kontext an ein Modell zu senden. Aber die fetch()-Version hat null Overhead. Null Framework-Dokumentation nötig. Null zusätzliche Tokens verbraucht, um dem Agent beizubringen, wie man ein Tool benutzt, das er nicht versteht.
Bedeutet das, dass Frameworks nie Sinn machen? Nein. Wenn du in 48 Stunden einen Proof of Concept liefern musst und dir Performance egal ist, bringt dich ein Framework schneller ans Ziel. Wenn du ein großes Team hast, das standardisierte Patterns braucht und bereit ist den Performance-Preis zu zahlen, bieten Frameworks diese Struktur.
Aber wenn Agent-Performance zählt — wenn Reasoning-Qualität zählt, wenn Kontext-Effizienz zählt, wenn du effektive Agents bauen willst, die tatsächlich im Echtbetrieb funktionieren — ist Bare Metal die Architektur. Nicht weil es trendy ist. Sondern weil es der kürzeste Pfad zwischen dem Agent und der Realität ist.
Der Migrationspfad ist nicht mal ein Rewrite. Es ist das Entfernen von Schichten. Strip das Framework. Behalte die Logik. Lass den Agent mit Patterns arbeiten, die er bereits versteht.
Die Context-Engineering-These
Context Engineering bedeutet nicht, bessere Prompts zu schreiben. Es bedeutet, dem Agent bessere Daten durch sauberere Leitungen zu geben.
Frameworks erzeugen eine Wissenslücke. Du füllst diese Lücke mit Dokumentation. Diese Dokumentation bläht den Kontext auf. Dieses Aufblähen killt Performance. Die ETH Zürich Studie beweist es. Die Chroma Research Daten bestätigen es. Die Architektur erklärt warum.
Bare Metal bedeutet, der Agent arbeitet mit Trainingsdaten, die er bereits versteht. Keine .md-Dateien nötig. Keine Framework-Dokumentation, die dein Kontext-Fenster verbraucht. Mehr Platz für echte Arbeit. Bessere Ergebnisse.
Die beste Abstraktionsschicht ist keine Abstraktionsschicht. Dein Job ist es, die kürzeste Leitung zwischen dem Agent und der Realität zu bauen.