Kapitel 8 — Architektonische Deployment-Layouts

Achter Beitrag der kapitelweisen Tour durch LLM Primer IV: Designing AI Cognition with MCP. Darin: zwei Systeme mit identischer Orchestrierungslogik verhalten sich in der Produktion sehr unterschiedlich, weil die Frage „wo läuft das Modell eigentlich" auf drei verschiedene Arten beantwortet wird und jede Antwort eine andere Latenz-, Kosten- und Sicherheitsdecke setzt.

Warum dieses Kapitel existiert

Die Kapitel 6 und 7 spezifizierten, wie Agenten koordinieren. Sie schwiegen zu einer Frage, die ebenso viel über das reale Verhalten entscheidet: wo läuft jeder Agent, und wie sind Sprachmodelle, MCP-Server und Werkzeuge über das Netzwerk angeordnet? Die architektonischen Entscheidungen in diesem Kapitel berühren jeden Request und jeden Dollar. Drei deutlich verschiedene Layouts haben sich im MCP-Ökosystem durch 2025 bis 2026 herausgebildet, und keines ist universell richtig. Jedes ist für eine andere Beschränkungskombination optimiert, und die Wahl hat Konsequenzen, die Entwickler artikulieren können sollten, bevor sie sie treffen.

8.1 Der wiederverwendbare KI-Agent: Modell mit dem Server gepackt

Das erste Layout packt ein Sprachmodell zusammen mit einem MCP-Server und exponiert die Kombination als einzelne Black-Box-Capability. Der Client ruft „review diesen Pull Request" auf, wie er ein Tool aufrufen würde; darunter läuft eine vollständige agentische Schleife auf der Serverseite, ruft das Modell, ruft interne Tools und liefert nur die Endausgabe zurück. Das Muster entstand, als Organisationen spezialisierte Agenten — Research, Code-Review, Finanzanalyse — bauten, die sie vielen Host-Anwendungen freigeben wollten, ohne dass jede die Internals verstehen musste.

Die Stärken sind real. Kapselung erlaubt den Autoren, Modelle zu tauschen oder die Orchestrierung umzubauen, ohne dass für Clients etwas sichtbar wird. Wiederverwendbarkeit über Host-Anwendungen heißt, dass ein einzelner Agent Claude Code, eine Enterprise-App und einen Kunden-Chatbot über dieselbe Schnittstelle bedient. Die Kosten sind ebenso real. Opazität erschwert Debugging: trifft der Agent eine falsche Entscheidung, sieht der Client nicht, warum. Latenz stapelt, weil die server-seitige Schleife bei jedem Aufruf läuft. Und Doppel-Budgetierung ist strukturell: der Agent-Betreiber zahlt seine Modellaufrufe und der Client zahlt seine eigenen, und die Pro-Interaktion-Gesamtkosten können höher sein, als beiden Seiten initial bewusst ist.

Die Multi-Mandanten-Variante — ein Agent-Prozess bedient viele Client-Organisationen — verbessert die operative Ökonomie deutlich, indem sie Fixkosten über Mandanten amortisiert. Sie führt auch Datenleckagen zwischen Mandanten als erstklassigen Fehlermodus ein. Mehrere offengelegte Vorfälle in 2025 betrafen genau das, und Betreiber sollten Mandantenfähigkeit in die Laufzeit hineinentwerfen, statt sich auf Code-Reviews zu verlassen, um Lecks zwischen Requests zu fangen.

8.2 Strenge MCP-Reinheit: das Modell im Client

Das zweite Layout setzt das Sprachmodell strikt in den Client. MCP-Server geben nur Daten und Tools frei — keine Inferenz. Der Host fährt das Modell, trifft die Orchestrierungsentscheidungen und ruft Server, um Kontext zu sammeln und Aktionen auszuführen. Die Motivation ist die ursprüngliche Designbegründung des Protokolls: MCP existiert, um das N-mal-M-Integrationsproblem zu lösen, indem es eine uniforme Schnittstelle zwischen Modellen und Tools bietet, und Server, die ihre eigenen Modelle fahren, führen das Problem wieder ein, das das Protokoll lösen sollte.

