Managed Agent Mesh: das Kollaborations-Gewebe für 71 Agenten

Pexon Consulting | 11 Min. Lesezeit | 11.06.2026

TL;DR

Managed Agent Mesh ist die Pexon-Antwort auf das Skalierungs-Problem produktiver Multi-Agent-Plattformen: Bei 71 produktiven Agenten quer durch ein Unternehmen reden sie ohne Mesh-Struktur nicht miteinander, jeder Agent ist eine Insel, Routing-Logik ist mehrfach gebaut, Kontext geht zwischen Agenten verloren. Das Agent Mesh löst das mit Agent Registry, A2A-Message-Bus, Supervisor/Router-Schicht, Shared Context, Skills-Katalog und Mesh-Observability — als von Pexon betriebener Stack.

Warum Agenten ohne Mesh nicht skalieren

Wir sehen das Pattern aktuell wöchentlich: Ein Mittelständler hat über 18 Monate 8 oder 12 produktive AI-Agents gebaut — einer für CRM, einer für ERP, einer für Document Intelligence, einer für Kundenservice. Jeder Agent funktioniert isoliert. Bei der nächsten Use-Case-Welle („der Customer-Support-Agent soll mit dem ERP-Agent zusammenarbeiten, um Lieferstatus zu beantworten“) wird klar: Sie reden nicht miteinander. Routing ist mehrfach gebaut. Kontext geht zwischen Agenten verloren.

Das Problem ist nicht „wir haben zu viele Agents“. Das Problem ist, dass die Kollaborations-Schicht fehlt. Jeder Agent ist eine Insel, die nur über ihr User-Frontend erreichbar ist. Die strukturelle Antwort heißt Agent Mesh — eine Plattform-Schicht, in der Agenten sich gegenseitig finden, miteinander sprechen, Kontext teilen und über eine zentrale Observability nachvollziehbar bleiben.

Pexon Consulting hat das Agent Mesh als Pexon-Produkt aufgebaut, basierend auf den Patterns aus 30+ Multi-Agent-Projekten. Der konkrete Zahlwert „71 Agenten“ stammt aus unserem größten produktiven Setup — ein Mittelständler mit zwischenzeitlich 71 produktiv betriebenen Agents quer durch alle Fachbereiche. Bei der Größe ist das Mesh nicht „nice to have“, sondern strukturelle Pflicht.

Die sechs Mesh-Komponenten im Detail

Komponente 1: Agent Registry. Zentrales Verzeichnis aller produktiven Agents. Pro Agent: Name, Beschreibung, Verantwortlichkeitsbereich, verfügbare Tools, Lifecycle-Status, Owner, AI-Act-Klassifikation, DSGVO-Folgenabschätzung. Jeder Agent registriert sich beim Start im Mesh, der Discovery-Service kennt alle Agenten. Mehr zur Registry-Architektur im Agent-Registry-Blog.

Komponente 2: A2A-Kommunikation. Agent-to-Agent Handoffs und Message-Bus für asynchrone Kollaboration. Wenn der Customer-Support-Agent eine Frage hat, die der ERP-Agent beantworten kann, übergibt er sie nicht über User-Umwege, sondern direkt via A2A-Bus. Wir bauen das mit NATS oder Redis Streams als Message-Bus, plus standardisiertes Message-Format (Sender, Empfänger, Conversation-ID, Payload, Trace-Context).

Komponente 3: Supervisor / Router. Multi-Agent-Workflows brauchen Orchestrierung. Der Supervisor entscheidet, welcher Agent als nächstes drankommt, holt sich Ergebnisse, konsolidiert. Wir bauen das typisch mit langgraph-supervisor (mehr im Agent-Routing-Blog). Bei 71 Agenten gibt es nicht einen Master-Supervisor, sondern hierarchische Strukturen — Sub-Supervisor pro Fachbereich, Top-Level-Router für Cross-Domain-Anfragen.

Komponente 4: Shared Context. Gemeinsamer Speicher über Conversation-Sessions, sodass Agenten den User-Kontext nicht jedes Mal neu aufbauen müssen. Wir bauen das mit Postgres als Backend, plus klar definierter Context-Lebensdauer (typisch 24 Stunden, konfigurierbar pro Anwendungsfall). Sensitive Felder werden gehasht oder verschlüsselt.

Komponente 5: Skills- und Tool-Katalog. Wiederverwendbare Fähigkeiten, die mehrere Agenten gemeinsam nutzen. Statt jeder Agent baut seine eigene CRM-Suche, gibt es einen zentralen search_crm-Skill, den jeder berechtigte Agent nutzen kann. Wir bauen das als MCP-Server-Föderation — mehr im Universal-MCP-Client-Blog.

Komponente 6: Mesh-Observability. Cross-Cutting-Beobachtbarkeit pro Hop — wer hat wann mit wem gesprochen, welche Permissions waren im Spiel, welche Latenz hatte der Hop, welche Cost ist entstanden. Wir nutzen OpenTelemetry mit GenAI Semantic Conventions, mehr im OpenTelemetry-AI-Agent-Blog.

