Kapitel 1 — Die KI-Integrationskrise und der Aufstieg der agentischen Architektur
Erster Beitrag der kapitelweisen Tour durch LLM Primer IV: Designing AI Cognition with MCP. Darin: das dominante Muster aus der 2024er-Ära — langer System-Prompt, eine Handvoll Werkzeuge, ein einziges Kontextfenster, das alles erledigen soll — versagt in einer wiedererkennbaren Reihenfolge, und das Versagen zeigt auf eine Protokollschicht, an der das Feld stillschweigend schon länger gearbeitet hatte.
Warum dieses Kapitel existiert
Etwa zwei Jahre lang lautete das Standardrezept für eine LLM-Anwendung: schreibe einen langen System-Prompt, häng eine Handvoll Werkzeuge dran, nenne das Ganze einen Agenten. Das Rezept lieferte Demos. Es brach — vorhersehbar — mit wachsender Oberfläche zusammen. Prompts krochen über sechstausend Tokens. Werkzeuginventare wuchsen über vierzig. Das Team patchte, auditierte, fuhr Regressionstests, und stellte irgendwann fest, dass das Hinzufügen von Features exponentiell teurer geworden war als früher. Die Diagnose war nicht Faulheit oder schlechtes Engineering. Es war eine Architektur, die jedes Anliegen durch eine geteilte Ressource zwang — den Kontext des Modells — und ein tieferes kombinatorisches Problem darunter.
Dieses Kapitel geht die Fehlermodi in der Reihenfolge durch, in der Teams ihnen tatsächlich begegnen, benennt jeden und rahmt anschließend den architektonischen Ausweg. Der Ausweg ist eine Protokollschicht, mit der Modelle und Werkzeuge sich ohne maßgeschneiderten Glue finden, und eine Disziplin — Context-Engineering — die den Blick des Modells als verwaltetes Budget behandelt statt als freies Textfeld. Beide Ideen stellen das Gerüst für den Rest des Buchs.
1.1 Der monolithische Agent und warum sein System-Prompt irgendwann bricht
Die erste Generation produktiver LLM-Anwendungen hatte eine architektonisch einfache Gestalt. Ein System-Prompt mit mehreren Tausend Tokens beschrieb Rolle, Werkzeuge, Beschränkungen, Tonalität und Sonderfälle. Für enge Flächen funktionierte das. Während das Team Feature für Feature in einzelnen Absätzen ergänzte, wurde der Prompt zum längsten einzelnen Artefakt der Codebasis, hauptsächlich durch Hinzufügen bearbeitet, weil das Entfernen riskant wirkte.
Was dieser Prompt intern tat, versteht man am besten über Aufmerksamkeit. Ein Transformer berechnet Attention-Gewichte über jedes Token im Kontext, jedes Token des System-Prompts eingeschlossen. Ein Prompt mit sechstausend Tokens wird nicht überflogen — es wird gegen ihn gemittelt. Je länger der Prompt, desto stärker verteilt sich die Aufmerksamkeitsmasse über Anweisungen, die für den aktuellen Schritt irrelevant sind. Das Phänomen hat Namen: Kontextverdünnung, Instruktionskollision, Capability Drift. Das Team beobachtet Regression und kann die Ursache nicht lokalisieren, weil die Ursache das Zusammenspiel dreier neuer Regeln mit einer vor zwei Sprints ergänzten Klausel ist.
Ein verwandter Fehler tritt auf der Werkzeugschicht auf. Bei zehn Tools wählt das Modell korrekt; bei vierzig fällt die Trefferquote bei der Auswahl, teils scharf. Das Team patcht mit klarstellender Sprache, die den Prompt verlängert, die die Aufmerksamkeit weiter verdünnt. Das System ist nun in einer Rückkopplungsschleife mit sich selbst.
1.2 Spezialisierung und die Wartungskurve, die in die falsche Richtung biegt
Unter dem Prompt-Problem liegt ein tieferes. Frontier-Modelle für allgemeine Zwecke sind starke Generalisten, aber Generalisten-Leistung ist ein Mittelwert über eine riesige Fläche, und Mittelwerte verbergen Klippen. Vertragsprüfung im Recht, strukturierte medizinische Codierung, Finanzabstimmung — jede hat eigenes Vokabular, eigene Regeln und eine Fehlertoleranz, für die allgemeines Training nicht optimiert. Der Instinkt sagt, das per Prompting zu spezialisieren; der Preis ist mehr verbrauchtes Aufmerksamkeitsbudget bei weniger Ertrag. Echte Spezialisierung will eine eigene Komponente mit eigenem fokussierten Kontext, für die der monolithische Agent keinen Platz hat.
Die Wartung skaliert in die gleiche falsche Richtung. Ein monolithischer Agent mit fünfzig Werkzeugen über vier Domänen hat nicht das Zehnfache der Wartungslast eines mit fünf Werkzeugen und einer Domäne — sondern mehr, weil jedes Feature über den geteilten Prompt mit jedem anderen interagiert. Die Geschwindigkeit des Teams wird durch die Kosten gesetzt, die bestehende Oberfläche kohärent zu halten, nicht durch die Kosten, neue Fähigkeiten zu bauen. Inferenzkosten skalieren mit der Kontextlänge, und so ziehen der ökonomische Druck, den Prompt zu schrumpfen, und der ingenieurtechnische Druck, ihn wachsen zu lassen, in entgegengesetzte Richtungen.
1.3 Das N-mal-M-Integrationsproblem
Akzeptiere das Argument für Zerlegung. Du hast nun N modelltragende Komponenten und M Tool-Integrationen. Ohne ein gemeinsames Protokoll sind die Integrationskosten N mal M — jedes Modell braucht eigenen Adaptercode für jedes Tool, mit den Eigenheiten jedes Modells kartesisch multipliziert mit den Eigenheiten jedes Tools. Ein neues Modellrelease bedeutet, jedes Tool erneut zu testen. Ein neues Tool bedeutet, N Adapter zu schreiben.
Die Geschichte der Informatik hat einen Namen für diese Form und einen Namen für die Lösung. Vor LSP (2016) brauchte jeder Editor Integration mit jeder Sprache — Editoren mal Sprachen. LSP führte ein Protokoll ein; die Matrix kollabierte auf additive Kosten. Vor USB hatte jede Peripherie ihre eigene Buchse und jedes Betriebssystem brachte eigene Treiber mit. Nach USB: ein Host, ein Gerät, ein gemeinsames Protokoll dazwischen. Das Model Context Protocol ist derselbe Zug, angewendet auf Modelle und Werkzeuge. Es macht Adapter nicht überflüssig; es standardisiert sie. Die erste Integration ist langsamer; die hundertste deutlich schneller; die tausendste praktisch frei, weil das Tooling sich akkumuliert hat. Das ganze Spiel liegt in der kumulativen Kurve.
Ein Protokoll mit Discovery lässt zusätzlich eine zweite, leisere Matrix in sich zusammenfallen — die Beschreibungsmatrix. Das Modell muss nicht mehr jedes Tool im System-Prompt beim Start aufgezählt bekommen; es kann das Protokoll fragen „was ist gerade verfügbar?" und einen strukturierten Katalog von der autoritativen Quelle erhalten: dem Server selbst.
1.4 Vom Prompt-Engineering zum Context-Engineering
Eine Begriffsverschiebung begleitet die architektonische. 2022 bis 2023 hieß die Disziplin Prompt-Engineering — Formulierungen finden, die das Modell in die gewünschte Richtung schubsen. Bis 2025 war der Prompt nur noch ein Input unter vielen. Das Modell sieht auch abgerufene Dokumente, Tool-Beschreibungen, vorige Turns, Tool-Ergebnisse, Scratchpad-Notizen, Memory-Snippets. Was in diesem Kontext zu jedem Schritt stehen sollte, beantwortet keine Formulierung mehr. Es beantwortet eine Architektur, die pro Turn entscheidet, worauf das Modell schauen soll.
Der Begriff, der sich eingebürgert hat, ist Context-Engineering. Er behandelt das Kontextfenster als verwaltetes Budget. Moderne Long-Context-Modelle bewerben Millionen-Token-Fenster, aber die Leistung baut nichtlinear ab, sobald der Kontext sich füllt — das Phänomen, das manchmal Context Rot heißt. Ein Modell, dem du einen Millionen-Token-Kontext mit der Antwort vergraben darin reichst, schneidet oft schlechter ab als dasselbe Modell mit zehntausend sorgfältig ausgewählten Tokens. Was zählt, ist nicht die Fenstergröße; es ist die Dichte nützlichen Signals in dem, was wirklich vor dem Modell steht.
MCP ist, zum Teil, die Infrastruktur, die Context-Engineering praktikabel macht. Das Protokoll gibt dem Host das Werkzeug, danach zu fragen, welche Tools und welche Datenquellen verfügbar sind, die relevanten im richtigen Moment zu holen und auszuhandeln, welche Capabilities das Modell aufrufen darf. Der Host baut den Kontext dynamisch, pro Turn, anhand dessen, was die aktuelle Aufgabe wirklich braucht.
Was Kapitel 1 vorbereitet
Die Diagnose hat drei Teile: monolithische Agenten scheitern, weil lange Prompts die Aufmerksamkeit verdünnen; spezialisierte Fähigkeit kann nicht in einem geteilten Prompt leben; darunter liegt das N-mal-M-Integrationsproblem. Jeder Fehlermodus zeigt in dieselbe Richtung — eine Schicht unter dem Modell, die vermittelt, wie Modelle und Werkzeuge sich finden, einander beschreiben und aushandeln, was sie tun können. Kapitel 2 führt diese Schicht ein: die drei Rollen, die MCP definiert, die kleine Menge konzeptioneller Primitiven und den Session-Lebenszyklus, der mit expliziter Capability-Verhandlung beginnt.
Als Nächstes — Kapitel 2: Das Model Context Protocol enthüllt. Was MCP ist, was das Kürzel „USB-C für KI" tatsächlich bedeutet, die Drei-Rollen-Aufteilung in Host, Client und Server und warum dynamische Entdeckung und bidirektionales Messaging MCP in den Fällen, die zählen, anders machen als eine REST-API.
