Deep Agents in LangChain: Planung, Unteragenten und ein Banking-Gateway

Viele Teams können einen Agenten mit einem Laptop zum Arbeiten einsetzen. Weitaus weniger schaffen es, einen solchen Agenten in der Praxis am Laufen zu halten – und genau diese Lücke ist es, die tiefgehenden Agenten überhaupt erst notwendig macht. Die Idee ist kein Schlagwort, sondern eine Reaktion auf eine konkrete Grenze: Ein einfacher Tool-Aufruf-Loop bricht zusammen, sobald die Aufgabe langwierig, mehrschrittig oder komplex wird.

Die Grenze des einfachen Loops

Der grundlegendste Agent ist ein LLM, das in einem Loop läuft und Tools aufruft. Ein solcher Agent ist in der Regel oberflächlich, was bedeutet, dass er keine langfristige Planung durchführen kann und komplexe, mehrstufige Aufgaben nicht bewältigen kann. Er kommt mit einer einzigen Frage gut zurecht, stolpert aber bei größeren Aufgaben über Hindernisse.

Produkte wie Deep Research, Manus und Claude Code haben dies mit vier Elementen geschafft: einem Planungstool, Unteragenten, einem Dateisystem und einer detaillierten Anweisung. Das deepagents-Projekt entstand aus dem Versuch heraus, zu verstehen, was Claude Code so allgemeingültig macht, und dieses Prinzip weiterzuentwickeln. LangChain bezeichnet solche Agenten als „deep agents“, da sie komplexe Aufgaben planen und über längere Zeiträume hinweg ausführen können. Im Grunde ist dies LangChains Weg zu autonomen Agenten im Stil von Claude Code, die echte, mehrstufige Aufgaben bewältigen können – nicht nur einmalige Fragen.

deepagents ist eine eigenständige Bibliothek, die aus den Kernkomponenten für Agenten von LangChain erstellt wurde und auf dem LangGraph-Runtime läuft, der eine zuverlässige Ausführung, Streaming sowie Unterstützung für menschliche Einmischung bietet. Eine gute Beschreibung ist ein Agenten-Toolkasten: derselbe Tool-Aufruf-Zyklus wie bei anderen Frameworks, ergänzt um zusätzliche eingebaute Tools und Funktionen.

Die vier Bestandteile

Planung. Ein eingebautes Tool namens write_todos ermöglicht es dem Agenten, eine große Aufgabe in einzelne Schritte aufzuteilen, den Fortschritt zu verfolgen und den Plan bei Eintreffen neuer Informationen anzupassen.

Ein Dateisystem für den Kontext. Werkzeuge wie ls, read_file, write_file und edit_file ermöglichen es dem Agenten, umfangreichen Kontext in den Speicher oder auf die Festplatte zu schreiben, sodass das Kontextfenster nicht überläuft und Ergebnisse beliebiger Größe verarbeitet werden können. Ältere Nachrichten werden automatisch zusammengefasst, sobald das Gespräch zu lang wird.

Unter-Agenten. Ein integriertes Aufgabenwerkzeug erzeugt spezialisierte Unter-Agenten mit isoliertem Kontext. Der Hauptagent bleibt unüberlastet, während ein Hilfsagent sich intensiv mit einer Unteraufgabe beschäftigt.

Lange Systemanweisungen. Die aus Claude Code erneut erstellten Anweisungen sind lang und enthalten viele Anleitungen zur Verwendung der Werkzeuge sowie Beispiele dafür, wie in bestimmten Situationen vorgegangen werden soll. Ohne sie wären diese Agenten weitaus weniger leistungsfähig. Die Gestaltung der Anweisungen bleibt weiterhin entscheidend.

Ihre Stellung in der LangChain-Stack-Struktur

