Agent Routing in LangGraph: Conditional Edges, Supervisor, Swarm

Pexon Consulting | 10 Min. Lesezeit | 10.06.2026

TL;DR

Agent Routing LangGraph ist die Architektur-Entscheidung, die jeder produktive Multi-Agent-Pipeline treffen muss: Wie kommt eine Anfrage zum richtigen Subagent oder Tool? Pexon Consulting nutzt drei Standard-Pattern — Conditional Edges für einfache Verzweigungen, Supervisor-Pattern für hierarchische Multi-Agent-Setups, Swarm-Pattern für peer-to-peer-Handoffs. Hier die Code-Beispiele und der Entscheidungsbaum, welches Pattern wann passt.

Warum Routing das eigentliche Multi-Agent-Problem ist

Wir hören das aktuell in fast jedem Engineering-Erstgespräch: Das Team hat eine LangGraph-Pipeline mit einem ReAct-Agent gebaut, der funktioniert gut. Jetzt soll der nächste Schritt sein, mehrere spezialisierte Agents nebeneinander zu betreiben — einer für CRM-Fragen, einer für ERP-Fragen, einer für Wissensdatenbank-Lookups. Die Frage: Wie entscheidet das System, welcher Agent eine Anfrage bekommt.

Naive Antwort: „Wir lassen den ReAct-Agent das machen, der hat ja schon Tool-Use.“ Funktioniert für 5-15 Tools. Bricht ab 25-40 Tools, weil das LLM bei zu vielen Optionen die Wahl nicht mehr zuverlässig trifft, und weil die Kontext-Verarbeitung jedes Tools (Schema, Beschreibung) Tokens kostet. Bei 50 oder 100 Tools wird das Routing zum Engpass.

Die saubere Antwort heißt strukturiertes Routing — und LangGraph bietet vier Pattern unterschiedlicher Komplexität dafür. Welches du wählst, hängt vom Use-Case ab.

Pattern 1: Conditional Edge — die einfachste Antwort

Conditional Edges sind die Grundlage. Ein Knoten gibt seinen State zurück, eine Routing-Funktion entscheidet, welcher Folge-Knoten als Nächstes läuft.

from langgraph.graph import StateGraph, END
from typing import Literal

def classify_request(state: dict) -> Literal["query_agent", "action_agent"]:
    """Routet basierend auf Anfrage-Typ."""
    last_msg = state["messages"][-1].content
    if any(verb in last_msg.lower() for verb in ["zeige", "finde", "was", "wer"]):
        return "query_agent"
    return "action_agent"

graph = StateGraph(AgentState)
graph.add_node("classify", lambda s: s)
graph.add_node("query_agent", query_agent)
graph.add_node("action_agent", action_agent)
graph.add_conditional_edges("classify", classify_request)
graph.add_edge("query_agent", END)
graph.add_edge("action_agent", END)

Vorteile: einfach, transparent, kein LLM-Call für die Routing-Entscheidung (also schnell und billig). Nachteile: Regel-basierte Routing-Logik ist starr, bei komplexen Anfragen unzuverlässig.

Sinnvoll für: Binäre oder klare 3-Wege-Routing-Entscheidungen, bei denen die Regel-Logik stabil ist (z.B. „Frage vs Aktion“, „Bekannter Kunde vs Neukunde“, „Lesen vs Schreiben“).

Pattern 2: Router-Node mit LLM-Klassifikation

Wenn das Routing nicht regel-basiert klar ist, nutzt du einen Router-Node mit eigenem LLM-Call, der die Anfrage klassifiziert und in die richtige Bahn schickt.

from langchain_anthropic import ChatAnthropic
from pydantic import BaseModel
from typing import Literal

class RoutingDecision(BaseModel):
    target: Literal["crm_agent", "erp_agent", "knowledge_agent"]
    reasoning: str

router_llm = ChatAnthropic(
    model="claude-haiku-4-5",
    temperature=0.0,
).with_structured_output(RoutingDecision)

def router(state: AgentState) -> dict:
    """LLM-basierte Klassifikation der Anfrage."""
    decision = router_llm.invoke([
        {"role": "system", "content": ROUTING_PROMPT},
        {"role": "user", "content": state["messages"][-1].content},
    ])
    return {"routing_decision": decision.target, "reasoning": decision.reasoning}

