AGENTFORCE ARCHITEKTUR
Raus aus dem Monolithen: Skalierbare Multi-Agent-Architekturen mit Agentforce gestalten
Am Anfang wirkt ein einzelner Agent oft wie die einfachste Lösung: ein Prompt, viele Tools, ein gemeinsamer Kontext und ein zentraler Einstiegspunkt. Solange der Anwendungsfall überschaubar bleibt, kann das gut funktionieren.
Mit jedem zusätzlichen Prozess wächst jedoch die Verantwortung dieses Agenten. Neue Regeln kommen hinzu, weitere Tools müssen unterschieden werden und immer mehr Kontext konkurriert um Aufmerksamkeit. Änderungen an einer Stelle können Verhalten an ganz anderer Stelle beeinflussen.
Die entscheidende Architekturfrage lautet deshalb nicht: Wie viele Agenten brauchen wir? Sondern: Welche Aufgaben sollten bewusst getrennt werden, damit jeder Agent nur den Kontext, die Tools und die Verantwortung trägt, die er tatsächlich benötigt?
WARUM DER MONOLITH AN GRENZEN KOMMT
Warum ein einzelner Super-Agent mit wachsendem Umfang instabil wird.
Ein monolithischer Agent sammelt mit der Zeit immer mehr Verantwortung. Er muss unterschiedliche Aufgaben erkennen, passende Tools auswählen, fachliche Regeln berücksichtigen und gleichzeitig den bisherigen Gesprächskontext korrekt einordnen.
Das Problem ist nicht unbedingt die Leistungsfähigkeit des Modells. Das Problem ist, dass zu viele unterschiedliche Entscheidungen innerhalb desselben Kontextes getroffen werden müssen. Irrelevante Instruktionen und Tools bleiben sichtbar, obwohl sie für die aktuelle Aufgabe keine Rolle spielen.
Je größer der Agent wird, desto schwieriger wird es außerdem zu verstehen, warum er sich in einem konkreten Fall so verhalten hat. Tests werden breiter, Änderungen riskanter und Fehler lassen sich schlechter auf eine einzelne Verantwortung zurückführen.
Weniger Kontextlast
Jeder Agent erhält nur die Instruktionen, Daten und Tools, die für seine Aufgabe relevant sind.
Gezielte Orchestrierung
Die Entscheidung, welcher Agent zuständig ist, wird zu einem sichtbaren Teil der Architektur.
Mehr Modularität
Fachliche Fähigkeiten können verändert und getestet werden, ohne den gesamten Agenten neu aufbauen zu müssen.
Multi-Agent bedeutet deshalb nicht automatisch, für jeden einzelnen Schritt einen neuen Agenten anzulegen. Eine Aufteilung ist dann sinnvoll, wenn dadurch echte Verantwortungsgrenzen entstehen: anderer Kontext, andere Tools, andere Berechtigungen oder eine klar abgrenzbare fachliche Aufgabe.
Bleiben diese Grenzen unscharf, verteilt man die Komplexität lediglich auf mehrere Komponenten. Die Architektur sieht modularer aus, verhält sich aber weiterhin wie ein Monolith.
KONTEXT WÄCHST SCHNELLER ALS DIE AUFGABE
Was ein monolithischer Agent bei jedem Turn mit sich trägt.
In einem großen Agenten landen Systeminstruktionen, Tool-Beschreibungen, fachliche Regeln, Gesprächshistorie und zusätzliche Kontextinformationen im selben Entscheidungsraum.
Für eine einzelne Kundenfrage wird aber meist nur ein kleiner Teil davon benötigt. Trotzdem muss das Modell zwischen allen sichtbaren Optionen unterscheiden. Mit wachsendem Umfang steigt damit nicht nur die technische Last, sondern auch die Zahl möglicher Fehlentscheidungen.
Besonders kritisch wird das, wenn mehrere Fachdomänen ähnliche Aktionen anbieten. Ein Tool für Vertragsänderungen, ein Tool für Kundendaten und ein Tool für Servicefälle können für das Modell ähnlich aussehen, obwohl sie unterschiedliche fachliche Konsequenzen haben.
Eine gute Multi-Agent-Architektur reduziert diesen Entscheidungsraum bewusst. Der Orchestrator entscheidet zunächst nur, welche Verantwortung benötigt wird. Erst der zuständige Specialist Agent erhält den detaillierten fachlichen Kontext.
EIN PRAKTISCHES ARCHITEKTURMODELL
Das Vier-Ebenen-Modell für skalierbare Multi-Agent-Architekturen.
Eine belastbare Multi-Agent-Architektur trennt nicht nur Agenten voneinander. Sie trennt auch Routing, fachliche Arbeit, gemeinsam genutzte Fähigkeiten und den späteren Betrieb.
1. Orchestrator
Er erkennt die Art der Aufgabe und entscheidet, welcher Agent die Verantwortung übernimmt. Seine Aufgabe ist Routing – nicht die vollständige fachliche Bearbeitung.
2. Specialist Agents
Jeder Specialist Agent besitzt einen klar begrenzten fachlichen Auftrag, passende Instruktionen und nur die Tools, die für diesen Bereich notwendig sind.
3. Gemeinsame Fähigkeiten
Datenzugriff, wiederverwendbare Actions, Policies oder technische Services werden dort geteilt, wo mehrere Agenten wirklich dieselbe Fähigkeit benötigen.
4. Governance & Betrieb
Monitoring, Evaluation, Berechtigungen, Eskalation und Fehlerbehandlung bilden eine eigene Ebene. Sie dürfen nicht implizit in einzelnen Prompts verschwinden.
Diese Trennung verhindert, dass der Orchestrator selbst wieder zum neuen Super-Agenten wird. Er sollte möglichst wenig Fachlogik enthalten und nur genügend Kontext besitzen, um die nächste Zuständigkeit zuverlässig zu bestimmen.
Gleichzeitig sollten Specialist Agents nicht dauerhaft voneinander abhängig sein. Übergaben brauchen ein definiertes Ergebnis: Welche Information wird weitergegeben? Welche Entscheidung wurde bereits getroffen? Was bleibt offen?
KLARE VERANTWORTUNG
Jeder Agent braucht eine klar erkennbare Rolle.
Ein Specialist Agent sollte nicht nur durch seinen Namen von anderen Agenten unterscheidbar sein. Seine Aufgabe muss in der Architektur eindeutig beschrieben sein: Welche Arbeit übernimmt er? Welche Eingaben erwartet er? Welche Entscheidungen darf er treffen?
Dazu gehören auch Grenzen. Ein Service-Agent darf beispielsweise Informationen vorbereiten, ohne automatisch eine vertragliche Entscheidung treffen zu dürfen. Ein Sales-Agent kann ein Angebot vorbereiten, ohne Preisfreigaben selbst zu erteilen.
Je eindeutiger diese Verantwortung beschrieben ist, desto leichter lassen sich Routing, Berechtigungen, Tests und spätere Änderungen kontrollieren.
KONTEXT GEZIELT ÜBERGEBEN
Vertrauenswürdige Daten weitergeben – nicht das Gewicht des ganzen Systems.
Ein Handoff zwischen Agenten sollte nicht die komplette Gesprächshistorie und alle verfügbaren Systeminformationen weiterreichen. Der nächste Agent braucht nur den Kontext, der für seine eigene Entscheidung relevant ist.
Idealerweise wird die Übergabe deshalb strukturiert: bestätigte Kundendaten, bereits getroffene Entscheidungen, relevante Referenzen und die noch offene Aufgabe. Der Specialist Agent kann anschließend gezielt weitere Daten abrufen, wenn sie wirklich benötigt werden.
Das reduziert Context Pollution und macht gleichzeitig nachvollziehbarer, welche Information eine Entscheidung tatsächlich beeinflusst hat.
Dabei zählt nicht nur die Menge der Daten. Auch Herkunft, Aktualität und Berechtigung müssen klar sein. Ein kleiner, verlässlicher Kontext ist für einen Agenten wertvoller als ein großer Kontext, dessen Bedeutung nicht eindeutig ist.
ARCHITEKTUR SCHRITTWEISE AUFBAUEN
Schritt für Schritt aufbauen – statt den Monolithen einfach zu verteilen.
Eine Multi-Agent-Architektur sollte aus realen Verantwortungsgrenzen entstehen. Nicht aus dem Wunsch, möglichst viele Agenten zu haben.
Mit einer klaren Aufgabe starten
Zuerst festlegen, welche konkrete Arbeit getrennt werden soll und warum ein eigener Agent dafür sinnvoll ist.
Den Orchestrator klein halten
Routing und Zuständigkeit gehören in den Orchestrator – nicht die komplette Fachlogik.
Tools gezielt begrenzen
Ein Agent sollte nur die Actions und Systeme kennen, die er für seine Aufgabe benötigt.
Handoffs explizit machen
Definieren, welche Informationen und offenen Punkte beim Wechsel zum nächsten Agenten übergeben werden.
Context bewusst reduzieren
Nicht die gesamte Historie kopieren, sondern nur bestätigte und relevante Informationen weiterreichen.
Fehler lokal begrenzen
Ein Fehler in einem Specialist Agent sollte nicht automatisch die gesamte Multi-Agent-Kette destabilisieren.
Evaluation pro Agent ermöglichen
Qualität und Verhalten dort messen, wo die fachliche Entscheidung tatsächlich getroffen wird.
Betrieb von Anfang an mitdenken
Monitoring, Berechtigungen, Eskalation und Ownership gehören zur Architektur – nicht erst zum Go-live.
MEHR AGENTEN LÖSEN NICHT AUTOMATISCH MEHR PROBLEME
Wann Multi-Agent-Systeme selbst zur neuen Komplexität werden.
Eine schlechte Multi-Agent-Architektur kann schwieriger zu betreiben sein als der ursprüngliche Monolith. Das passiert vor allem dann, wenn Agenten ähnliche Verantwortungen besitzen oder ständig Kontext untereinander weiterreichen müssen.
Unklare Zuständigkeiten führen zu unnötigen Schleifen: Agent A delegiert an Agent B, Agent B erkennt sich nicht als zuständig und gibt die Aufgabe zurück. Aus einer fachlichen Entscheidung wird ein Routing-Problem.
Auch zu viele kleine Agenten können schaden. Wenn jeder minimale Prozessschritt einen eigenen Agenten erhält, steigt die Zahl der Handoffs, Schnittstellen und Fehlerpunkte – ohne dass fachliche Verantwortung klarer wird.
Die richtige Granularität liegt deshalb zwischen den Extremen: groß genug, damit ein Agent eine sinnvolle fachliche Aufgabe vollständig bearbeiten kann, aber klein genug, damit Kontext, Tools und Verantwortung beherrschbar bleiben.
Multi-Agent ist kein Selbstzweck. Die Architektur ist dann besser, wenn sie Entscheidungen verständlicher, Tests gezielter und den Betrieb robuster macht.
MONOLITH VS. MULTI-AGENT
Das Multi-Agent-Modell aus Sicht des Betriebs denken.
Die eigentliche Verbesserung liegt nicht darin, dass mehrere Agenten existieren. Sie liegt darin, dass Kontext, Verantwortung und Fehlerbereiche bewusst getrennt werden.
| Thema | Monolithischer Agent | Multi-Agent-Architektur |
|---|---|---|
| Kontext | Viele Instruktionen, Tools und Fachbereiche gleichzeitig sichtbar | Jeder Agent erhält nur den für seine Aufgabe relevanten Kontext |
| Tool-Auswahl | Ein Agent muss zwischen vielen ähnlichen Actions unterscheiden | Tools werden pro Verantwortung gezielt begrenzt |
| Routing | Fachliche Erkennung und Bearbeitung passieren im selben Agenten | Orchestrator entscheidet zuerst über die Zuständigkeit |
| Verantwortung | Zuständigkeiten liegen implizit im Prompt | Jeder Specialist Agent besitzt einen klar definierten Auftrag |
| Fehlerwirkung | Änderungen oder Fehlentscheidungen können viele Bereiche gleichzeitig beeinflussen | Fehler und Änderungen lassen sich stärker auf einen Verantwortungsbereich begrenzen |
| Tests | Breite End-to-End-Tests für viele Fähigkeiten gleichzeitig | Routing, Specialist Agents und Handoffs können gezielter getestet werden |
| Betrieb | Ursachen sind bei komplexem Verhalten schwer auseinanderzuhalten | Monitoring kann Routing, Agenten und Übergaben getrennt beobachten |
Die beste Architektur ist nicht zwangsläufig die mit den meisten Agenten. Sie ist diejenige, bei der Verantwortungsgrenzen im Verhalten des Systems tatsächlich sichtbar werden.
MESSBARER BETRIEB
Die Architektur sollte in den Kennzahlen sichtbar werden.
Wenn Agenten bewusst getrennte Aufgaben übernehmen, sollte sich diese Trennung auch beobachten lassen. Sonst bleibt die Architektur lediglich ein Diagramm.
Neben klassischen Qualitätsmetriken lohnt sich deshalb ein Blick auf die Übergänge zwischen Agenten: Wie häufig wird geroutet? Wie oft muss ein Agent weitergeben? Wo entstehen Schleifen? Welche Specialist Agents benötigen besonders viel Kontext? Wo treten Fallbacks oder menschliche Eskalationen auf?
Solche Kennzahlen helfen nicht nur beim Monitoring. Sie zeigen auch, ob die gewählte Aufteilung sinnvoll ist. Wenn fast jede Anfrage mehrere Agenten durchlaufen muss, sind die Verantwortungsgrenzen möglicherweise zu fein. Wenn ein Specialist Agent ständig zusätzliche Tools oder Kontext benötigt, ist seine Rolle möglicherweise falsch geschnitten.
- Routing-Qualität und Fehlrouting
- Handoffs pro Anwendungsfall
- Schleifen oder wiederholte Delegationen
- Context-/Token-Aufwand pro Agent
- Erfolgsquote pro Specialist Agent
- Fallbacks und menschliche Eskalationen
- Latenz über die gesamte Agentenkette
Eine gute Multi-Agent-Architektur reduziert nicht nur technische Komplexität. Sie macht Verantwortung auch im Betrieb messbar.
PASSEND WEITERLESEN
Weitere Einblicke rund um Agentforce, KI und Salesforce-Architektur.
Die Architektur ist nur der Anfang. Diese Perspektiven führen von der Datenbasis über den kontrollierten Piloten bis zur belastbaren Plattformentscheidung.
Agentforce-Pilot: Vom Prototyp zum sicheren Betrieb
Ein funktionierender Prototyp zeigt, dass etwas technisch möglich ist. Ein guter Pilot geht weiter: Er prüft Nutzen, Daten, Berechtigungen, Grenzen, Übergaben und Betrieb unter realistischen Bedingungen. Am Ende sollte deshalb nicht nur „funktioniert“ stehen, sondern eine belastbare Entscheidung: produktiv setzen, gezielt nachbessern oder bewusst stoppen.
Beitrag lesen
Datenbasis für KI: Was Agentforce und Data 360 wirklich brauchen
Agentforce und Data 360 funktionieren nur mit Daten, deren Bedeutung, Qualität und Nutzung klar genug für den konkreten Anwendungsfall sind. Vollständigkeit allein reicht dafür nicht. Entscheidend ist, welche Daten einen Prozess wirklich beeinflussen, wer sie verantwortet und wie verlässlich sie im Betrieb genutzt werden können.
Beitrag lesen
Salesforce Standard oder Custom? Eine Entscheidung mit Augenmaß
Standard, Low-Code oder Custom: Die technisch einfachste Lösung ist nicht automatisch die beste. Entscheidend ist, welche Variante den fachlichen Bedarf erfüllt und auch später noch verständlich, testbar und wartbar bleibt. Der Vergleich sollte deshalb nicht nur auf Entwicklungsaufwand schauen, sondern auch auf Abhängigkeiten, Berechtigungen, Betrieb und spätere Änderungen.
Beitrag lesen