Pexon als Managed-Service-Provider

Das Agent Mesh ist nicht „wir geben euch Code und ihr betreibt es selbst“. Es ist ein Managed Service, in dem Pexon den Mesh-Betrieb übernimmt.

Konkret: Wir bauen, deployen und betreiben die Mesh-Infrastruktur auf eurer Cloud-Umgebung (Bedrock Frankfurt, Azure Sweden, on-prem). Wir pflegen die Standard-Pattern für Registry, A2A, Supervisor, Shared Context. Wir liefern Mesh-Updates und neue Features. Ihr deployt eure Agenten in das Mesh und nutzt die Plattform-Funktionen.

Vorteile dieses Modells: Erstens, ihr habt eine einzelne Plattform-Komponente, die professionell betrieben wird. Zweitens, neue Agenten profitieren sofort von Mesh-Funktionen ohne eigenen Engineering-Aufwand. Drittens, Mesh-Pattern-Updates kommen automatisch — wenn wir neue Best-Practices entdecken, profitieren alle unsere Kunden gleichzeitig.

Operations-Niveau: 99,9% Verfügbarkeit garantiert für Mesh-Komponenten (Registry, A2A-Bus, Supervisor-Service). Updates auf Mesh-Software in kontrollierten Cycles, vorab kommuniziert. 24/7-Bereitschaft für kritische Vorfälle.

Wann lohnt sich Agent Mesh

Pragmatische Faustregel aus unseren Projekten: Bei 3-5 produktiven Agenten reicht Punkt-zu-Punkt-Kommunikation. Bei 6-15 Agenten wird ein einfacher Supervisor sinnvoll. Ab 15-25 produktiven Agenten ist das volle Mesh strukturell notwendig — vorher ist es Overkill, danach ist es unverzichtbar.

Bei dem Mittelständler-Setup mit 71 Agenten haben wir das Mesh über 18 Monate aufgebaut, parallel zum Wachstum der Agenten-Landschaft. Wäre das Mesh nicht da gewesen, wäre die Agenten-Skalierung bei circa Agent 18-22 zum Stehen gekommen — die organisatorische Komplexität wäre nicht mehr handhabbar gewesen.

Häufig gestellte Fragen

Müssen wir alle unsere Agents zu LangGraph migrieren?

Nein. Das Mesh ist Framework-agnostisch. Agents können in Claude Agent SDK, OpenAI Agents SDK, LangGraph, eigenem Custom-Code oder Kombinationen davon laufen. Was wir verlangen: Jeder Agent implementiert das A2A-Protokoll und meldet sich in der Registry. Beides ist als SDK-Library für die wichtigsten Frameworks verfügbar.

Was passiert mit Datenschutz und User-Identity über Agent-Hops?

User-Identity wird über das Mesh propagiert. Jeder A2A-Aufruf trägt die User-Token-Claims, sodass nachgelagerte Agents auch unter User-Identity arbeiten. Permission-Checks werden pro Hop durchgeführt. Mehr zur Identity-Propagation im Agent-Permissions-Entra-ID-Blog. Ergänzend regelt das Permission Policies für Managed Agents-Modell, welche Aktionen ein einzelner Agent im Mesh ohne Rückfrage ausführen darf.

Wie verhindern wir Endlosschleifen zwischen Agenten?

Drei Schutz-Mechanismen. Erstens: Hop-Counter mit hartem Cap (typisch 8-12 Hops pro Conversation). Zweitens: Loop-Detection basierend auf Hash der A2A-Messages — wenn der gleiche Message-Pattern dreimal vorkommt, wird abgebrochen. Drittens: Cost-Cap pro Conversation, sodass Endlosschleifen finanzielle Sicherheit haben.

Wie skaliert das Mesh bei sehr hoher Last?

Aktuelle Auslegung: 71 Agents in Produktion mit rund 50.000 A2A-Hops pro Tag bei einem unserer Kunden. Mesh-Komponenten skalieren horizontal — Registry hinter Load Balancer, A2A-Bus mit NATS-Cluster, Supervisor-Service als Stateless-Replica-Set. Bei höheren Last-Profilen erweitern wir die Komponenten linear.

Kann ich das Mesh auch in einer Defence-Grade-Umgebung betreiben?

Ja. Mesh-Software läuft auf der Defence-Grade-Bare-Metal-Plattform. Für VS-NfD-eingestufte Setups passen wir die Mesh-Konfiguration entsprechend an (Encrypted A2A-Bus, Shared-Context mit Confidential-Computing-Schutz). Operations-Modell ist analog.

Nächster Schritt

Wenn dein Unternehmen mehr als 15 produktive Agenten hat und die Kollaborations-Skalierung ansteht: Wir machen einen 60-Minuten-Architektur-Call mit dir und idealerweise einem Senior-Engineering-Lead. Du beschreibst die aktuelle Agenten-Landschaft, wir skizzieren die Mesh-Architektur mit Festpreis-Setup und Operations-Vertrag.

Verwandte Themen