def route_to_agent(state: dict) -> str:
    return state["routing_decision"]

graph.add_node("router", router)
graph.add_conditional_edges("router", route_to_agent)

Vorteile: Flexibel, robust bei semantisch unterschiedlichen Anfragen. Nachteile: zusätzlicher LLM-Call (Latenz und Kosten), Routing-Qualität hängt von der Prompt-Qualität ab.

Wir nutzen Haiku 4.5 als Router-LLM — günstig, schnell, ausreichend für Klassifikations-Aufgaben mit klaren Kategorien. Bei einem Pilotkunden lag die Router-Genauigkeit nach Prompt-Tuning bei 96,3% korrekter Klassifikation gegen 200 Test-Fälle.

Sinnvoll für: 3-15 mögliche Routing-Ziele mit klaren semantischen Unterschieden, wo regel-basiertes Routing nicht reicht.

Pattern 3: Supervisor-Pattern für hierarchische Teams

langgraph-supervisor (separates Paket) implementiert das hierarchische Multi-Agent-Setup: Ein Supervisor-Agent koordiniert mehrere spezialisierte Subagents, entscheidet zentral, welcher Subagent als Nächstes drankommt, und konsolidiert am Ende die Ergebnisse.

from langgraph_supervisor import create_supervisor
from langgraph.prebuilt import create_react_agent

crm_agent = create_react_agent(model, [search_customer, get_order_history], name="crm")
erp_agent = create_react_agent(model, [check_inventory, create_order], name="erp")
service_agent = create_react_agent(model, [open_ticket, search_kb], name="service")

supervisor = create_supervisor(
    [crm_agent, erp_agent, service_agent],
    model=model,
    prompt=SUPERVISOR_PROMPT,
).compile()

result = supervisor.invoke({
    "messages": [{"role": "user", "content": "Welche offene Bestellung hat Kunde 4711, und wo sind die Artikel verfügbar?"}]
})

Was hier passiert: Der Supervisor klassifiziert die Frage, ruft den CRM-Agent für die Kunden-Bestelldaten, dann den ERP-Agent für Lagerstatus, konsolidiert beide Antworten in einer kohärenten Response.

Vorteile: Saubere Hierarchie, klare Verantwortlichkeiten pro Subagent, einfach erweiterbar. Nachteile: Supervisor-Aufrufe sind teurer als direkte Routing-Calls, weil der Supervisor jeden Turn entscheidet.

Sinnvoll für: 3-8 spezialisierte Subagents mit klar abgegrenzten Verantwortungsbereichen. Klassischer Customer-Support-Stack (CRM + ERP + Knowledge + Tickets) oder F&E-Stack (Konstruktion + Spec + Patent + Prüf).

Pattern 4: Swarm-Pattern für Peer-to-Peer-Handoffs

langgraph-swarm implementiert peer-to-peer Multi-Agent: Es gibt keinen zentralen Supervisor, sondern die Subagents reichen die Anfrage untereinander weiter. Ein Agent erkennt, dass er die aktuelle Anfrage nicht mehr bedienen kann, und übergibt explizit an einen Kollegen.

from langgraph_swarm import create_swarm
from langgraph.prebuilt import create_react_agent
from langchain_core.tools import tool

@tool
def transfer_to_erp(reason: str) -> str:
    """Übergibt an den ERP-Agent, wenn ERP-Zugriff nötig ist."""
    return f"Handoff to ERP: {reason}"

crm_agent = create_react_agent(
    model,
    [search_customer, get_order_history, transfer_to_erp],
    name="crm",
)

erp_agent = create_react_agent(
    model,
    [check_inventory, create_order, transfer_to_crm],
    name="erp",
)

swarm = create_swarm([crm_agent, erp_agent], default_active_agent="crm").compile()

Vorteile: Sehr flexibel, die Subagents entscheiden selbst, wann ein Handoff sinnvoll ist. Kein Single-Point-of-Decision wie beim Supervisor. Skaliert auf viele Subagents ohne Supervisor-Engpass.

Nachteile: Komplexer zu debuggen, weil die Handoff-Logik verteilt ist. Endlosschleifen-Risiko (CRM verweist an ERP, ERP an CRM) — wir bauen Handoff-Counter mit harten Caps ein.

