Agentenarchitektur ist keine Anwendungsarchitektur: das agentix-Muster

Vor Kurzem haben wir ein Setup gesehen, in dem ein einziger MCP-Server mit rund zehn verschiedenen Anwendungen sprach. Ein Schweizer Taschenmesser: ein Prozess, alle Zugangsdaten, alle Werkzeuge, geschrieben für genau einen Agenten und für niemanden sonst wiederverwendbar. Es funktionierte, aber dafür ist MCP nicht gedacht. Dieser Beitrag erklärt, warum, trennt zwei Arten von Architektur, die man leicht verwechselt, und schlägt für die zweite ein Muster vor. Wo etwas Meinung und nicht Tatsache ist, steht das dabei.

Zwei Fragen, nicht eine

Anwendungsarchitektur legt fest, wie Code aufgebaut ist: Schichten, Services, wem welche Daten gehören, Ports und Adapter, wer wen aufruft. Diese Aufrufe stehen zur Entwurfszeit fest, werden im Pull Request geprüft und als Einheiten ausgeliefert, die unabhängig voneinander ausfallen.

Agentenarchitektur legt fest, wer zur Laufzeit was tun darf, wenn ein Modell den nächsten Schritt wählt und diese Wahl nicht deterministisch ist. Ihre Gegenstände sind Fähigkeitsgrenzen, Wirkungsradius, die Vertrauensgrenze zwischen Modellausgabe und echter Wirkung, Übergabeverträge, Freigaben und Kosten.

Beides steht senkrecht zueinander. Eine sauber geschichtete Anwendung kann einen Agenten beherbergen, der jedes Zugangsdatum besitzt, und ein unordentlicher Monolith kann hinter gut begrenzten Agenten stehen. Die beiden treffen sich am MCP-Server: in der Anwendungssicht ein Adapter, der ein Protokoll in Aufrufe an ein System übersetzt, in der Agentensicht eine Fähigkeitsgrenze, an der aus der Bitte eines Modells eine Wirkung wird.

Das agentix-Muster

Wir nennen es agentix-Muster, weil open-agentix darum herum gebaut ist, nicht weil seine Teile neu wären. Minimale Rechte, Bounded Contexts, Ports und Adapter und Workflow-Orchestrierung gab es lange vor Agenten. Unser Beitrag ist eine bestimmte Kombination, aufgeschrieben als Regeln, die man prüfen kann.

Definition. Im agentix-Muster liegt jedes System, das ein Agent berühren darf, hinter genau einem MCP-Server. Dieser hält die Zugangsdaten und bietet die Fähigkeiten des Systems als typisierte Werkzeuge an, getrennt nach Lesen und Schreiben. Jeder Geschäftsprozess ist ein versionierter Plan aus Schritten; jeden Schritt führt ein eigener, eng begrenzter Agent aus, der nur die Werkzeuge seines Schritts hält, ein typisiertes Ergebnis übergibt und jedes System nur über ein deterministisches Policy-Gate erreicht, das jede Entscheidung unter der Run-ID festhält.

Die Regeln und ihre Begründung

R1. Ein MCP-Server pro System. Ein Server pro System oder Bounded Context, und er ist die einzige Tür zu diesem System. Werkzeuge haben typisierte Schemas, Lesen und Schreiben sind getrennte Werkzeuge, die Zugangsdaten liegen nur dort. Warum: Eine Tür heißt eine Stelle zum Prüfen, zum Austauschen eines Schlüssels und zum Nachsehen im Audit-Trail, und ein kleiner Server lässt sich von jedem Agenten wiederverwenden, der dieses System braucht. Ein Server pro Werkzeug, das andere Extrem, vervielfacht Deployments und Zugangsdaten, ohne eine Grenze hinzuzufügen. Hat ein System sehr unterschiedliche Risikoklassen, etwa Rechnungen lesen und Erstattungen auslösen, bleibt es bei einem Server mit getrennten Lese- und Schreibwerkzeugen und Policy pro Werkzeug. Aufteilen sollte man den Server erst, wenn sich die Zugangsdaten selbst unterscheiden.