Es gibt drei Schichten, wobei jede auf der darunterliegenden aufbaut. LangGraph ist die Agenten-Laufzeitumgebung, geeignet zum Vermischen von Workflows und Agenten. LangChain ist das Agenten-Framework, geeignet zum Einsatz des Kernloops sowie zum Erstellen von Prompts und Tools von Grund auf. Deep Agents ist die Plattform, geeignet für autonome, langlaufende Agenten, die von integriertem Planen, einem Dateisystem und ähnlichen Zusatzfunktionen profitieren. Die Plattform basiert auf der Agenten-Abstraktion von LangChain, die wiederum auf LangGraph beruht.

Ein Beispiel aus der Bankbranche

Stellen Sie sich eine Bank vor, die fünf Domänenwerkzeuge anbietet: das Finden von Geldautomaten nach Postleitzahl, die Auflistung der Investmentberater in einer Stadt, das Abrufen der Unternehmen aus dem Investitionsportfolio der Bank, die Bereitstellung von Informationen zu Rentenplänen sowie das Finden von Filialen in verschiedenen Regionen. Jedes dieser Werkzeuge erledigt eine spezifische Aufgabe hervorragend. Probleme entstehen, wenn ein Benutzer gleichzeitig nach Informationen aus mehreren dieser Werkzeuge fragt:

Können Sie die Geldautomatenstandorte der XYZ Bank zusammen mit den Unternehmen in ihrem Investitionsportfolio aufzählen und außerdem die Standorte der Investmentberater in Chicago angeben?

Darauf zu antworten bedeutet, mehrere Absichten in einer Anfrage zu erkennen, die richtigen Werkzeuge auszuwählen und zu koordinieren, den Kontext über verschiedene Datensphären hinweg beizubehalten und die Ergebnisse zu einer zusammenhängenden Antwort zusammenzufassen. Architekturen, die für einstufige oder lineare Abläufe konzipiert sind, stoßen hier oft an ihre Grenzen. Genau dafür sind tiefe Agenten gedacht.

Die Abfolge verläuft wie folgt.

1. Planung. Der Hauptorchestrator liest die komplexe Frage und verwendet write_todos, um sie in drei Aufgaben aufzuteilen: Die Geldautomatenstandorte ermitteln, die Unternehmen im Portfolio finden und die Berater in Chicago ausfindig machen.

Erzeugung. Anstatt alle drei Schritte nacheinander in einem überdimensionierten Kontext abzuwickeln, startet das System drei Unteragenten – einen pro Aufgabe –, wobei jeder seine eigene Kontextfenster hat, damit sie sich nicht gegenseitig stören.

Toolaufruf. Jeder Unteragent verwendet genau das richtige der fünf Tools: get_atm_centers(zipcode=...), get_trusted_portfolio_companies() und get_investment_officers(city="Chicago").

Synthese. Die Ergebnisse werden an den Orchestrierer zurückgesendet, der sie zu einer gut formatierten Antwort zusammenführt und die zu erledigenden Aufgaben abhakt.

Ein einfacher Tool-Aufruf-Agent würde alle drei Aufgaben nacheinander innerhalb eines Kontexts bearbeiten. Er könnte frühere Ergebnisse vergessen, den Überblick darüber verlieren, auf welche Frage er antwortet, oder die Kontextgrenze erreichen. Ein tiefergehender Agent hält die Aufgaben getrennt voneinander und verfolgt den Fortschritt über die To-Do-Liste, sodass selbst bei fehlgeschlagenen Aufrufen oder der Rückgabe von unvollständigen Daten der Orchestrierer weiß, wo er steht.

Die Struktur ist einfach:

from deepagents import create_deep_agent

agent = create_deep_agent(
    tools=[
        get_atm_centers,         # your ATM tool
        get_investment_officers, # your officers tool
        get_portfolio_companies, # your portfolio tool
        get_retirement_plans,    # your retirement tool
        get_bank_locations,      # your locations tool
    ],
    system_prompt="You are XYZ Bank's AI assistant. Always answer completely and cite sources."
)

