Agentic Loops Production: Welches Framework hält 100 Concurrent Users?

Pexon Consulting | 9 Min. Lesezeit | 01.06.2026

TL;DR

Agentic Loops Production scheitert selten am Modell, sondern an Framework-Limits. Unser 100-User-Benchmark mit LangGraph, AutoGen, CrewAI und Semantic Kernel zeigt: Nur zwei halten produktive Last ohne Token-Explosion. Pexon Consulting betreibt Agent-Stacks für Versicherer und Mittelstand-IT. Dieser Artikel liefert konkrete Zahlen zu Concurrency, Token-Budget-Management, State-Persistenz und den fünf häufigsten Failure-Modes.

Warum Single-User-Demos lügen

Wir sehen das Muster in fast jedem Kundengespräch: Ein Team baut einen Agent-Loop auf dem MacBook, jagt fünf Test-Prompts durch und meldet „Production-Ready“ an die Geschäftsführung. Drei Wochen später, beim ersten echten Pilot mit 40 Sachbearbeitern, sterben die Pods im 20-Minuten-Takt. Tool-Calls hängen, Tokens explodieren, Kosten laufen aus dem Ruder.

Der Grund ist immer derselbe — Agent-Frameworks werden für Demos optimiert, nicht für 100 parallele Conversations mit unbekannter Länge. Ein Engineering-Talk mit Stepan Rutz brachte uns dazu, das systematisch zu messen statt aus dem Bauch zu argumentieren. Die Lücke zwischen „läuft auf dem Laptop“ und „hält Versicherungsschaden-Bearbeitung im Live-Betrieb“ ist größer, als die meisten Framework-Marketing-Seiten zugeben.

Eine konkrete Zahl aus unseren Projekten: Bei einem Mittelstandskunden im Manufacturing kostete der erste produktive Monat 3.400 EUR statt der prognostizierten 800 EUR — weil das Framework keinen Token-Cap pro Loop hatte und ein einziger Tool-Call-Fehler eine 80.000-Token-Endlosschleife auslöste. Genau solche Failure-Modes will dieser Benchmark sichtbar machen.

Unser Benchmark-Setup

Bevor wir Zahlen liefern, hier die Bedingungen — sonst sind die Ergebnisse Marketing.

Hardware & Stack:

• Azure Kubernetes Service (AKS), 3 Pods (4 vCPU / 8 GB)
• LLM: Claude Sonnet 4 via Anthropic API (Tier 2: 1.000 RPM, 80k TPM)
• Vector Store: Azure AI Search (Standard S2)
• State Store: PostgreSQL Flexible Server (4 vCPU, async pool)
• Load: 100 Concurrent Users über 30 Minuten, jede Conversation 5 Turns

Workload-Profil: Sachbearbeiter-Use-Case (Schaden klassifizieren, Dokumente abfragen, Folgefragen). Pro Turn 2-4 Tool-Calls (RAG-Suche, Datenbank-Lookup, Klassifikation). Erwartete Latenz pro Turn: unter 12 Sekunden p95.

# locust load test — vereinfacht
from locust import HttpUser, task, between

class AgentUser(HttpUser):
    wait_time = between(2, 5)

    @task
    def conversation(self):
        session = self.client.post("/agents/start").json()
        for prompt in load_test_prompts():  # 5 Turns
            self.client.post(
                f"/agents/{session['id']}/turn",
                json={"message": prompt},
                timeout=30,
            )

Gemessen wurden: p50/p95/p99-Latenz pro Turn, Token-Verbrauch je Conversation, Pod-Restarts, Tool-Call-Fehlerquote und Kosten pro 1.000 Conversations. Der komplette Benchmark-Code liegt intern — wir teilen ihn auf Anfrage im Workshop-Setup.

Agentic Loops Production unter Last — was zuerst bricht

Die kurze Antwort: AutoGen und CrewAI brechen früher, als ihre GitHub-READMEs vermuten lassen. Beide haben Threading-Modelle, die für Multi-Agent-Konversationen in einem Prozess optimiert sind, nicht für viele parallele User-Sessions in einem Web-Backend.

LangGraph nutzt asyncio nativ — jede Tool-Call-Iteration ist ein Coroutine-Step. Damit skaliert es genau so gut wie ein normaler FastAPI-Service. Semantic Kernel ist solide bis ~80 User, dann beginnt der Plugin-Loader (der bei jedem Call die Tool-Definitionen reflectet) zum Bottleneck zu werden.

AutoGen v0.4 hat das Async-Modell zwar nachgezogen, aber GroupChat und RoundRobinGroupChat synchronisieren intern Listen-State — bei 50 parallelen Sessions sehen wir Race Conditions im Message-History-Append. CrewAI nutzt Python-Threading, was den GIL-Overhead direkt sichtbar macht. Bei 30 Concurrent Users steigt die p95 von 7s auf 19s.

