Das agentix-Muster
Anwendungsarchitektur legt fest, wie Code aufgebaut ist. Agentenarchitektur legt fest, wer zur Laufzeit was tun darf, wenn ein Modell den nächsten Schritt wählt. Beide treffen sich am MCP-Server: in der einen Sicht ein Adapter, in der anderen eine Fähigkeitsgrenze. Das agentix-Muster ist die Form, um die open-agentix für die zweite Frage gebaut ist.
Definition
Abschnitt betitelt „Definition“Jedes System, das ein Agent berühren darf, liegt 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.
| Regel | In einem Satz |
|---|---|
| R1 | Ein MCP-Server pro System oder Bounded Context, die einzige Tür dorthin. Typisierte Werkzeuge, Lesen und Schreiben getrennt, Zugangsdaten nur dort. Unterschiedliche Risikoklassen: getrennte Werkzeugsätze und Policy pro Werkzeug. |
| R2 | Ein Prozess wird zu 1..n Agenten, standardmäßig einer pro Schritt. Trennen, wenn sich Risiko, Datenklasse, Rechte, Modell, Fehlerbehandlung, Kosten oder Freigabe unterscheiden; zusammenlassen, wenn Schritte Kontext und Rechte teilen. Kein Gott-Agent. |
| R3 | Agenten erreichen Systeme nie direkt: Jeder Werkzeugaufruf läuft durch das Policy-Gate und in den Audit-Trail. |
| R4 | Übergaben sind ausdrücklich, per Schema typisiert und knapp, kein gemeinsamer Speicher und kein freier Chat zwischen Agenten. |
| R5 | Orchestrierung ist Daten: ein versionierter Plan, kein allwissender Orchestrator-Agent. |
| R6 | Budgets, Grenzen und Identität pro Agent. |
| R7 | Alles ist über Run-ID und Agenten-ID nachvollziehbar. |
Antimuster
Abschnitt betitelt „Antimuster“Gott-Agent, ein Alles-Könner-MCP-Server für viele Systeme, ein MCP-Server pro Endpunkt, geteilte Zugangsdaten, freier Chat zwischen Agenten, ein Orchestrator-Agent mit allen Werkzeugen und Policy, die im Prompt steht.
Stand in open-agentix
Abschnitt betitelt „Stand in open-agentix“Verfügbar in 0.1 Pipelines aus 1..n Agenten in
agents.md mit Werkzeugen, Argumentregeln, Freigaben, Modell und
Budget pro Agent; das deterministische Policy-Gate; der verkettete Audit-Trail; Schritte und Kosten
pro Lauf und Agent.
Roadmap Schemaprüfung von Übergaben (heute wird
die vorige Ausgabe als Text weitergereicht, format: json wird geparst, aber nicht geprüft),
bedingte Planschritte, benannte Lese- und Schreibprofile pro MCP-Server, Zugangsdaten pro Lauf und
isolierte Worker (v0.2) sowie Agent Check und die Erzeugung von Agent Plans (beratend). Siehe die
Roadmap.
Quellen
Abschnitt betitelt „Quellen“Abgerufen am 4. Oktober 2026. Das Muster ist unsere eigene Synthese. Es ist mit diesen Seiten
vereinbar, die es nicht vorschreiben: MCP-Server stellen „specific capabilities“ bereit, und jedes
Werkzeug führt „a single operation“ aus; Subagenten bekommen über eine tools-Allowlist „specific
tool access“. Typisierte Übergaben (R4) und Pläne statt eines orchestrierenden Agenten (R5) gehen
über diese Quellen hinaus.
- Model Context Protocol, Architecture overview
- Model Context Protocol, Understanding MCP servers
- Model Context Protocol, Security best practices
- Claude-Code-Dokumentation, Create custom subagents
Begründung, ein durchgerechnetes Beispiel und die Abwägungen stehen im Blogbeitrag Agentenarchitektur ist keine Anwendungsarchitektur.