R2. Geschäftslogik wird zu 1..n Agenten, einer pro Schritt. Beschreiben Sie den Prozess als Schritte. Standardmäßig ist ein Schritt ein Agent; einen Gott-Agenten, der alle Server hält, gibt es nicht. Trennen Sie, wenn sich Risikoklasse, Datenklasse, Rechte, Modell, Fehlerbehandlung, Kosten oder Freigabebedarf unterscheiden. Zusammenlassen sollten Sie Schritte, die Kontext und Rechte teilen: Jede Trennung kostet Latenz, Tokens und Abstimmung und verliert Kontext, den der nächste Agent gebraucht hätte.

R3. Agenten sprechen nie direkt mit Systemen. Jeder Werkzeugaufruf läuft durch ein deterministisches Policy-Gate (erlauben, ablehnen, Freigabe) und landet im Audit-Trail. Ein Modell darf fragen; die Entscheidung kommt aus Code, den man lesen und testen kann, außerhalb des Prompts.

R4. Übergaben sind ausdrücklich, typisiert und knapp. Agenten reichen dem nächsten Schritt ein Artefakt mit Schema weiter, keinen gemeinsamen Speicher und keinen offenen Chat. Eine typisierte Übergabe lässt sich prüfen, protokollieren und erneut abspielen; Freitext aus einem Schritt, der feindliche Eingaben gelesen hat, ist ein Weg für Prompt-Injection in den nächsten.

R5. Orchestrierung ist Daten. Die Reihenfolge der Schritte steht in einem versionierten Plan, nicht in einem weiteren Agenten, der alles weiß. Einen Plan kann man vergleichen, prüfen und festschreiben; ein Orchestrator-Agent mit allen Werkzeugen ist ein Gott-Agent mit Umweg.

R6. Budgets und Identität pro Schritt. Jeder Agent hat eigene Grenzen (Schritte, Werkzeugaufrufe, Tokens, Kosten, Zeit) und eine eigene Identität im Audit-Trail. So stoppt eine Schleife nur ihren Schritt, und auf „Wer war das?“ gibt es eine bessere Antwort als „die Pipeline“.

R7. Beobachtbarkeit über die Run-ID. Jeder Modellaufruf, Werkzeugaufruf, jede Policy-Entscheidung, Freigabe und Kostenzeile trägt Run-ID und Agenten-ID. Ohne das kann niemand zeigen, dass R1 bis R6 eingehalten wurden.

Ein durchgerechnetes Beispiel: Ticket-Triage

Ein Ticket zu einer fehlgeschlagenen Zahlung kommt herein. Jemand soll Ticket und Kunde nachschlagen, entscheiden, ob daraus ein Engineering-Issue werden muss, und es gegebenenfalls anlegen.

Manipuliert Text im Ticket den Research-Agenten, kann dieser nur lesen. Der Analyse-Agent hält nichts, was sich missbrauchen ließe. Der Action-Agent kann eine Art von Issue anlegen, erst nach Freigabe durch einen Menschen, und kann das CRM nicht lesen. Als Plan, skizziert in der Form des geplanten Agent Plan (kein ausgeliefertes Format):

kind: AgentPlan
name: payment-ticket-triage
version: 1.0.0
steps:
  - agent: research
    tools: [jira.issue.get, jira.issue.search, crm.customer.get]
    output: { schema: findings.json }
    budget: { maxToolCalls: 10, maxCostUsd: 0.10 }
  - agent: analysis
    tools: []
    input: findings.json
    output: { schema: decision.json }   # { action: "create" | "none", summary, priority }
  - agent: action
    when: decision.action == "create"
    tools:
      - name: jira.issue.create
        approval: required
        maxCallsPerRun: 1
    input: decision.json

Best Practices für den Entwurf von MCP-Servern