Unsere klare Empfehlung: Wenn Sie >50 Concurrent User-Sessions planen, ist LangGraph aktuell die einzige Wahl, die nicht zwei Quartale später teure Rewrites erzwingt. Semantic Kernel ist eine valide Option im .NET-Umfeld oder bei Microsoft-Enterprise-Stack.

Token-Budget-Management — der unsichtbare Kostenfaktor

Das größte Production-Risiko ist nicht Latency, sondern Tokens. Ein Agent, der seine Stop-Condition nicht sauber prüft, kann pro Conversation 80.000 statt 8.000 Tokens verbrauchen — das ist Faktor 10 bei den Kosten. Bei Claude Sonnet 4 (3 USD/Mio Input, 15 USD/Mio Output) reden wir über 0,18 EUR statt 0,02 EUR pro Conversation. Auf 10.000 Conversations/Monat hochgerechnet: 1.800 EUR statt 200 EUR.

Wir raten aktuell davon ab, Agents ohne harten Token-Cap pro Loop in Produktion zu nehmen. Die meisten Frameworks bieten das nicht out-of-the-box, deshalb wrappen wir den LLM-Call:

class TokenBudgetExceeded(Exception):
    pass

class BudgetedLLM:
    def __init__(self, llm, max_tokens_per_loop: int = 12_000):
        self.llm = llm
        self.budget = max_tokens_per_loop
        self.used = 0

    async def invoke(self, messages, **kwargs):
        if self.used >= self.budget:
            raise TokenBudgetExceeded(
                f"Loop-Budget {self.budget} überschritten — Abbruch"
            )
        response = await self.llm.ainvoke(messages, **kwargs)
        self.used += response.usage.total_tokens
        return response

Drei Patterns reduzieren den Token-Verbrauch im Loop zusätzlich:

1. Sliding-Window-Memory statt vollständiger History — die letzten 6 Turns sind in 90 % der Fälle ausreichend
2. Summarization-Checkpoints alle 10 Turns für lange Conversations (Customer-Support-Threads)
3. Tool-Result-Truncation — RAG-Ergebnisse auf Top-3 Chunks begrenzen statt Top-10, das spart bis zu 4.000 Input-Tokens pro Call

In unseren Tests halbierte die Kombination aus diesen drei Patterns die Token-Kosten gegenüber dem LangGraph-Default um 47 %.

State-Persistenz — wenn ein Pod stirbt

Production heißt: Ein Pod kann jederzeit sterben. Kubernetes-Rolling-Update, OOM-Kill, Node-Drain. Wenn die Conversation-State nur im Pod-Memory liegt, verliert der User mitten im Loop seinen Kontext und muss von vorne anfangen. Das ist in einem Sachbearbeiter-Tool ein No-Go.

LangGraph macht das gut mit dem Checkpointer-Pattern. Jeder Graph-Node persistiert seinen State automatisch — bei einem Pod-Restart kann der Loop von der letzten Checkpoint-Position weiterlaufen.

from langgraph.checkpoint.postgres import AsyncPostgresSaver

checkpointer = AsyncPostgresSaver.from_conn_string(
    "postgresql://agent:***@postgres:5432/agent_state"
)
graph = workflow.compile(checkpointer=checkpointer)

# pro User-Session eine eindeutige thread_id
config = {"configurable": {"thread_id": user_session_id}}
result = await graph.ainvoke(input_state, config=config)

Redis vs. Postgres: Für High-Throughput-Workloads (>200 conversations/sec) ist Redis schneller, verliert aber bei Node-Failure State, der nicht persistiert wurde. Postgres ist langsamer (Faktor 3 in unseren Tests), dafür ACID. Unsere Default-Empfehlung für Mittelstand-Workloads: Postgres mit Connection-Pool (20 Connections pro Pod). Redis nur, wenn Sie wirklich Sub-100ms-Latenz auf State-Reads brauchen — bei Agent-Loops mit 5-10s LLM-Calls ist das fast nie der Fall.

AutoGen und CrewAI haben kein vergleichbares Checkpointer-Konzept. Sie müssen State-Serialisierung selbst bauen, was in unseren Audits der häufigste Grund für Production-Outages ist.

Die fünf Wege, wie Agents in Produktion sterben

Bei jedem Pexon-Production-Audit für Agent-Stacks sehen wir dieselben fünf Failure-Modes. In dieser Reihenfolge der Häufigkeit:

Failure-Mode 3 ist der unterschätzte. Wenn der Anthropic-API ein 429 zurückgibt und Ihr Framework standardmäßig dreimal retryt, entsteht bei 100 Concurrent Users ein Retry-Storm, der die Rate-Limit-Situation weiter verschärft. Wir konfigurieren grundsätzlich einen Circuit Breaker (z.B. tenacity mit Stop-After-Attempt-2 plus Exponential Backoff von mindestens 4 Sekunden) auf den LLM-Client.

Failure-Mode 1 ist der teuerste. Ein einziger Endlos-Loop bei einem Kunden kostete 280 EUR in 40 Minuten, bis das Monitoring anschlug. Die Anthropic-Rate-Limit-Dokumentation ist hier Pflichtlektüre für jeden, der Agents in Produktion betreibt.

Unsere Empfehlung — welches Framework für welchen Use Case

Es gibt keinen einzigen Gewinner. Die Wahl hängt vom Use Case und vom bestehenden Stack ab:

Was wir aktuell nicht empfehlen: OpenAI Swarm in Production. Das Repo ist explizit als experimental markiert, ohne State-Management und ohne Checkpointer. Wer das deployed, baut sich eine technische Schuld, die spätestens beim ersten Kubernetes-Rolling-Update zurückkommt.

Eine zweite klare Position: Wenn Ihr Team noch keine Production-Erfahrung mit Agents hat, fangen Sie mit einem einzigen Framework an — nicht mit drei parallelen Stacks. Die Komplexität liegt selten im Framework selbst, sondern in Observability, Cost-Monitoring und Fallback-Mechanismen. Ein Stack, sauber instrumentiert, ist mehr wert als drei halb-fertige Experimente.

Häufig gestellte Fragen

Welches Framework eignet sich für Agentic Loops Production mit über 100 Concurrent Users?

Aus unseren Benchmark-Daten hält aktuell nur LangGraph 100+ parallele User-Sessions ohne Degradation. Semantic Kernel kommt auf ca. 80 stabil, danach wird der Plugin-Loader zum Bottleneck. AutoGen und CrewAI brechen früher und sind für diese Last in der aktuellen Version nicht produktionsreif.

Was kostet ein Agent-Loop pro Request in der Produktion?

Kommt drauf an, aber unsere Range liegt bei 0,02-0,20 EUR pro Conversation mit Claude Sonnet 4. Der Faktor 10 entsteht durch Token-Cap-Disziplin: Ohne Hard-Cap und ohne Sliding-Window-Memory rutschen Conversations schnell in den 80.000-Token-Bereich. Mit den Patterns aus diesem Artikel liegt eine 5-Turn-Conversation typisch bei 0,03-0,05 EUR.

LangGraph vs. AutoGen vs. CrewAI — was ist der praktische Unterschied?

LangGraph ist ein Graph-Orchestrator (Nodes & Edges), async-nativ, mit Checkpointer-Pattern für State-Persistenz. AutoGen ist auf Multi-Agent-Konversationen optimiert — mehrere LLM-Agents reden miteinander. CrewAI nutzt ein Role-Based-Pattern (Crew aus Agents mit Rollen), ist schnell zu prototypen, aber Threading-basiert. Für Production-Single-Agent-Loops ist LangGraph der bessere Schnitt, AutoGen glänzt bei klassischen Multi-Agent-Forschungs-Setups.

Brauche ich Kubernetes für Agentic Loops in Production?

Nicht zwingend, aber sobald Sie über 30 Concurrent Users hinausgehen oder echte Verfügbarkeits-SLAs zusagen, ist Kubernetes die pragmatischste Antwort. Horizontal-Pod-Autoscaler reagiert auf Request-Last, Rolling-Updates ermöglichen Zero-Downtime-Deploys, und der Checkpointer macht Pod-Restarts transparent für den User.

Wie messe ich die Performance meines Agent-Stacks systematisch?

Drei Metriken-Gruppen: (1) Latency p50/p95/p99 pro Turn und pro Conversation, (2) Token-Verbrauch pro Conversation als Histogramm — nicht nur Durchschnitt, weil die Tail-Conversations die Kosten dominieren, (3) Tool-Call-Fehlerquote nach Fehler-Typ. OpenTelemetry mit dem langsmith-Exporter oder Phoenix von Arize liefern das out-of-the-box. Ohne Observability ist jeder Production-Launch ein Blindflug.

Nächster Schritt

Wenn Sie aktuell vor der Framework-Entscheidung stehen oder einen bestehenden Agent-Stack auf Production-Reife prüfen wollen: Wir machen das im 6-Wochen-Pilotprojekt für Generative AI konkret — inklusive Benchmark gegen Ihren echten Workload, Token-Cost-Analyse und Production-Readiness-Audit.

Verwandte Themen