Agenten brauchen ein stabiles Fundament

Im letzten Post haben wir einen Agenten von Grund auf gebaut — ohne Framework, direkt gegen die Anthropic API. Das Ergebnis: ein funktionierender ReAct-Agent mit Calculator und Wikipedia als Tools.

Funktioniert. Aber bei genauerem Hinsehen zeigen sich schnell einige Grenzen:

Bei einem Crash startet der Agent von vorne — es gibt kein Checkpointing. Der Loop ist linear — bedingte Verzweigungen lassen sich zwar mit if/else einbauen, werden aber schnell unübersichtlich, intransparent und schwer wartbar.

Die Tools sind nur für diesen einen Agenten implementiert. Kein anderer Client kann sie nutzen.

Die Frage ist: Was braucht man, damit der Agent über ein Experiment hinauswächst? Die Antwort: Abstraktionen — in Form von Frameworks und Standards. In unserem Fall sind es zwei, die jeweils ein konkretes Problem lösen.

LangGraph: Der Agent als Graph

LangGraph adressiert die Schwachpunkte des manuellen Loops, indem es den Agenten als gerichteten State-Graphen modelliert. Knoten sind Python-Funktionen, Kanten bestimmen den Kontrollfluss, und der typisierte State fließt durch den gesamten Graphen — persistierbar nach jedem Schritt.

[START] → [plan] → [research] → [evaluate]
              ^                       |
              |                  Qualität OK?
              |                  Nein: zurück
              +---------<---------+
                                  Ja: weiter
                                       |
                                  [summarize] → [END]

In Phase 1 war der State eine Python-Liste im Speicher. LangGraph macht daraus ein typisiertes Schema — ein TypedDict, in dem jedes Feld explizit deklariert ist. Das klingt nach mehr Aufwand, ist aber die Voraussetzung für vieles, was folgt. Man definiert das Schema einmal, die Knoten geben zurück, was sie ändern wollen, und LangGraph kümmert sich um den Rest — Persistierung, Merge-Logik, Wiederherstellung.

Checkpointing. Der State wird nach jedem Knoten persistiert. Das ist mehr als ein Sicherheitsnetz für Crashes. Es bedeutet, dass der Agent auf vorherigen Ergebnissen aufbauen kann — eine Folgefrage nutzt den State der ersten Anfrage, ohne die gleichen Tool-Calls nochmal zu machen. Out-of-the-box-Persistenz, die Multi-Turn-Interaktion ermöglicht und gleichzeitig Token und Kosten spart.

Testbarkeit. Weil das Schema der Kontrakt zwischen Knoten ist, kann man jeden Knoten isoliert testen — ohne den gesamten Loop zu mocken. Das wäre mit dem manuellen Loop deutlich aufwändiger.

Transparenter Kontrollfluss. Edges machen den Kontrollfluss sichtbar. Verzweigungen, Zyklen, Abbruchbedingungen sind Struktur — nicht versteckte if/else-Blöcke im Code. Der Research-Agent oben nutzt das: Wenn die Qualität der Recherche nicht reicht, geht er über eine Conditional Edge zurück zum Plan-Knoten und recherchiert mit angepassten Suchbegriffen weiter.

Der Tradeoff: Die Graph-Struktur erfordert eine initiale Einarbeitung. Sie verlangt, den Kontrollfluss des Agenten explizit zu durchdenken. Andererseits schafft sie die Grundlage für alles, was danach kommt — Multi-Agent-Systeme, Tracing, Deployment.

MCP: Ein Standard für Tools

LangGraph löst das Problem auf der Agent-Seite. Aber die Tools sind immer noch direkt in Python implementiert und an einen einzigen Agenten gebunden. Wie macht man Tools wiederverwendbar?

Das Model Context Protocol (MCP) ist ein offener Standard von Anthropic, der definiert, wie LLM-Anwendungen mit externen Tools kommunizieren. Die Analogie “USB-C für AI-Tools” trifft es gut: Der Server deklariert seine Tools einmal. Jeder MCP-kompatible Client — also auch ein Agent — kann sie nutzen, ohne Änderungen am Server.

In der Praxis ist ein MCP-Server ein Python-Script mit wenigen Zeilen:

mcp = FastMCP("Filesystem Server")