result = agent.invoke({"messages": [{"role": "user", "content": "Can you give me a list of ATM centers for XYZ bank and also list the name of companies XYZ has in its investment portfolio? Also can you give me the location of XYZ investment agents in Chicago?"}]})

Der Agent entscheidet, welche Tools aufgerufen werden sollen, in welcher Reihenfolge und wie die Ergebnisse kombiniert werden. Sie müssen keine Routing-Logik selbst schreiben – das ist der eigentliche Wert des Frameworks.

ReAct gegen tiefe Agenten, wenn ein Tool fehlt

Nehmen wir denselben Anfragekontext und fügen eine vierte Frage hinzu, für die es kein Tool gibt: eine Liste von Kreditkartenoptionen für Studenten. So geht jede der Designs heran.

Ein tiefes Agent überprüft sein Tool-Register und erstellt die To-Do-Liste, bevor es handelt, sodass es von Anfang an erkennt, dass nichts für Kreditkarten vorhanden ist. Es startet Sub-Agenten für die drei zu erledigenden Aufgaben, die parallel laufen und normal abgeschlossen werden. Anschließend markiert es den Kreditkarten-Eintrag als „kein Tool verfügbar“ und gibt eine synthetisierte Antwort zurück. Diese Antwort beantwortet alle drei Fragen vollständig und teilt dem Benutzer klar mit, dass kein Kreditkarten-Tool konfiguriert ist und eines hinzugefügt werden könnte. Nichts geht schief, und der teilweise Erfolg wird ordnungsgemäß gemeldet.

ReAct, abgekürzt für Reasoning plus Acting, folgt einem strengen Thought-Act-Observe-Zyklus Schritt für Schritt ohne vorherigen Plan. Das führt zu drei Problemen:

• Es arbeitet sequenziell, also zuerst Geldautomaten, dann das Portfolio und anschließend die Mitarbeiter. Das Problem mit den Kreditkarten tritt erst ganz am Ende auf, nachdem alles andere erledigt ist.

Es scannt niemals die verfügbaren Tools. Es findet das fehlende Tool zur Laufzeit, wenn es versucht, es aufzurufen, und je nach LLM und Implementierung kann es abbrechen, mit einem erfundenen Toolnamen erneut versuchen oder, was am schlimmsten ist, eine glaubwürdige Liste von Kreditkarten erstellen, weil es davon ausgeht, dass eine Antwort existiert.

Weil der Fehler mitten im Laufzyklus auftritt, garantiert nichts, dass die ersten drei Ergebnisse sauber beim Benutzer ankommen. Der Agent könnte einfach fehlschlagen und nichts zurückgeben.

ReAct eignet sich für kurze, gut definierte Aufgaben, bei denen bekannt ist, dass alle Tools vorhanden sind. Deep Agents hingegen dienen der komplexeren Realität, in der Fragen zusammengesetzt sind, Tools fehlen können und man dennoch so viel Wert wie möglich aus dem Verfügbaren gewinnen möchte.

Die Designfrage: Ein Agent mit allen Tools?

Heißt das, wir sollten viele Tools entwickeln und sie alle über einen einzigen Agenten bereitstellen? Nein. Ein einzelner Agent, der 50 oder mehr Tools enthält, ist ein Anti-Muster. Besser ist eine Hierarchie von Agenten. Stellen Sie sich einen Agenten vor, dessen Konfiguration Hunderte von Tools auflistet – von Web-Suchen und E-Mails über Flugbuchungen bis hin zu Raketenstarts – mit der Anweisung, „sich selbst zu helfen“. Das funktioniert manchmal, und gelegentlich beantwortet er eine Beschwerde wegen verspäteter Lieferung, indem er einen Flug bucht, Steuern einreicht und eine Pizza bestellt. Das will niemand.

Domaineigentum