Bei jedem Punkt steht, ob die MCP-Dokumentation ihn nennt (Doku) oder ob er unsere Empfehlung ist (unsere). Die Quellen stehen am Ende.

• Eine Verantwortung: ein System oder eine Fähigkeit pro Server (unsere, vereinbar mit der Doku, die Server beschreibt, die „specific capabilities“ bereitstellen, und Beispiele mit je einem System nennt).
• Kleine, typisierte Werkzeugoberfläche: jedes Werkzeug mit Eingabeschema, Typen und Pflichtfeldern (Doku: Werkzeuge sind „schema-defined interfaces“; Grenzen und Enums sind unsere).
• Lesen und Schreiben getrennt: eigene Werkzeuge, zerstörerische heißen auch so (unsere; die Doku trennt nur lesende Ressourcen von Werkzeugen, die das Modell steuert).
• Idempotent und begrenzt: Schreibzugriffe gefahrlos wiederholbar, Ergebnisse in der Größe begrenzt (unsere).
• Klare Fehler, die Agent und Audit-Trail unterscheiden können (unsere).
• Keine Zugangsdaten im Umlauf: Geheimnisse im Server auflösen, nie im Prompt; das Token eines Clients nie an eine nachgelagerte API durchreichen (Doku für das Token, unsere für den Rest).
• Minimale Scopes: klein anfangen, bei Bedarf erweitern (Doku).
• Policy und Freigabe pro Werkzeug (Doku nennt Freigabedialoge und Vorab-Erlaubnisse als Möglichkeiten; deterministische Policy pro Werkzeug ist unsere).
• Versionierung von Werkzeugen und Scopes, keine stillen Bedeutungsänderungen (Doku für Scopes, unsere für Werkzeuge).
• Audit: jeder Aufruf einem Lauf und einem Agenten zuordenbar (Doku nennt Aktivitätsprotokolle und Korrelations-IDs; Run- und Agenten-ID sind unsere).

Antimuster

• Der Gott-Agent: ein Agent mit allen Servern, „weil es einfacher ist“, bis zur ersten Injection.
• Der Taschenmesser-Server: ein MCP-Server für viele Systeme. Viele Zugangsdaten, keine Wiederverwendung.
• Ein MCP-Server pro Endpunkt: viele Türen, keine Grenze.
• Geteilte Zugangsdaten: Der Audit-Trail kann nicht mehr sagen, wer gehandelt hat.
• Freier Chat zwischen Agenten: nichts zu prüfen, nichts erneut abzuspielen.
• Der Orchestrator-Agent, der alles hält: die häufigste Art, R5 zu brechen.
• Policy im Prompt: „Lösche niemals etwas“ ist ein Wunsch, keine Kontrolle.

Checkliste für die Entscheidung

1. Kann ich jeden Schritt des Prozesses in einem Satz benennen?
2. Welche Werkzeuge welcher Server braucht jeder Schritt, und welche davon lesen nur?
3. Unterscheiden sich benachbarte Schritte in Risiko, Datenklasse, Rechten, Modell, Fehlerbehandlung, Kosten oder Freigabe? Dann trennen, sonst zusammenlassen.
4. Was übergibt jeder Schritt, und kann ich dafür ein Schema schreiben?
5. Welche Aufrufe brauchen einen Menschen, und wer darf entscheiden?
6. Kann ich einen Lauf allein aus seiner Run-ID nachvollziehen?

Was die Dokumentation sagt und was von uns kommt

Die MCP-Dokumentation beschreibt einen Host, der pro Server einen eigenen Client anlegt, Server, die „specific capabilities“ bereitstellen, mit Beispielen je System (Dateisystem, Datenbank, GitHub, Slack, Kalender), Werkzeuge, die jeweils „a single operation“ ausführen, eine optionale Zustimmung des Nutzers vor einem Werkzeugaufruf und Sicherheitshinweise, die das Durchreichen von Tokens verbieten und minimale Scopes empfehlen. Die Claude-Code-Dokumentation beschreibt Subagenten mit eigenem Kontextfenster, „specific tool access“, einer tools-Allowlist und optional eigenem Modell und eigener MCP-Server-Liste. R1, R2 und R3 sind damit vereinbar. Keine der Quellen schreibt unsere Regeln vor oder empfiehlt dieses Muster.