Die Stärken sind Kontrolle und Transparenz. Jeder Modellaufruf ist für die Instrumentierung des Clients beobachtbar. Der Client wählt das Modell pro Request, kann zwischen Anbietern fallbacken und trägt sämtliche Modellkosten direkt — keine Doppel-Budgetierung, weil es kein zweites Modell in der Kette gibt. Für regulierte Industrien, in denen Audit-Logs beim Client die ganze Reasoning-Kette erfassen müssen, befriedigt strenge Reinheit die Anforderung ohne Mehrdeutigkeit.

Die Kosten sind ebenso klar. Jedes Stück Intelligenz muss von jedem Client neu implementiert werden, was für Organisationen mit vielen Host-Anwendungen eine echte Bürde ist. Manche Capabilities — Multi-Step-Recherche, iterative Verfeinerung — lassen sich umständlich als Single-Shot-Tools faktorisieren, und sie freizugeben, drückt entweder komplexe Orchestrierung in den Client oder verletzt die Reinheit still, indem der Server doch sein eigenes Modell fährt. Und der Client muss in der Lage sein, Orchestrierung zu fahren, was in der Praxis heißt, auf Strands, LangChain, Semantic Kernel oder das Microsoft Agent Framework zu setzen, statt die Schleife from scratch zu rollen.

8.3 Hybrid: client-seitige Orchestrierung mit server-seitiger Ausführung

Das dritte Layout splittet den Unterschied. Der Client orchestriert und fährt primäre Inferenz; bestimmte MCP-Server fahren eigene Modellaufrufe für spezialisierte Teilaufgaben. Das klarste Beispiel ist ein langlaufendes Deep-Research-Tool. Ein Client, der ein Recherche-Ergebnis in einen breiteren Workflow falten will, will nicht jeden Schritt der Recherche selbst verwalten; er will „recherchiere X und sag mir, was du gefunden hast" aufrufen und eine Synthese erhalten. Die Recherche ist mehrstufig, mehrquellig und profitiert von eigener interner Orchestrierung.

Das Hybrid-Muster funktioniert, wenn die Grenze an einer sinnvollen Naht gezogen wird — eine Teilaufgabe mit klaren Inputs und Outputs, in sich geschlossen genug, dass server-seitige Intelligenz sie ohne Client-Koordination abschließen kann, und spezialisiert genug, dass sie als Black Box besser läuft als durch den allgemeinen Orchestrator. Recherche, Code-Analyse, Dokumentensynthese passen ins Profil. Allgemeine Konversation nicht.

Der Preis ist architektonische Komplexität. Es gibt nun zwei Stellen, an denen Intelligenz läuft, Observability muss die Grenze überspannen, und Kostenzuordnung sitzt zwischen den beiden reinen Mustern. Eine nützliche Disziplin ist, die Zahl intelligenter Server zu begrenzen und jeden auf eine wohldefinierte Capability zu fokussieren. Zwei oder drei sind betreibbar; zwölf werden zu einer Föderation, die kein Team versteht. Hybrid-Deployments tendieren über die Zeit auch zu einem der reinen Enden, und Architekten sollten ehrlich sein, ob ihr Hybrid ein stabiles Design oder ein Übergangszustand ist.

Was Kapitel 8 vorbereitet

Die drei Kapitel von Teil III sind durch den Designraum von Multi-Agent-Systemen aus der Perspektive des Mechanismus gegangen. Was sie nicht abdecken, ist das darunterliegende Substrat: der Kontext, den jeder Modellaufruf erhält, und das Gedächtnis, das über Aufrufe hinweg persistiert. Die Wirksamkeit eines Agenten hängt davon ab, was er beim Handeln sehen und woran er sich erinnern kann. Das Kontextfenster ist endlich. Die Speicherarchitektur muss entworfen werden. Die Muster des Attention-Budget-Managements, der Scratchpad-Nutzung, des episodischen und semantischen Gedächtnisses sind das Substrat, das aus einer koordinierten Menge von Agenten ein System macht, das über Stunden, Tage oder länger nützliche Arbeit leistet.

Als Nächstes — Kapitel 9: Das Aufmerksamkeitsbudget verwalten. Warum ein Millionen-Token-Fenster eine Deckenwert ist und kein Betriebspunkt, was das Budget frisst, und wie MCP, RAG und Fine-Tuning jeweils zu einer anderen Lückenform passen.