Die Leitregel lautet, dass jeder Domain-Agent eine kleine, zusammenhängende Gruppe von Tools besitzt – idealerweise drei bis fünf – aus einem einzigen Geschäftsbereich. Ein Gateway-Agent berührt niemals die Tools. Er liest lediglich die Absicht, leitet sie an den richtigen Domain-Agent weiter und fügt die Antworten zusammen. Es handelt sich dabei um dieselbe Trennung der Aufgaben, wie sie bei Microservices verwendet wird.

Im Bankensektor ist die natürliche Aufteilung wie folgt:

• Ein Filial- und ATM-Agent mit get_atm_centers sowie get_bank_locations, der die physische Präsenz abdeckt: Postleitzahlen, Städte, Öffnungszeiten.
• Ein Investments-Agent mit get_portfolio, get_officers und get_retirement_plans, der das Geldmanagement abdeckt, einschließlich finanzieller Vorschriften, Zertifizierungen der Mitarbeiter sowie Planarten.
• Ein Produkte-Agent mit get_credit_cards, sobald diese verfügbar sind, sowie Informationen zu Krediten und Sparkonten, der den Produktkatalog abdeckt. Wenn ein Tool fehlt, meldet nur dieser Agent das Defizit, während die anderen unberührt weiterarbeiten.

Der Code spiegelt diese Struktur wider:

from deepagents import create_deep_agent
# Each domain agent is self-contained
branch_agent = create_deep_agent(
    tools=[get_atm_centers, get_bank_locations],
    system_prompt="You are the Branch & ATM specialist for XYZ Bank..."
)
investments_agent = create_deep_agent(
    tools=[get_portfolio, get_officers, get_retirement_plans],
    system_prompt="You are the Investments specialist for XYZ Bank..."
)
products_agent = create_deep_agent(
    tools=[get_credit_cards],  # sparse now, grows over time
    system_prompt="You are the Products specialist for XYZ Bank..."
)
# Gateway knows nothing about tools — only about agents
gateway = create_deep_agent(
    tools=[
        branch_agent.as_tool(name="branch_atm_agent"),
        investments_agent.as_tool(name="investments_agent"),
        products_agent.as_tool(name="products_agent"),
    ],
    system_prompt="""You are the XYZ Bank assistant gateway.
    Parse the user's intent, delegate to the right domain agent(s),
    and synthesize a unified response. Never answer directly — always route."""
)

Warum das skalierbar ist

Sobald die Bank weitere Funktionen hinzufügt, bleiben das Gateway sowie die anderen Domänenagenten unverändert. Man fügt ein Tool zum entsprechenden Domänenagenten hinzu oder erstellt einen neuen, wie z. B. für Kredite oder Betrug, und registriert ihn beim Gateway. Jede Änderung beschränkt sich auf eine Domäne.

Vergleichen Sie dies mit einem „Wald“ an Tools: Ein Agent mit 30 solchen Tools hat kein Gefühl für die jeweilige Domäne und könnte bei der Beantwortung einer Frage zu den Öffnungszeiten von Geldautomaten versehentlich get_retirement_plans aufrufen – einfach weil beides zum Aufgabengebiet gehört. Domänenagenten vermeiden das, indem sie jedem Agenten durch seine Systemanweisungen und sein Toolset eine klare Identität geben. Ein Agent, der weiß, wer er ist, kann in seinem eigenen Bereich präziser entscheiden.

Ein nützlicher Test: Wenn man darüber streitet, ob ein Tool zu Agent A oder Agent B gehört, dann erledigt das Tool entweder zu viel und sollte geteilt werden, oder es ist ein drittes Domänenkonzept erforderlich. Die Grenze sollte genauso offensichtlich sein wie die Entscheidung, ob eine Frage an den Filialleiter oder den Anlageberater gerichtet wird.

Offene Fragen

Zwei Dinge bleiben unklar: Ob tiefe Agenten stark von der Wahl des zugrundeliegenden Modells abhängen und ob mit ihnen eine vollständige End-to-End-Lösung erstellt werden kann. Die Antwort auf die zweite Frage lautet ja, und der natürliche nächste Schritt ist ein praktischer Aufbau dieses Bankenszenarios.