Wo wir weiter gehen oder abweichen: Die MCP-Doku verlangt nicht einen Server pro System; eines ihrer eigenen Beispiele ist ein kombinierter „Calendar/Email Server“. Subagenten in Claude Code geben eine Zusammenfassung an die Hauptunterhaltung zurück, die selbst delegiert. Unsere R4 (typisierte Übergaben) und R5 (Plan statt orchestrierendem Agenten) sind strengere Entscheidungen für unbeaufsichtigte, protokollierte Läufe, keine Korrektur dieser Dokumentation.

Abwägungen und Meinung

Mehr Agenten bedeuten mehr Übergaben, mehr Modellaufrufe, mehr Latenz und mehr Pflege. Eine Aufgabe mit einem Werkzeug und einem Leser braucht keine drei Agenten. Was hilft: Schritte mit gleichen Rechten zusammenlassen, für enge Schritte kleine Modelle und, wo kein Modell nötig ist, schlichten Code nehmen, Übergaben kurz halten. Die Regeln leihen sich etwas bei minimalen Rechten, Microservices, Bounded Contexts sowie Ports und Adaptern, sind aber nicht dasselbe: Microservices trennen Deploy-Einheiten, R2 trennt Befugnisse. Tatsache: Werkzeugaufrufe lassen sich abfangen, und eine kleinere Berechtigung reicht weniger weit. Meinung: dass ein Schritt pro Agent der richtige Standard ist, ein Server pro System die richtige Körnung und der Mehraufwand sich meistens lohnt.

Wo open-agentix steht

Umgesetzt in 0.1.0: Pipelines aus 1..n Agenten in agents.md mit unveränderlichen Versionen, Werkzeug-Allowlists mit Argumentregeln und approval: required pro Agent, Modell und Budget pro Agent, das deterministische Policy-Gate, das MCP-Gateway, der verkettete Audit-Trail sowie Schritte und Kosten pro Lauf und Agent. Auf main, aber noch nicht veröffentlicht: Mandanten, Verbindungen mit Geltungsbereich Mandant, Team oder Agent (nur mit Referenzen auf Geheimnisse) und Rollenbindungen für einzelne Agenten.

Noch nicht da:

• Typisierte Übergaben (R4): Die vorige Ausgabe wird als Text weitergereicht; format: json wird geparst, aber nicht gegen ein Schema geprüft. Ein- und Ausgabeschemas sind geplant.
• Bedingte Pläne (R5): Heute ist eine Pipeline eine geordnete Liste; when ist geplant.
• Benannte Lese- und Schreibprofile pro Server (R1) kommen mit der geplanten Katalog-Governance; bis dahin erreichen Freigaben pro Agent und Policy-Muster dasselbe.
• Zugangsdaten pro Schritt und isolierte Worker (R6) stehen für v0.2 auf der Roadmap.
• Agent Check und die Erzeugung von Agent Plans, bei denen ein Modell die Aufteilung zur Prüfung durch Menschen vorschlägt, sind geplant und bewusst nur beratend.

Quellen

Alle abgerufen am 4. Oktober 2026. Wir geben sinngemäß wieder; Zitate sind kurz und englisch.

• Model Context Protocol, What is MCP?
• Model Context Protocol, Architecture overview
• Model Context Protocol, Understanding MCP servers
• Model Context Protocol, Security best practices
• Claude-Code-Dokumentation, Create custom subagents

Die Kurzfassung des Musters steht in der Dokumentation. Wenn Sie eine Regel für falsch halten oder einen Fall kennen, in dem ein Gott-Agent die bessere Lösung ist, schreiben Sie uns in den GitHub Discussions. Wir korrigieren das Muster lieber, als es zu verteidigen.