Sinnvoll für: Komplexe Workflows, in denen die Subagents wirklich miteinander interagieren müssen (nicht nur sequenziell aufgerufen werden). Klassischer Use-Case bei einem Banking-Kunden: Mehrere Spezialisten-Agents (KYC, Bonität, Produktauswahl, Compliance), die in beliebiger Reihenfolge konsultiert werden müssen.

Pexon-Entscheidungsbaum: welches Pattern wann

Aus 12+ Multi-Agent-Projekten 2025/2026 unsere Default-Empfehlung:

Bist du bei 1-3 Routing-Zielen mit klarer Regel? → Conditional Edge.

Bist du bei 3-15 Routing-Zielen, regelbasiert nicht klar trennbar? → Router-Node mit Haiku 4.5.

Hast du 3-8 spezialisierte Subagents mit klar getrennten Verantwortungsbereichen, die typisch sequenziell aufgerufen werden? → Supervisor.

Hast du Subagents, die wirklich miteinander reden müssen, mit dynamischen Handoffs? → Swarm.

Bist du unsicher? → Starte mit Router-Node plus einfacher Conditional Edges. Refactor zu Supervisor oder Swarm später, wenn der Bedarf klar ist.

Wir warnen Kunden konsequent vor verfrühter Swarm-Architektur. Bei vielen Projekten haben Teams Swarm gewählt, weil es „modern“ klingt — und dann monatelang an Endlosschleifen, Handoff-Race-Conditions und Debugging-Schmerz gearbeitet, statt sich auf das eigentliche Business-Problem zu konzentrieren. Supervisor reicht in 70-80% der Multi-Agent-Setups, die wir bauen.

Häufig gestellte Fragen

Wie viele Subagents sind sinnvoll in einem Setup?

Aus unseren Projekten: 3-8 ist der Sweet-Spot. Bei mehr als 8 wird der Supervisor-Overhead spürbar, plus die mentale Komplexität für das Engineering-Team steigt schnell. Bei mehr als 10 Subagents fangen wir an, in hierarchische Setups zu splitten — Team-Supervisor pro Sub-Domäne, oberster Master-Supervisor entscheidet welches Team.

Was kostet ein Supervisor-Setup an Modell-Tokens?

Pro Konversations-Turn typisch 1,5-2,5x mehr Tokens als ein einzelner ReAct-Agent, weil der Supervisor-LLM-Call zusätzlich anfällt. Bei Use-Cases mit klarem Routing-Bedarf ist das die Tokens wert. Bei einfachen Use-Cases ist ein einziger Agent günstiger.

Wie debugge ich Routing-Fehler?

Mit MLflow Tracing oder LangSmith. Jeder Routing-Entscheid wird als Span getracked, mit Eingabe, Klassifikations-Output und Begründung. Bei einem Pilotkunden haben wir damit eine Klasse von Fehlrouting-Fällen identifiziert, die bei einer bestimmten Anfrage-Formulierung auftrat, und über Prompt-Tuning behoben. Mehr im MLflow LangGraph Tracing Blog.

Kann ich Supervisor und Swarm mischen?

Theoretisch ja, praktisch selten sinnvoll. Wir haben das in einem Projekt gemacht — Supervisor auf oberster Ebene routet zu drei Sub-Teams, jedes Team intern als Swarm organisiert. Funktional komplex, aber bei sehr großen Multi-Agent-Setups die einzige saubere Antwort.

Was, wenn der Router-Node die falsche Klassifikation trifft?

Wir bauen einen Fall-back-Loop: Wenn der gewählte Agent nach 2-3 Tool-Calls erkennt, dass er die Anfrage nicht bedienen kann, gibt er die Anfrage zurück an den Router mit einer Begründung. Der Router macht eine zweite Klassifikation. Das ist ein konsistentes Recovery-Pattern, das wir in jeden Production-Setup einbauen.

Nächster Schritt

Wenn dein Team gerade Multi-Agent-Architektur in LangGraph plant: Wir machen einen 60-Minuten-Call mit dir und idealerweise einem Senior-Engineer. Du beschreibst die geplante Subagent-Struktur, wir empfehlen das Routing-Pattern und skizzieren das Setup mit Festpreis.

Verwandte Themen