Multi-Agent-Systeme brauchen drei Schichten Sichtbarkeit. System-Health, Run-Quality und Workflow-State. Wir fahren dafuer einen Stack aus Sentry, Langfuse und LangGraph. Drei Tools, drei klar getrennte Aufgaben, keiner kann das Problem des anderen. Hier wie das bei uns zusammenspielt und warum genau diese Kombination.
Multi-Agent-Systeme haben eine Eigenschaft die jeder unterschaetzt der sie zum ersten Mal in Production sieht. Ein einzelner LLM-Call ist transparent. Du gibst einen Prompt rein, du bekommst eine Antwort raus, du siehst beides. Eine Pipeline aus acht Agenten die ueber vier Tage zusammenarbeitet ist eine Black Box mit acht Tueren, von denen jede andere Annahmen darueber hat was die anderen sieben gerade machen.
Wir betreiben eine Fleet aus rund 40 Worker-Agenten verteilt auf acht Spezial-Fleets. Eine Pipeline die MCP-Server entwirft, baut, reviewt und published. Ein Memory-Produkt-Squad der unser SaaS-Memory permanent verbessert. Eine Academy-Content-Pipeline. SaaS-Operations. Ein Chief-of-Staff-Orchestrator als Layer-2 ueber den Fleet-CEOs. Alles auf dem Anthropic Claude Agent SDK in TypeScript, taeglich per Cron.
Die Frage ist nicht wie das technisch skaliert. Die Frage ist wie man die Qualitaet ueber Zeit hochhaelt. Drei Tools beantworten die Frage in unserer Architektur. Sentry, Langfuse und LangGraph. Jedes loest ein anderes Problem, keines kann das Problem des anderen.
Was Multi-Agent-Setups wirklich brauchen
Drei Schichten muessen sichtbar sein, sonst lernt man nichts.
Die erste Schicht ist System-Health. Welcher MCP-Server ist langsam, welcher Tool-Call gibt silent JSON-RPC-Errors zurueck statt Exceptions, wo ist der Latenz-Spike der die Cron-Runs reisst. Das ist klassische APM-Arbeit, nur eben ueber LLM-Calls und MCP-Server statt nur Web-Requests.
Die zweite Schicht ist Run-Quality. Hat der Reviewer-Agent die echten Bugs gefunden oder nur Boilerplate-Findings produziert. Hat der Architect einen ausfuehrbaren Plan geliefert oder einen schoenen Text. Bei einem einzelnen Test-Run kann das ein Mensch beurteilen. Bei 40 Workern und 30 Tagen muss das ein System koennen.
Die dritte Schicht ist Workflow-State. Wenn ein Build-Subprocess nach 13 Minuten crasht, willst du nicht den ganzen Build neu starten. Du willst ab dem letzten guten Checkpoint resumen. Wenn ein Tester einen Approval-faelligen Output liefert, willst du Human-in-the-Loop ohne dass du dafuer Custom-Code baust.
Diese drei Schichten sind orthogonal. Tools die alle drei machen wollen, machen alle drei mittelgut. Tools die eine Schicht erstklassig machen, kombinieren sich zu einem Stack der besser ist als die Summe.
Sentry fuer Errors und MCP-Server-Health
Sentry verfuegt seit April 2026 ueber native MCP-Server-Auto-Instrumentation. Eine Zeile Code pro MCP-Server, und du bekommst sofort ein Dashboard mit den meistgenutzten Tools, der Latenz-Distribution pro Tool, der Error-Rate, der Client-Segmentierung und der Transport-Distribution. Bei fuenf Production-MCP-Servern ist das fuenf Zeilen Code fuer einen Health-Layer den man sonst Wochen baut.
Das Wichtigste daran. Das Anthropic MCP SDK behandelt Errors als JSON-RPC-Response statt als Exception. Wenn ein Tool intern crasht, sieht der Caller einen success-Status mit error-content im JSON. Klassische Stack-Trace-Tools sehen das nicht. Sentry sieht es.
Auf dem Agent-Layer macht Sentry Auto-Instrumentation fuer das Anthropic SDK, schreibt Tool-Use-Loops als nested Spans in den Trace und traced Token-Counts auch dann wenn Pricing pauschal ist. Token-Volume bleibt ein wertvoller Quality-Proxy auch wenn nicht pro Token abgerechnet wird. Wenn ein Architect ploetzlich vierfach mehr Tokens braucht ohne dass der Output besser wird, ist das ein Drift-Signal.
Der Stack ist OpenTelemetry-konform und implementiert die GenAI Semantic Conventions v1.36. Heisst, jedes andere OTel-Tool kann die gleichen Spans lesen. Kein Lock-In auf Sentry-spezifische Span-Formate.
Langfuse fuer Run-Quality, Evals und Prompt-Management
Langfuse ist die produktive Antwort auf die Frage ob die Agenten ueber Zeit besser oder schlechter werden. MIT-lizenziert, Self-Host moeglich, dedizierte Claude Agent SDK Integration in der TypeScript-SDK v4.
Drei Capabilities die in der Praxis den Unterschied machen.
Tracing. Multi-Agent-Calls werden als Agent Graphs visualisiert, nicht nur als linearer Span-Tree. Wer wen aufruft, welche Tool-Calls dazwischen liegen, wo der Trace abbricht, wo der Token-Verbrauch explodiert.
Evals via LLM-as-Judge. Wir pflegen Goldsets, also kuratierte Test-Suiten mit erwarteten Outputs, und lassen sie bei jeder Code-Aenderung an einem Agent automatisch durchlaufen. Custom Evaluators scoren ob der Agent die erwarteten Findings geliefert hat. Das macht Run-Quality ueber Zeit messbar statt subjektiv. Wenn der Reviewer-Agent vor zwei Wochen 18 von 20 Cases gecatched hat und heute nur noch 14, weisst du dass etwas gedriftet ist und kannst gezielt nach der Ursache suchen.
Prompt-Management mit Versionierung. Prompts leben nicht hardcoded in Source-Files. Versioniert, Labels fuer A/B-Tests, also prod-a gegen prod-b parallel laufen, Performance pro Version automatisch getrackt nach Latency, Tokens und Eval-Score. Rollback ist ein Klick, nicht ein Git-Revert.
Self-Host laeuft auf Docker plus Postgres plus ClickHouse, also genau die Toolchain die wir auf unserem AI-Server eh fahren. Lizenz ist MIT, alle Produkt-Features kommen ohne Limits, nur die Enterprise-Module fuer SCIM, Audit-Log und Data-Retention-Policies brauchen Lizenz-Schluessel.
LangGraph fuer Stateful-Workflows
LangGraph nutzen wir selektiv, nicht ueberall. Konkret in den Sequenzen wo ein Workflow ueber mehrere Subprocess-Calls und mehrere Stunden laeuft und ein Crash mittendrin nicht zu einem kompletten Re-Run fuehren darf. Die MCP-Factory-Pipeline ist der klassische Use-Case. Architect schreibt einen Plan, Builder baut den Code, Reviewer findet die Findings, Tester macht den Live-Smoke. Vier Subprocesses, mehrere Stunden, viele Stellen wo etwas Externes brechen kann. Ein npm-install fail, ein git-clone-Timeout, ein MCP-Tool-Call der haengt.
Mit LangGraph als State-Graph mit Postgres-Checkpointing wird der Workflow durable. State, also Plan-Pfad, Build-Slug, Findings, lebt in der StateGraph, jeder Node-Output wird gecheckpointed. Crash bei Schritt drei von vier heisst Resume ab letztem guten Checkpoint, nicht Komplett-Restart. Tester-Output PARTIAL triggert interrupt() fuer manuelle Approval. Human-in-the-Loop ohne dass wir das selber bauen.
Wir fahren LangGraph mit einem Subprocess-Adapter. Jeder LangGraph-Node spawnt unseren bestehenden Worker als Subprocess statt einen LangChain-ChatModel-Call zu machen. Das hat einen wichtigen Effekt. Unsere Worker bleiben unveraendert auf dem Anthropic Claude Agent SDK, Pricing-Architektur bleibt erhalten, kein Wechsel auf token-basiertes Billing. LangGraph orchestriert den Workflow, die Worker bleiben sie selbst.
Der Adapter ist ueberschaubar. Etwa 80 Zeilen TypeScript. Postgres-Checkpointer ist production-ready und legt drei Tabellen in einem eigenen Schema an. MCP-Adapters von LangChain verbinden bestehende MCP-Server transparent als LangChain-Tools, also auch hier kein Rewrite.
LangGraph bringt einen Trade-off mit. Proprietaere Lizenz, also Lock-In-Risiko falls die Pricing-Strategie sich aendert. Dieses Risiko nehmen wir bewusst nur dort in Kauf wo der Resume-Wert echten ROI liefert. Fuer 80 Prozent unserer Workflows reicht der Claude Agent SDK alleine.
Wo sich der Stack ueberschneidet
Eine Stelle, eine Loesung. Sentry und Langfuse instrumentieren beide LLM-Calls via OpenTelemetry. Wenn Sentry zuerst initialisiert, was es per Default macht, schluckt es die Langfuse-Spans. Loesung ist dokumentiert. Ein gemeinsamer TracerProvider, beide SpanProcessor anhaengen. Eineinhalb Stunden Setup, dann sehen beide Tools ihre eigenen Spans.
Wer das nicht vorab weiss, debuggt zwei Tage. Wer es weiss, hat es im Bootstrap-File und vergisst es.
Was den Stack zusammenhaelt
Drei Eigenschaften die wir bei der Tool-Wahl gewichtet haben.
Open-Standards-First. Sentry und Langfuse sind beide OTel-konform mit GenAI Semantic Conventions. Spans wandern ohne Code-Change. Wer diese Spans morgen zu einem dritten Sink schicken will, also Honeycomb, Datadog oder eigenes System, braucht keinen Rewrite.
Self-Host wenn moeglich. Langfuse ist self-hosted auf eigener Infrastruktur. Sentry-Cloud nutzen wir wegen Convenience, aber Sentry ist ebenfalls self-hostable. Daten-Souveraenitaet bleibt steuerbar.
Pauschal-Pricing respektieren. Unsere Pricing-Architektur ist pauschal, nicht pro Token. Tools die uns zwingen wuerden auf token-basiertes Billing umzusteigen waeren echte Kostentreiber. Der Subprocess-Adapter-Pattern haelt LangGraph kompatibel mit dieser Architektur.
Lehren die fuer alle gelten die Multi-Agent bauen
Aus dem Stack-Bau, nicht spezifisch fuer eine Domain.
Token-Volume ist auch bei pauschalem Pricing ein wichtiger Quality-Proxy. Ploetzlich vierfach mehr Tokens fuer den gleichen Output ist ein Drift-Signal, egal ob man dafuer zahlt oder nicht. Wer das nicht traced, sieht den Drift erst Wochen spaeter wenn der Output spuerbar schlechter wird.
MCP-Server-Errors als JSON-RPC-Response statt Exception sind eine spezielle Klasse von Bugs die klassische APM-Tools nicht catchen. Hier gibt es eine Toolkette die das catched, sie zu nutzen kostet Minuten und gibt Tage zurueck.
Stateful-Workflow mit Resume macht erst ab einer gewissen Komplexitaet Sinn. Single-Step-Agents brauchen das nicht. Multi-Step-Workflows ueber mehrere Stunden mit echten externen Dependencies wie npm, git oder fremde APIs profitieren extrem davon. Die Schwelle fuer den Switch ist hoeher als die meisten Tutorials suggerieren. Wer LangGraph oder ein vergleichbares Orchestrator-Tool zu frueh einbaut, hat mehr Komplexitaet im Stack als Mehrwert auf der Strasse.
Was der Stack nicht macht
Er macht nicht die Architektur-Entscheidungen. Er macht nicht die Prompt-Engineering-Arbeit. Er macht nicht die Domain-Modellierung. Er macht sichtbar was passiert. Was du daraus lernst, ist deine Arbeit.
Sentry plus Langfuse plus LangGraph ist drei Tools fuer drei Probleme. Wer alle drei Probleme hat, gewinnt mit dem Stack. Wer nur eines hat, sollte nur eines einbauen. Tooling-Sprawl ist ein echtes Anti-Pattern in Solo-Setups und kleinen Teams.
Bei uns laufen alle drei Probleme gleichzeitig durch die Fleet. Deswegen alle drei Tools.