@mcp.tool()
def list_directory(path: str = ".") -> str:
    """Listet den Inhalt eines Verzeichnisses auf."""
    ...

mcp.run(transport="stdio")

Die Idee ist dieselbe wie bei REST oder OpenAPI: Ein Standard, der verhindert, dass jede Integration von Null neu gebaut werden muss.

MCP ist noch jung. Breaking Changes zwischen Versionen sind real. Monitoring, Rate Limiting und Auth-Standards sind bei REST und gRPC deutlich ausgereifter. MCP hat Momentum. Ob es sich langfristig durchsetzt, muss sich zeigen. Aktuell führt allerdings kaum ein Weg daran vorbei.

Komposition: Verschiedene Tool-Quellen, ein Interface

Beide Abstraktionen haben eigenständigen Wert. LangGraph bringt Struktur in den Agenten, MCP bringt Standardisierung in die Tools. Zusammen entfalten sie zusätzlichen Wert.

Ein konkretes Beispiel: Ein Agent nutzt gleichzeitig Tools aus drei verschiedenen Quellen — einen MCP-Server über stdio, eine HTTP-API (Tavily Web-Suche) und eine lokale Python-Funktion. Alle drei werden zu LangChain-Tools konvertiert und landen als flache Liste beim Agenten. Der Agent merkt keinen Unterschied.

Das ist der Payoff von Standardisierung: Ein neues Tool hinzufügen heißt eine Funktion schreiben und sie zur Liste hinzufügen. Der Agent muss nicht angefasst werden.

Zwei Erkenntnisse, die geblieben sind

Harte vs. weiche Kontrolle. Vorgaben im System Prompt, wie etwa “Suche zuerst lokal, dann im Web”, sind eine Präferenz, keine Garantie. Jede Query kann diese Anweisung überschreiben — absichtlich oder nicht. Für kritische Abläufe muss die Reihenfolge im Graphen verdrahtet sein, nicht im Prompt. Je wichtiger der Ablauf, desto weniger darf er vom System Prompt abhängen.

State-Updates sind eine Quelle stiller Fehler. In LangGraph gibt jeder Knoten nur die geänderten Felder zurück. Dabei können zwei Dinge schiefgehen, ohne dass der Code einen Fehler wirft: Erstens kann ein Knoten Felder zurückgeben, die im Schema nie definiert wurden — LangGraph ignoriert sie stillschweigend, nichts wird gespeichert. Zweitens bestimmt die Annotation im Schema, ob ein Wert überschrieben oder erweitert wird. Ohne die richtige Annotation gehen Zwischenergebnisse verloren. In beiden Fällen: Der Code läuft, keine Fehlermeldung — man findet es erst, wenn man die Ergebnisse inhaltlich prüft.

Was Phase 2 verändert — und was nicht

Phase 2 macht den Agenten nicht intelligenter — er kann danach nicht besser recherchieren, nicht besser planen, nicht besser antworten. Aber er wird robuster und bekommt echte neue Fähigkeiten: Crash-Resistenz durch Checkpointing und die Fähigkeit, auf vorherigen Ergebnissen aufzubauen (Multi-Turn-Interaktion). Und das, was in Phase 1 manuell und fragil war, wird strukturiert, testbar und wiederverwendbar.

Und genau dieses Fundament wird relevant, wenn die Anforderungen wachsen. LangGraph bildet die Grundlage für Multi-Agent-Systeme — mehrere spezialisierte Agenten, die koordiniert zusammenarbeiten. Und die Graph-Struktur ermöglicht standardisiertes Tracing, das jeden Schritt des Agenten sichtbar macht. Beides sind Themen für kommende Posts.

Code und Details: Alle drei Blocks — LangGraph Research-Agent mit Tests, eigener MCP-Server, Multi-Tool-Agent mit drei Tool-Quellen — sind auf GitHub dokumentiert: → agentic-ai / Phase 2: Abstractions

Ich bin ML Engineer mit Fokus auf Self-Hosted AI und Datensouveränität. Ich helfe Unternehmen im DACH-Raum, ML- und AI-Systeme auf eigener Infrastruktur zu betreiben. Offen für Austausch und spannende Projekte — schreib mir auf LinkedIn.