Deep Agents

Hallo, hier ist Alex von DEV STORIES DOT EU. Deep Agents, Folge 1 von 16. Einen Coding Agent von Grund auf zu bauen, macht etwa eine Stunde lang Spaß. Dann stößt dein Modell an das Context Limit, vergisst die ursprüngliche Aufgabe komplett und überschreibt ein wichtiges File mit Datenmüll. Damit dein Assistent seinen eigenen Workspace nicht zerstört, brauchst du das sogenannte Agent Harness Pattern. Viele stoßen auf dieses Pattern durch eine Library namens Deep Agents. Zunächst eine kurze Klarstellung: Deep Agents ist weder LangChain noch LangGraph. Es ist eine eigenständige Python-Library, die auf diesen Tools aufbaut und sie zu einem sofort einsatzbereiten Coding Assistant bündelt. Wenn du versuchst, selbst einen Coding Assistant zu bauen, fängst du normalerweise mit einem einfachen Script an. Du nimmst einen User Prompt, schickst ihn an ein Large Language Model und gibst den Code aus, den es zurückliefert. Das ist einfach nur eine simple Chat Loop. Das funktioniert super, um eine einzelne Frage zu beantworten. Aber schon bald willst du, dass das Modell ein Feature über mehrere Files hinweg auf deiner Maschine implementiert. Hier platzt die Illusion. Du merkst, dass du manuell Tools schreiben musst, um Files zu lesen, Directories zu durchsuchen und Code Diffs sicher anzuwenden. Du brauchst ein System, das den Context über Dutzende von Steps hinweg trackt, ohne das Token Limit auszureizen. Du musst eine persistente Task List bauen, damit sich das Modell wirklich merkt, was es gerade getan hat und was als Nächstes ansteht. Am Ende verbringst du deine ganze Zeit damit, File System Boilerplate und State Management zu schreiben, anstatt dich auf das Agent Behavior zu konzentrieren. Genau das löst das Agent Harness Pattern. Ein Harness ist der Infrastructure Layer, der das rohe Language Model umschließt. Es verwandelt eine fragile, stateless Chat Loop in einen robusten, lang laufenden Agenten. In Deep Agents liefert dieses Harness das Memory Management, die File System Operations und die schrittweise Planning Logic direkt out of the box. Du gibst ihm ein High-Level Goal und verweist es auf ein lokales Directory. Das Harness übernimmt die repetitive Arbeit, dem Modell ein sicheres Environment zu geben, um Code zu planen, zu editieren und zu verifizieren. Hier ist der entscheidende Punkt. Der Hauptvorteil eines unabhängigen Harness wie Deep Agents ist, dass es komplett model-agnostic ist. Eng integrierte Lösungen wie das Claude Agent SDK oder ältere Ecosystems wie OpenAI Codex sind zwar stark optimiert, aber sie binden dich an einen einzigen Provider. Wenn morgen ein günstigeres oder schlaueres Modell herauskommt, bereitet dir die Migration deines tightly coupled Agenten massives Kopfzerbrechen. Weil Deep Agents das Environment von der Reasoning Engine abstrahiert, wird das Language Model zu einer komplett austauschbaren Component. Das Harness managt die Task Lists, liest das File System und kümmert sich um die Error Recovery. Diese Logik bleibt identisch, egal ob du Anthropic, OpenAI oder ein lokales Open-Weight Model nutzt. Das Harness ist das Chassis des Autos, und das Language Model ist nur der Motor. Der wahre Wert dieses Patterns ist Zuverlässigkeit. Ein Agent ist nur so fähig wie das Environment, in dem er operiert, und ohne ein Harness, das ihn an ein echtes File System und einen konkreten Plan koppelt, ist selbst das smarteste Modell nur ein Text-Generator, der auf der Stelle tritt. Wenn du helfen willst, die Show am Laufen zu halten, kannst du auf Patreon nach DevStoriesEU suchen. Jeder Support dort hilft enorm und wird immer geschätzt. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Deep Agents, Folge 2 von 16. Du brauchst kein riesiges Architekturdiagramm oder hunderte Zeilen Boilerplate, um ein Sprachmodell dazu zu bringen, seine Arbeit autonom zu planen. Du brauchst nur einen einzigen Function Call, um den Core Loop zu triggern. Der Entry Point für dieses Verhalten ist eine Funktion namens create deep agent. In dieser Funktion definierst du das Gehirn deiner Anwendung. Anstatt separate Client Libraries zu importieren und eigene Wrapper zu schreiben, sagst du der Funktion über einen einfachen, durch einen Doppelpunkt getrennten String, welches Modell verwendet werden soll. Du übergibst den Provider, einen Doppelpunkt und den genauen Modellnamen. Du könntest zum Beispiel anthropic colon claude-sonnet-4-6 oder openai colon gpt-5.4 verwenden. Das Framework liest diesen String und übernimmt unter der Haube die spezifische Initialisierung. Ein Agent braucht eine Möglichkeit, mit der Welt zu interagieren, und die gibst du ihm über Tools. Ein Tool ist einfach eine Standard-Python-Funktion, die eine bestimmte Aktion ausführt. Sagen wir, du baust einen Internet-Recherche-Agenten. Du würdest eine Funktion schreiben, die eine Query nimmt, eine Search API aufruft und Text zurückgibt. Diese Suchfunktion übergibst du direkt in deinem create deep agent Call als Teil einer Liste. Dein Agent ist jetzt startklar. Um den Prozess zu starten, rufst du die run Methode auf deinem neuen Agenten auf und übergibst ihm einen Prompt, zum Beispiel mit der Bitte, aktuelle Nachrichten über Quantencomputing zu recherchieren und zusammenzufassen. Jetzt übernimmt der Core Loop. Hier ist die wichtigste Erkenntnis: Entwickler gehen oft davon aus, dass sie komplexe System Prompts schreiben müssen, um das Modell dazu zu zwingen, Aufgaben herunterzubrechen, oder Custom Parser bauen müssen, um den Fortschritt zu tracken. Du musst nichts davon tun. Wenn du create deep agent aufrufst, injiziert das Harness automatisch ein integriertes Tool namens write todos. Du schreibst oder verwaltest dieses Tool nie selbst. Es ist Teil der Core Engine. Bevor der Agent dein Search Tool überhaupt anfasst, zwingt der Core Loop das Modell dazu, das write todos Tool zu nutzen. Der Agent wertet deinen Prompt aus und generiert eine strukturierte Liste von Schritten. Erst wenn dieser Plan fertig ist, beginnt die Execution Phase. Der Loop iteriert Schritt für Schritt über den Plan. Der Agent schaut sich seine erste Aufgabe an, erkennt, dass er Informationen braucht, und ruft dein Internet Search Tool auf. Er liest den Raw Text, der von der Suchmaschine zurückgegeben wird, und aktualisiert seinen internen Memory. Der Loop checkt dann, ob das Hauptziel erreicht ist. Wenn die Suchergebnisse unvollständig waren, geht der Agent zum nächsten Punkt auf seiner Todo-Liste über und formuliert vielleicht eine neue Search Query, um die fehlenden Details zu finden. Dieser Zyklus aus Tool-Auswahl, Beobachten des Ergebnisses und Überprüfen des Plans läuft autonom weiter. Wenn der Loop bestätigt, dass alle nötigen Aufgaben erledigt sind, stoppt er die Tool Calls. Der Agent analysiert die gesammelten Daten, generiert eine finale, zusammengefasste Antwort und gibt sie an dich zurück. Das entscheidende Merkmal des Core Loops ist, dass er einen statischen Textgenerator in einen aktiven Problemlöser verwandelt, indem er ihn strukturell dazu zwingt, vor dem Handeln zu planen. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Deep Agents, Folge 3 von 16. Einem autonomen Agenten Raw-Access auf deinen Computer zu geben, ist ein hervorragender Weg, versehentlich dein Home-Verzeichnis zu löschen. Wenn ein Agent entscheidet, deine Dateien neu zu organisieren oder ein Script zu testen, musst du sicherstellen, dass er auf einen sicheren Bereich beschränkt ist. Deshalb nutzen wir das Pluggable Filesystem. Wenn du einem Deep Agent Tools gibst, um eine Datei zu lesen oder zu bearbeiten, verbinden sich diese Tools nicht direkt mit deinem Betriebssystem. Stattdessen werden sie auf ein Backend gemappt. Ein Backend ist eine Storage-Umgebung, die vorgibt, wo und wie Dateien tatsächlich liegen. Die Standardumgebung ist das StateBackend. Das ist ein ephemeral Ghost-Drive, das komplett im Memory gehalten wird. Angenommen, du bittest einen Agenten, einen schnellen E-Mail-Entwurf zu schreiben oder ein paar Textdaten zu manipulieren. Der Agent erstellt die Datei, liest sie wieder ein und bearbeitet sie – alles innerhalb des StateBackends. Wenn dein Script durchgelaufen ist, wird dieser Memory geleert und die Dateien verschwinden. Es ist komplett isoliert und absolut sicher. Aber was passiert, wenn du willst, dass der Agent ein echtes Python-Projekt auf deiner lokalen Disk generiert? Memory reicht da nicht mehr aus. Du upgradest die Permissions des Agents, indem du ein FilesystemBackend einbindest. Das verbindet die File-Tools des Agents mit deiner echten Festplatte. Um das sicher zu halten, initialisierst du das Backend mit einem Parameter namens virtual mode, der auf true gesetzt ist. Hier ist der entscheidende Punkt: Virtual mode erzeugt eine strikte Pfadgrenze. Du definierst ein Base Directory, und der Agent operiert nur darin. Wenn der Agent versucht, ein sensibles System-File außerhalb dieses Ordners zu lesen, blockiert das Backend den Request. Es sperrt den Agenten in einen festgelegten Workspace ein. Hier gibt es jedoch ein gefährliches Missverständnis. Viele Developer gehen davon aus, dass das Aktivieren von virtual mode eine komplett sichere Sandbox erzeugt. Tut es aber nicht. Das FilesystemBackend kontrolliert nur File Operations. Wenn du willst, dass dein Agent auch Terminal Commands ausführt, musst du eine dritte Art von Backend einbinden, das LocalShellBackend. Das LocalShellBackend gibt dem Agenten ein neues Tool namens execute. Das erlaubt dem Agenten, Shell Commands auf deiner Host Machine auszuführen. Wenn du ein LocalShellBackend einbindest, wird dich der virtual mode deines FilesystemBackends nicht vor destruktiven Terminal Commands schützen. Der Agent könnte ein systemweites Deletion-Script ausführen, und die Shell würde es laufen lassen und dabei deine File-Path-Restriktionen komplett umgehen. File Access und Shell Execution sind unterschiedliche Capabilities, die auf unterschiedliche Backends gemappt werden. Wenn dein Agent nur Code schreiben muss, bleib beim FilesystemBackend. Binde das LocalShellBackend nur ein, wenn der Agent diesen Code unbedingt lokal compilen oder ausführen muss. Der sicherste autonome Agent ist nicht der mit den smartesten Prompts, sondern derjenige, der mit einem ephemeral StateBackend deployed wird, das dein Host-Betriebssystem physisch gar nicht berühren kann. Das war's für heute. Danke fürs Zuhören – leg los und bau was Cooles.

Hallo, hier ist Alex von DEV STORIES DOT EU. Deep Agents, Folge 4 von 16. Der häufigste Fehler beim Agent-Design ist das Schreiben eines riesigen, viertausend Wörter langen System Prompts, der detailliert beschreibt, wie jedes einzelne Tool funktioniert, und das Hardcoden spezifischer Session-Daten. Am Ende hast du einen fehleranfälligen Prompt, ausgereizte Context Windows und einen Albtraum beim Handling mehrerer User. Dynamic System Prompts lösen dieses Problem, indem sie die exakten Anweisungen, die das Language Model braucht, on the fly zusammenstellen. Stell dir Context Engineering in Deep Agents wie ein dynamisches Fließband vor. Anstatt einen einzigen statischen Textblock zu schreiben, wird der finale Prompt, der an das Language Model gesendet wird, aus drei verschiedenen Layern zusammengesetzt. Diese Layer sind der statische System Prompt, die Tool Prompts und der Runtime Context. Sie werden im exakten Moment der Ausführung zusammengeführt, um den vollständigen Input Context zu bilden. Der erste Layer ist der statische System Prompt. Das ist der Teil, den du manuell schreibst. Er definiert die Agent Persona, ihre Kernregeln und ihr oberstes Ziel. Er ist bewusst einfach gehalten. Du kannst dem Agenten zwar sagen, dass er ein Database Query Assistant ist, aber du sagst ihm nicht, wie er sich mit der Datenbank verbindet, welches Format das Tool erwartet oder wie die User Session ID lautet. Du hältst diesen Layer strikt fokussiert auf High-Level Business Logic. Der zweite Layer besteht aus den Tool Prompts, und hier kommt das Framework ins Spiel. Deep Agents injectet automatisch die notwendigen Usage Instructions für die spezifischen Tools, die du an den Agenten hängst. Wenn du dem Agenten ein Tool zum Lesen einer Datei gibst, hängt das Framework dynamisch das exakte Schema für dieses Tool an. Zusammen mit den Schemas injectet es einen built-in Planning Prompt. Dieser Planning Prompt instruiert das Modell, wie es die verfügbaren Tools effektiv sequenzieren soll, um ein Problem zu lösen. Du schreibst niemals manuell die Anweisungen aus, wie das Modell einen Tool Call formatieren oder seine Execution Steps planen soll. Das Framework übernimmt diese Mechaniken automatisch. Wenn du dem Agenten ein Tool hinzufügst oder entfernst, updaten sich die zugrunde liegenden Tool Prompts sofort, ohne dass du den Core System Prompt anfassen musst. Jetzt müssen wir eine häufige Ursache für Verwirrung zwischen dem statischen System Prompt und dem Runtime Context klären. Der statische Prompt wird definiert, wenn du den Agenten initialisierst. Der Runtime Context hingegen wird genau dann injiziert, wenn du den Agenten aufrufst, um seine Arbeit zu erledigen. Stell dir ein Szenario vor, in dem du eine Multi-Tenant-Applikation baust. Wenn ein bestimmter User eine Frage stellt, braucht der Agent dessen eindeutige Database Connection ID, um seine Daten abzurufen. Wenn du diesen Identifier in den statischen System Prompt packen würdest, müsstest du den kompletten Agenten für jeden einzelnen User Request von Grund auf neu erstellen. Stattdessen nutzt du den Runtime Context. Hier ist die entscheidende Erkenntnis. Du übergibst ein Context Object über ein Feature namens ToolRuntime direkt beim Invocation Step. Du übergibst dem Framework ein Dictionary, das die spezifische Database Connection ID für diese Session enthält. Das Framework nimmt diesen Runtime Context, mergt ihn mit deinem statischen Prompt und den automatisch generierten Tool Instructions und verkabelt ihn direkt mit den Tools, die ihn benötigen. Das Tool wird mit der korrekten, dynamisch bereitgestellten Connection ID ausgeführt. Dein statischer System Prompt bleibt komplett sauber von temporären Identifiern, API Keys oder Session Tokens. In der exakten Millisekunde der Ausführung beendet das dynamische Fließband seinen Job. Deep Agents verknüpft deine Core Instructions, die dynamisch generierten Tool Schemas, die Planning Prompts und die spezifischen Invocation Data zu einem kohärenten Input Context. Das Modell erhält ein komplettes, perfekt formatiertes Set an Anweisungen, das genau auf diesen spezifischen User und diesen spezifischen Task zugeschnitten ist. Die skalierbarsten Agenten wissen nichts über ihre Umgebung, bis zu dem exakten Moment, in dem sie zum Handeln aufgefordert werden. Das war’s für diese Folge. Bis zum nächsten Mal!

Hallo, hier ist Alex von DEV STORIES DOT EU. Deep Agents, Folge 5 von 16. Die meisten AI-Agenten crashen oder schlagen stillschweigend fehl, sobald sie ein System-Log oder einen Data Dump lesen, der ihre maximale Prompt-Größe überschreitet. Deep Agents verhindert das, indem es Context Limits so behandelt, wie ein Betriebssystem virtuellen Speicher handhabt. Das nennt man Context Compression und Offloading. Large Language Models haben eine feste Obergrenze dafür, wie viel Text sie auf einmal verarbeiten können. Wenn ein Agent versucht, zu viele Daten in seinem aktiven Prompt zu halten, wirft das Modell einen Error und stoppt. Deep Agents managt diesen Token Overflow, indem es die Größe der Conversation-Daten kontinuierlich überwacht. Das funktioniert genau wie bei einem Computer, der RAM auf die Festplatte auslagert, wenn der Speicher voll wird. Der aktive Working Space wird schlank gehalten, während die großen Datenmengen sicher aus dem Weg geräumt werden. Dieser Mechanismus arbeitet in zwei unterschiedlichen Phasen. Die erste Phase kümmert sich um plötzliche, massive Datenspitzen von externen Tools. Das Framework überwacht den Token Count von jedem einzelnen Tool Input und Tool Result. Der harte Threshold für diesen Check liegt bei zwanzigtausend Tokens. Wenn eine Operation dieses Limit überschreitet, fängt das System die Payload ab, bevor sie überhaupt das Language Model erreicht. Stell dir einen Agenten vor, der eine Query ausführt und einen massiven Database Dump mit dreißigtausend Tokens zieht. Ein Standard-Agent versucht, diese gesamte Payload direkt in die Conversation History einzufügen, was sofort einen Token Overflow triggert. Deep Agents geht einen anderen Weg. Es fängt diese massive Response ab, lagert den kompletten Text in eine neue Datei auf dem Backend-Filesystem aus und ersetzt die Payload in der Conversation durch eine einfache zehnzeilige Preview. Der Agent liest die Preview und erhält einen File Path, der auf die kompletten Daten zeigt. Der Agent weiß genau, was er gefunden hat, aber der aktive Prompt bleibt komplett aufgeräumt. Damit sind plötzliche Datenspitzen abgedeckt. Die zweite Phase kümmert sich um die langsame Ansammlung von Daten in einer Standard-Conversation. Wenn ein Agent einen langen, mehrstufigen Prozess ausführt, frisst das ständige Hin und Her der History langsam die verfügbaren Tokens auf. Deep Agents überwacht die gesamte Nutzung des Context Windows im Abgleich mit den Model Limits. Wenn der aktive Prompt fünfundachtzig Prozent des gesamten verfügbaren Context Windows erreicht, triggert automatisch ein Background Summarization Process. Das System nimmt den ältesten Block von Messages in der aktuellen History und nutzt ein Language Model, um eine dichte, faktenbasierte Summary dieser Ereignisse zu generieren. Dann ersetzt es diesen älteren Block von Messages im aktiven Prompt durch die neu generierte Summary, wodurch der Token Count sofort wieder auf ein sicheres Working Level sinkt. Hier ist der entscheidende Punkt: Developer gehen oft davon aus, dass das Zusammenfassen der Conversation die originale History dauerhaft zerstört. Das stimmt nicht. Bevor eine Summarization stattfindet, werden die originalen Messages als permanenter, kanonischer Record auf das Filesystem geschrieben. Die Rohdaten gehen nicht verloren. Wenn der Agent später feststellt, dass er ein hochspezifisches Detail aus einem früheren Schritt braucht, das es nicht in die Summary geschafft hat, kann er seine Search Tools nutzen, um dieses Filesystem zu queryen und den exakten Originaltext abzurufen. Durch die Kombination von sofortigen Filesystem Offloads für massive Tool Results mit dynamischer Summarization für langlaufende Histories kann ein Agent unbegrenzt arbeiten, ohne an seinem eigenen Context zu ersticken. Danke fürs Zuhören, Happy Coding zusammen!

Hallo, hier ist Alex von DEV STORIES DOT EU. Deep Agents, Folge 6 von 16. Wenn dein Haupt-KI-Agent zehn Webseiten liest, um eine einzige Frage zu beantworten, vergisst er irgendwann, was der ursprüngliche Prompt war. Das ganze Rauschen dazwischen übertönt die Anweisungen. Die Lösung dafür ist Context Isolation mit synchronen Subagents. Stell dir das wie ein Clean Architecture Pattern für deine Sprachmodelle vor. Wenn ein einzelner Agent Zugriff auf Dutzende von Tools hat und lange iterative Loops durchläuft, füllt sich sein Context Window schnell mit Rohdaten, Fehlermeldungen und Tool-Ausgaben. Dieser Context Bloat beeinträchtigt die Reasoning-Fähigkeit des Modells. Anstatt eines einzigen, riesigen Agenten, der versucht, alles zu erledigen, brauchst du einen Supervisor. Der Hauptagent fungiert als Manager. Er delegiert die unordentliche, Token-lastige Arbeit an Spezialisten und erhält nur einen sauberen, formatierten Abschlussbericht. Leute halten Subagents oft fälschlicherweise für einen fortlaufenden Multi-Agent-Chatroom, in dem verschiedene Modelle zusammensitzen und Ideen hin und her diskutieren. Das ist hier nicht der Fall. Synchrone Subagents sind streng ephemer. Sie werden gespawnt, um einen bestimmten Job auszuführen, laufen völlig autonom in ihrem eigenen isolierten Memory Space, bis der Job erledigt ist, und geben ein einziges Endergebnis an den Supervisor zurück. Sobald sie dieses Ergebnis übergeben haben, verschwinden sie. Stell dir ein konkretes Szenario vor. Dein Hauptagent hat die Aufgabe, ein Market Briefing zu schreiben, und braucht Daten zu aktuellen Wirtschaftstrends. Anstatt dass der Supervisor direkt fünfmal ein Web Search Tool aufruft und sein eigenes Context Window mit rohem Website-Text zumüllt, delegiert er das Problem. Er triggert einen Researcher-Subagent. Dieser ephemere Researcher geht in seinen eigenen isolierten Loop. Er macht die fünf Google-Suchen, liest die unordentlichen Ergebnisse, synthetisiert die Erkenntnisse und schreibt einen einzigen Zusammenfassungs-Absatz. Er gibt nur diesen Absatz an den Supervisor zurück. Der Supervisor bekommt genau das, was er braucht, und sein Context bleibt makellos. Um das zu konfigurieren, definierst du deine Spezialisten mit einfachen Dictionaries. Diese übergibst du an den subagents-Parameter, wenn du deinen Hauptagenten baust. Jedes Dictionary ist eine Subagent-Spezifikation, die vier Informationen benötigt. Erstens gibst du einen Namen an, wie researcher oder calculator. Zweitens gibst du eine Beschreibung an. Dieser Teil ist entscheidend. Der Supervisor liest diese Beschreibung, um zu entscheiden, welchen Spezialisten er für ein bestimmtes Problem anheuern soll. Drittens stellst du die Tools bereit, was diesem spezifischen Subagent isolierten Zugriff auf Dinge wie einen Web Scraper oder einen Database Client gibt. Schließlich übergibst du einen System Prompt, der steuert, wie sich der Subagent verhält. Sobald du diese Liste von Konfigurationen an den Hauptagenten übergibst, bekommt er automatisch Zugriff auf ein integriertes Tool namens task. Der Supervisor muss nicht wissen, wie man die Subagents instanziiert. Wenn er auf ein Problem stößt, das zur Beschreibung eines Spezialisten passt, ruft er einfach das task-Tool auf. Er übergibt zwei Argumente: den Namen des zu verwendenden Subagents und eine Plain-Text-Anweisung, was getan werden muss. Die Execution des Supervisors pausiert. Der Subagent fährt hoch, arbeitet seine Tools ab und ist irgendwann fertig. An den Supervisor gibt das task-Tool einfach die finale Textantwort zurück, als wäre es ein Standard-Function-Call. Selbst wenn du keine Dictionaries explizit definierst, gibt dir das Framework einen Fallback. Es ist ein General-Purpose Default-Subagent eingebaut. Der Hauptagent kann diesen Default-Spezialisten nutzen, um komplexe Reasoning-Schritte auszulagern. Er fungiert als unbeschriebenes Blatt und gibt dem Modell ein frisches Context Window, um ein dichtes Logikrätsel durchzuarbeiten, ohne den Supervisor-Memory zu verunreinigen. Hier ist die wichtigste Erkenntnis. Indem du strikte Grenzen zwischen isolierten Tasks erzwingst, verhinderst du, dass intermediäre Scratchpad-Arbeit die Reasoning-Qualität deines primären Application Flows beeinträchtigt. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Deep Agents, Folge 7 von 16. Ein autonomes System blind SQL-Abfragen ausführen zu lassen, ist ein hervorragender Weg, um versehentlich eine Production-Datenbank zu droppen. Wenn du willst, dass dein Agent in der realen Welt funktioniert, brauchst du einen Mechanismus, der ihn abfängt, bevor er etwas Zerstörerisches tut. Hier kommen Human-in-the-Loop-Interventionen ins Spiel. Die Grundidee ist einfach. Du pausierst den Agenten kurz bevor er eine kritische Operation ausführt, bittest einen Menschen um Anweisungen und setzt die Ausführung basierend auf diesem Feedback fort. Bevor wir uns die Mechanik ansehen, gibt es eine häufige Fehlerquelle, die du vermeiden solltest. LangGraph braucht Memory, um den State zu pausieren und fortzusetzen. Wenn du versuchst, eine Human-in-the-Loop-Intervention zu konfigurieren, ohne einen Checkpointer einzurichten, wird die Intervention fehlschlagen. Das System braucht einen Persistence Layer, wie einen Memory Saver, um den Execution Graph einzufrieren und die aktuellen Variablen zu speichern, während es auf die Antwort eines Menschen wartet. Füge also immer zuerst einen Checkpointer hinzu. Nicht alle Tools brauchen ein Human Review. Das Wetter abzufragen oder ein Logfile zu lesen, ist im Allgemeinen sicher. Das Löschen von Dateien oder das Ändern von Datenbankeinträgen erfordert strenge Kontrolle. Diese Risikokategorisierung steuerst du über den Konfigurationsparameter interrupt on. Wenn du deinen Agenten initialisierst oder deinen Tool Node definierst, übergibst du diesem Parameter eine Liste von Tool-Namen. Wenn der Agent versucht, ein Tool aufzurufen, das nicht auf der Liste steht, wird es sofort ausgeführt. Wenn er versucht, ein Tool aufzurufen, das auf der Liste steht, pausiert die Ausführung. Lass uns ein konkretes Szenario durchgehen. Du hast einen Agenten mit einem Datenbank-Tool namens execute. Du fügst execute zu deiner interrupt on Liste hinzu. Der Agent entscheidet, dass er ein paar alte Daten bereinigen muss, und versucht, einen Database Drop Command auszuführen. Das System fängt den Call ab und pausiert den Execution Graph. Wenn du deinen Agenten ausführst, überwachst du das Result Object, das vom Framework zurückgegeben wird. Genauer gesagt, prüfst du auf eine Property namens interrupts. Wenn die interrupts-Liste im Result Daten enthält, hat der Agent ein Safety Gate erreicht und wartet auf deinen Input. An diesem Punkt bewertet der menschliche Operator die ausstehende Aktion. Du hast drei erlaubte Entscheidungen, die du an den Agenten zurückgeben kannst. Diese sind approve, reject oder edit. Wenn du mit approve bestätigst, führt der Agent das Tool mit den ursprünglichen Argumenten aus. Wenn du mit reject ablehnst, schlägt der Tool Call kontrolliert fehl, und der Agent erhält eine Error Message, die ihn auffordert, einen anderen Ansatz zu versuchen. Hier wird es interessant. Die edit-Entscheidung erlaubt es dir, die geplante Aktion des Agenten zu modifizieren, bevor sie passiert. In unserem Datenbank-Szenario versucht der Agent einen gefährlichen Drop Command. Du kannst diesen Request abfangen, die Tool-Argumente umschreiben, um stattdessen eine sichere Select Query auszuführen, und diesen modifizierten Payload an das System zurücksenden. Um den Agenten weiterlaufen zu lassen, rufst du ihn erneut auf, aber dieses Mal übergibst du ein Command Object über den resume-Parameter. Innerhalb dieses resume-Parameters übergibst du deinen Decision String zusammen mit eventuell modifizierten Argumenten. Der Checkpointer ruft den eingefrorenen State ab, injiziert deine menschliche Entscheidung direkt in den Graph, als hätte der Agent es ursprünglich so geplant, und die Ausführung geht weiter. Das Wichtigste, was du dir merken solltest, ist, dass Human-in-the-Loop-Interventionen dir mehr bieten als nur einen Not-Aus-Schalter. Die Möglichkeit, Tool-Argumente on the fly zu bearbeiten, erlaubt es dir, einen Agenten sicher durch komplexe Workflows zu führen, ohne von vorn anfangen zu müssen. Wenn du die Show unterstützen möchtest, such auf Patreon nach DevStoriesEU. Das war es für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Deep Agents, Folge 8 von 16. Vielleicht siehst du dir einen Agent an, der eine lokale Datei liest, und denkst, diese Fähigkeit wäre tief in der Core Execution Loop hardcoded. Ist sie aber nicht. Die Magie hinter dem File System eines Agents basiert komplett auf composable Middleware, die du selbst erweitern kannst. Heute geht es darum, das Harness mit Middleware zu erweitern. Deep Agents ist keine Black Box. Das Harness, das die Execution Pipeline steuert, ist extrem erweiterbar. Wenn du einen Agent mit einem File System oder einer Todo Liste ausstattest, hängst du eigentlich nur pre-packaged Middleware an dieses Harness. Middleware sitzt genau an der Grenze zwischen der Entscheidung des Agents, einen Tool Call zu machen, und der tatsächlichen Execution von diesem Tool. Sie ist ein Interceptor. Sie gibt dir die absolute Kontrolle darüber, was reingeht, was rauskommt und was während des Austauschs geloggt wird. Um deine eigene Custom Middleware zu schreiben, erstellst du eine Interceptor Funktion und wendest einen speziellen Decorator namens wrap tool call an. Dieser Decorator registriert deine Funktion beim Harness. Wenn der Agent ein Tool triggert, pausiert das Harness den Default Flow und übergibt die Kontrolle an deine wrapped Funktion. Innerhalb dieses Interceptors erhältst du die vom Agent generierten raw Input Arguments, eine Referenz auf das aufgerufene Tool und den aktuellen Graph State. Du führst das ursprüngliche Tool manuell aus deiner Funktion heraus aus, fängst den Output ab und gibst diesen Output dann an das Harness zurück. Stell dir eine Custom Middleware vor, die gebaut wurde, um eine externe API zu monitoren. Du willst jeden API Tool Call abfangen, die genauen Arguments loggen, die der Agent verwendet hat, und Usage Metrics tracken, um Rate Limits zu vermeiden. Deine wrap tool call Funktion fängt den Request ab, bevor er das Netzwerk erreicht. Sie extrahiert den Payload, schreibt ihn in deine Application Logs und führt dann den eigentlichen API Request aus. Sobald der Request abgeschlossen ist, empfängt die Middleware die Response Data. Jetzt muss sie loggen, dass ein Call gemacht wurde. Pass an dieser Stelle gut auf. Beim Tracken von Usage Metrics versuchen Developer oft, Standard Class Instance Variables zu verwenden. Sie schreiben einfach so etwas wie self dot api call count plus equals one. Das ist ein fataler Fehler. Deep Agents führen Tools und Subagents routinemäßig parallel aus. Wenn mehrere Tools im selben Moment resolven und versuchen, dieselbe Instance Property direkt zu mutieren, verursachst du Race Conditions. Deine Counter werden sich gegenseitig überschreiben, Updates werden gedroppt und deine Metrics werden komplett falsch sein. Um Daten sicher zu managen, musst du stattdessen den Graph State updaten. Der Graph State ist explizit dafür designt, Parallel Execution zu handlen. Anstatt eine Local Variable zu modifizieren, liest deine Middleware die aktuelle Metric aus dem Graph State, berechnet den neuen Wert und gibt ein geupdatetes State Object zusammen mit dem Tool Result per yield zurück. Das Execution Harness übernimmt von da an. Es verarbeitet alle eingehenden State Updates von parallelen Tool Executions und führt sie sauber ohne Collisions zusammen. Indem alle Side Effects und das Metric Tracking über den Graph State geroutet werden, bleibt deine Middleware komplett thread-safe. Wenn du dieses Pattern verstehst, erschließt sich dir das gesamte Framework. Du hörst auf, den Agent als geschlossenes System zu behandeln, und fängst an, ihn als transparente Pipeline zu sehen, in der jede Action sicher intercepted und gemessen werden kann. Das war es für diese Folge. Bis zum nächsten Mal!

Hallo, hier ist Alex von DEV STORIES DOT EU. Deep Agents, Folge 9 von 16. Ein AI Coding Assistant ist toll, bis du ihn zum fünfzigsten Mal daran erinnern musst, dass dein Projekt Strict Typing und Snake Case Variablen erfordert. Die Lösung lautet: Project Conventions via Memory Files. Developer Ergonomics verlangt, dass sich deine Tools an deine Codebase anpassen, nicht umgekehrt. Du solltest nicht in jeden einzelnen Prompt einen Styleguide einfügen müssen. Deep Agents löst das, indem es dem Agenten über eine spezielle Datei namens AGENTS dot md Persistent Memory gibt. Leute verwechseln manchmal Memory mit Skills. Memory bildet deine universelle Baseline. Es wird beim Startup immer geladen und ist damit perfekt für globale Conventions und Architekturregeln. Skills sind funktionale Tools, die der Agent nur dann dynamisch lädt, wenn ein bestimmter Task sie erfordert. Heute schauen wir uns ausschließlich Memory an. Wenn du einen Agenten initialisierst und den Memory-Parameter übergibst, injected das Framework den Inhalt der AGENTS dot md Datei automatisch direkt in den Agent Context, bevor er mit der Arbeit beginnt. Diese Operation basiert auf dem Memory-First-Protokoll, das drei verschiedene Phasen für den Agenten vorgibt: Research, Response und Learning. In der Research-Phase liest der Agent das Memory File, um das Environment zu verstehen. In der Response-Phase generiert er den Code oder beantwortet den Prompt. Dann kommt die Learning-Phase. Hier ist der entscheidende Punkt: Du musst die AGENTS dot md Datei nicht manuell schreiben. Der Agent aktualisiert diese Datei selbstständig basierend auf deinem Feedback. Nehmen wir ein konkretes Szenario. Du bittest den Agenten, einen neuen API Endpoint zu generieren. Er schreibt funktionsfähigen Code, aber er formatiert die Variablen in CamelCase. Du lehnst den Pull Request ab und antwortest, dass dieses Projekt strikt Snake Case verwendet. Der Agent korrigiert den Code, aber er belässt es nicht dabei. Er geht in die Learning-Phase, öffnet die lokale AGENTS dot md Datei und hängt eine neue Regel an, die Snake Case für alle zukünftigen Variablen vorschreibt. Wenn du das nächste Mal einen Endpoint anforderst, liest der Agent dieses Memory File während seiner Research-Phase und schreibt von Anfang an nativ in Snake Case. Dieses Persistent Memory System arbeitet in zwei verschiedenen Scopes. Erstens: der Global Scope. Diese Datei liegt in deinem User Home Directory, in einem dot deepagents Ordner. Das nutzt du für deine persönlichen Developer Preferences. Wenn du über all deine Projekte hinweg immer asynchrones Python gegenüber synchronem Code bevorzugst, lernt der Agent das hier. Zweitens: der Project Scope. Diese Datei liegt direkt in deinem lokalen Repository-Ordner. Hier kommen die Repository-spezifischen Regeln rein. Wenn ein Agent läuft, lädt er beide Dateien. Er wendet zuerst deine globalen Preferences an und legt dann die Projekt-spezifischen Conventions darüber. Da das Project-scoped Memory File in deinem Repository liegt, committest du es in die Version Control. Wenn ein neuer Developer dem Team beitritt und den Agenten ausführt, erbt seine lokale Instanz sofort alle stilistischen Entscheidungen, die der Agent bereits gelernt hat. Jeder korrigierte Fehler verbessert dauerhaft das Verständnis des Agenten für dein Repository und macht ihn von einem generischen Code Generator zu einem hochgradig kontextualisierten Maintainer. Das war's für diese Folge. Bis zum nächsten Mal!

Hallo, hier ist Alex von DEV STORIES DOT EU. Deep Agents, Folge 10 von 16. Wenn du fünfzig verschiedene API-Dokumentationen in deinen System Prompt packst, wird dein Agent dadurch nicht intelligenter. Er wird nur abgelenkt und scheitert an grundlegenden Tasks. Du brauchst einen Weg, einem Agenten tiefes Fachwissen zu geben, ohne das Context Window zu sprengen. Progressive Disclosure mit Skills löst genau dieses Problem. Ein Skill in Deep Agents funktioniert wie ein modulares Gehirn-Upgrade. Er erlaubt es dir, komplexe Logik, wie AWS Deployment-Regeln oder Custom Data Science Workflows, in einem isolierten Directory zu bündeln. Um einen zu bauen, erstellst du einfach einen neuen Ordner, benennst ihn nach deinem Skill und legst eine Datei namens skill dot md rein. Ein häufiges Missverständnis ist, dass das Framework den gesamten Inhalt dieser Datei einfach an den System Prompt anhängt. Das tut es nicht. Das würde uns direkt wieder zum Problem des überladenen Context Windows zurückwerfen, die Performance verschlechtern und die Kosten in die Höhe treiben. Stattdessen nutzt das Framework ein Pattern namens Progressive Disclosure, das in drei Schritten abläuft: Match, Read und Execute. Ganz oben in deiner skill dot md Datei schreibst du einen Frontmatter-Block. Dieser ist als einfaches YAML formatiert und enthält nur einen Namen und eine kurze Beschreibung. Hier ist der entscheidende Punkt: Das Framework lädt nur diese kurze Beschreibung in den initialen System Prompt. Der Agent liest die Beschreibung und entscheidet, ob sie zum aktuellen User Request passt. Das ist die Match-Phase. Wenn der Agent entscheidet, dass der Skill relevant ist, rät er nicht, was als Nächstes zu tun ist. Er nutzt aktiv ein internes Tool, um den Rest der skill dot md Datei abzurufen. Das ist die Read-Phase. Jetzt hat der Agent die kompletten, detaillierten Anweisungen für diesen spezifischen Turn temporär in seinen Arbeitsspeicher geladen. Schließlich geht er in die Execute-Phase über, in der er diese detaillierten Anweisungen befolgt, um den Task abzuschließen. Wenn die Konversation zu einem anderen Thema wechselt, wird die schwere Payload verworfen, und der Agent kehrt in seinen Baseline State zurück. Stell dir ein Szenario vor, in dem du einen Skill namens langgraph-docs bauen willst. Dein skill dot md Frontmatter hat eine Beschreibung, die besagt, dass dieser Skill Anweisungen und interne URLs für die Suche in der LangGraph-Dokumentation bereitstellt. Der Body der Datei enthält diese tatsächlichen internen URLs und die spezifische Suchmethodik. Wenn ein User fragt, was LangGraph ist, checkt der Agent seine aktiven Skills. Er sieht die kurze Beschreibung, merkt, dass er mehr Informationen braucht, um die Frage zu beantworten, und fordert das komplette Dokument an. Er liest die URLs, führt die Suche durch und formuliert eine präzise Antwort. Ohne Progressive Disclosure müsstest du all diese URLs für jede einzelne Konversation in den Main Prompt packen. Wenn du eine Library von Skills aufbaust, könntest du auf Konflikte stoßen, bei denen zwei Skills versuchen, Anweisungen für ähnliche Tasks zu definieren. Deep Agents löst das über Source Precedence. Die Regel ist simpel: Der Letzte gewinnt. Welcher Skill auch immer zuletzt geladen wird, überschreibt widersprüchliche Anweisungen von früheren. Das erlaubt es dir, zuerst breite, generische Skills zu stacken und dann später in deiner Configuration hochspezifische Overrides darüberzulegen. Die Execution deines gesamten Agentic Workflows hängt davon ab, wie gut du dieses Frontmatter schreibst. Halte deine Beschreibungen präzise und deine Skill-Bodies sehr detailliert, denn der Agent wird die komplette Datei nur lesen, wenn du sie ihm zuerst über die Beschreibung verkaufst. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Deep Agents, Folge 11 von 16. Ein smarter Assistent sollte dich nicht bei jedem Start einer neuen Conversation fragen, welche Database du benutzt. Dennoch leiden die meisten Agents out of the box unter totaler Amnesie, sobald ein Thread endet. Um das zu lösen, brauchst du Long-term Memory Stores. Wenn du einen Agent ausführst, generiert er Files. Zuhörer nehmen oft an, dass ein File für immer existiert, wenn ein Agent es schreibt. Tut es aber nicht. By default ist alles ephemeral. Deep Agents nutzen ein StateBackend, das Files im State des aktuellen Conversation-Threads speichert. Wenn dieser Thread endet, verschwinden diese Files. Wenn du echte Personalization willst, bei der der Agent eine lebenslange Database mit User-Preferences und Projektwissen aufbaut, brauchst du einen anderen Ansatz. Du brauchst das StoreBackend. Das verbindet sich direkt mit einem persistenten LangGraph Store und hält die Daten über mehrere Threads hinweg sicher. Aber du willst nicht jedes einzelne temporäre File, das dein Agent erstellt, persistieren. Du brauchst einen Mechanismus, um ephemere Scratchpad-Arbeit von dauerhaften Memories zu trennen. Hier kommt das CompositeBackend ins Spiel. Stell es dir wie einen Traffic-Router für dein Agent-File-System vor. Du konfigurierst das CompositeBackend mit einem Default-Fallback, normalerweise dem ephemeren StateBackend. Dann registrierst du explizit eine Route für deinen Long-term Storage. Du sagst dem Router, dass jeder File-Path, der mit dem Directory-Prefix slash memories slash beginnt, vom StoreBackend verarbeitet werden muss. Pass an dieser Stelle gut auf. Diese Persistence ist nicht automatisch. Du musst den slash memories slash Path spezifisch an den Store routen. Wenn du diesen Routing-Schritt überspringst, schreibt der Agent die Memory-Files einfach in den ephemeren State, und sie werden gelöscht, wenn der Thread endet. Sobald du eine persistente Database einführst, stehst du vor einem neuen Problem. Du kannst nicht zulassen, dass ein User die gespeicherten Preferences eines anderen Users liest. Um das zu verhindern, nutzt das StoreBackend Namespace Factories. Eine Namespace Factory ist einfach eine Function, die basierend auf dem aktuellen Context einen Isolation Layer injectet. Anstatt ein File global zu speichern, generiert die Factory ein Prefix-Array, wie das Wort users gefolgt von der eindeutigen User-ID. Jedes Mal, wenn der Agent mit dem StoreBackend interagiert, scopt die Database die Operation automatisch auf genau diesen User-Namespace. Schauen wir uns an, wie das in der Praxis abläuft. Du startest Conversation eins. Du erwähnst, dass du eine React-Application baust. Der Agent notiert sich das und schreibt eine Summary in ein File namens project notes dot txt und legt es spezifisch im slash memories slash Directory ab. Das CompositeBackend sieht dieses Directory-Prefix, fängt den Write-Command ab und routet ihn an das dauerhafte StoreBackend unter deinem isolierten User-Namespace. Morgen startest du Conversation zwei. Das ist ein komplett neuer Thread mit null unmittelbarem Context. Du stellst eine Frage über State-Management-Frameworks. Bevor er antwortet, checkt der Agent sein slash memories slash Directory. Das CompositeBackend routet den Read-Request an den persistenten Store. Der Agent liest deine Project-Notes, sieht die React-Details und liefert eine hochrelevante Antwort, die genau auf deinen spezifischen Stack zugeschnitten ist. Der Context wird perfekt übernommen, obwohl die Threads getrennt sind. Cross-Thread-Persistence erfordert ein bewusstes Design, indem spezifische Directories an einen persistenten Store geroutet und mit User-spezifischen Namespaces geschützt werden. Danke, dass du ein paar Minuten mit mir verbracht hast. Bis zum nächsten Mal, machs gut.

Hallo, hier ist Alex von DEV STORIES DOT EU. Deep Agents, Folge 12 von 16. Es ist beeindruckend, wenn eine KI Code schreibt. Aber diese KI den gerade geschriebenen Code blindlings direkt auf deinem Laptop ausführen zu lassen, ist eine furchtbare Idee. Um das zu lösen, brauchst du einen sicheren Ort, an dem der Agent seine Logik verifizieren kann, ohne deine Host Machine zu gefährden. Genau darüber sprechen wir heute: Codeausführung in Sandboxes. Wenn ein Agent keinen Code ausführen kann, kann er nicht verifizieren, ob sein Code tatsächlich funktioniert. Er verlässt sich dann rein auf seine Trainingsdaten, um zu erraten, ob ein Script korrekt ist. Sandboxes geben dem Agenten einen sicheren Playground, um zu iterieren, Fehler zu machen und Bugs basierend auf echtem Execution Output zu fixen. Bevor wir uns die Mechanics ansehen, müssen wir ein häufiges Missverständnis klären. Du nimmst vielleicht an, dass der Agent selbst in der Sandbox deployed und ausgeführt werden muss. Das ist nicht der Fall. Deep Agents setzen auf das Sandbox as Tool Pattern. Die Agenten-Logik, Memory und Prompts leben sicher auf deinem Server. Der Agent pusht einfach Shell Commands und Code über eine API an eine isolierte Remote-Umgebung. Diese Interaktion passiert über das Execute Tool. Wenn der Agent entscheidet, dass er ein Script ausführen muss, ruft er das Execute Tool auf und übergibt den generierten Code Block. Dieses Tool leitet den Payload an ein Sandbox Backend weiter. Provider wie Modal, Daytona und Runloop stellen diese Umgebungen bereit. Sie provisionieren einen sicheren Container, führen den Code aus und geben den Standard Output oder Error Logs an den Agenten zurück. Die Sandbox schafft eine strikte Isolationsgrenze zwischen dem Execution Space und deinem System. Stell dir einen Agenten vor, der die Aufgabe hat, ein kleines Python Package zu erstellen und eine Test Suite mit pytest auszuführen. Der Agent sitzt auf deinem Server. Er nutzt das Execute Tool, um einen temporären Remote-Server zu erreichen. Zuerst sendet er einen Command, um die benötigten Libraries zu installieren. Dann schreibt er die Python-Files in das Sandbox Directory. Schließlich sendet er einen Command, um pytest auszuführen. Die Sandbox führt diese Schritte aus und gibt den Terminal Output zurück. Wenn ein Test fehlschlägt, liest der Agent den Error aus der API Response, updatet den Code und ruft das Execute Tool erneut auf. Der Agent kann builden, testen und alles wieder auf null setzen, während deine Host Machine komplett unberührt bleibt. Wenn du ein Sandbox Backend konfigurierst, musst du seinen Lifecycle definieren. Es gibt zwei Hauptansätze. Der erste ist Thread-scoped. Hier ist die Sandbox an einen bestimmten Conversation Thread gebunden. Wenn die Conversation startet, wird eine frische Sandbox hochgefahren. Wenn die User Session endet, wird die Sandbox zerstört. Das sorgt für einen Clean Slate bei jeder Interaktion und ist ideal für Single-Task Operations, bei denen Daten nicht persistieren müssen. Der zweite Ansatz ist Assistant-scoped. In diesem Model ist die Sandbox an den Agenten selbst gebunden, unabhängig von der aktiven Conversation. Jeder Thread, der mit diesem Agenten interagiert, teilt sich exakt denselben Sandbox State. Wenn ein Thread eine bestimmte Version einer Library installiert oder ein großes Dataset herunterlädt, bleiben diese Files für den nächsten Thread verfügbar. Das ist die richtige Wahl, wenn dein Agent als persistenter Worker agiert und einen stabilen, fortlaufenden Workspace braucht. Hier ist die wichtigste Erkenntnis: Das Execution Environment bestimmt die Capabilities des Agenten. Indem du den Sandbox Lifecycle kontrollierst und strikte API Boundaries erzwingst, gibst du dem Agenten die Freiheit, Fehler zu machen, ohne deine Infrastruktur zu gefährden. Die wahre Power eines Agenten ist nicht nur das Generieren von Code, sondern das Iterieren bei Fehlern, und Remote Sandboxes bieten den einzigen sicheren Weg, diese Iteration automatisch ablaufen zu lassen. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Deep Agents, Folge 13 von 16. Du feuerst eine komplexe Query ab, dein Supervisor Agent delegiert an drei parallele Subagents, und dein User starrt zwei Minuten lang auf einen generischen Loading Spinner. Das ist eine furchtbare User Experience, und um das zu fixen, musst du genau sichtbar machen, was unter der Haube passiert. Die Lösung heißt Subgraph Streaming UX. Multi-Agent Workflows sind von Natur aus asynchron und langsam. Wenn ein Main Agent Tasks delegiert, entsteht eine Black Box. Wenn du einfach auf das finale kombinierte Resultat wartest, denkt der User, dass die App eingefroren ist. Du musst die Aktivität der Subagents direkt ans Frontend streamen. Ein häufiger Fehler, den Developer hier machen, ist die Annahme, dass, wenn Subagents Tokens streamen, diese Tokens einfach blind an den Output Stream des Main Agents angehängt werden. Wäre das der Fall, würden sich die parallelen Outputs zu einem unleserlichen Textbrei vermischen. Stattdessen regelt das Framework das, indem es jedes einzelne Event in einen eigenen Namespace isoliert. Damit das funktioniert, nutzt du das Version 2 Streaming Format und übergibst ein Flag, das subgraphs auf true setzt, wenn du deinen Stream aufrufst. Wenn du das machst, liefert der Stream keine rohen Text Chunks mehr. Er liefert Dictionaries. Jedes Dictionary enthält drei spezifische Keys: type, ns und data. Type sagt dir, welche Art von Event du dir gerade ansiehst. Data enthält die eigentliche Payload oder das Text Token. Und ns steht für Namespace. Das ist der entscheidende Punkt. Der Namespace ist ein Tuple, das den genauen Pfad der Node definiert, die das Event generiert hat. Wenn ein Chunk vom Main Agent kommt, ist das Namespace Tuple leer. Wenn er von einem Subagent kommt, enthält der Namespace den Pfad. Das sieht dann aus wie ein Tuple, das das Wort tools enthält, gefolgt von einer eindeutigen Subagent ID. Angenommen, du baust ein Frontend Dashboard. Ein User bittet das System, einen Urlaub zu planen. Der Supervisor Agent spawnt drei separate Subagents: einen für Flüge, einen für Hotels und einen für Aktivitäten. In deinem Frontend Code loopst du über den eingehenden Stream. Indem du den Namespace Key bei jedem Dictionary Chunk checkst, weißt du genau, welcher Subagent dieses spezifische Token generiert hat. Du kannst diese Daten dann an separate UI Components routen. Statt eines einzelnen, hängenden Loading Spinners sieht dein User drei individuelle Loading Bars oder Textfenster, die sich nebeneinander in Echtzeit mit Outputs füllen. Manchmal musst du Informationen streamen, die nicht nur ein Language Model Token sind. Vielleicht willst du ein Custom Status Update pushen, zum Beispiel um die UI zu benachrichtigen, dass eine externe API aufgerufen wird. Das kannst du von innerhalb einer Node mit der getStreamWriter Funktion machen. Du holst dir den Writer, übergibst ihm dein Custom Dictionary, und er injectet diese Daten direkt in den gesamten Stream unter dem aktuellen Subagent Namespace. Das Frontend empfängt das genau wie jedes andere Event und updatet die richtige, spezifische Loading Bar. Wenn du helfen willst, die Show am Laufen zu halten, kannst du uns supporten, indem du auf Patreon nach DevStoriesEU suchst. Multi-Agent Transparenz ist im Grunde ein Routing-Problem; das Mappen von Namespace Tuples auf unabhängige UI Components ist das, was eine frustrierende Black Box in eine Premium User Experience verwandelt. Das war's für dieses Mal. Danke fürs Zuhören, und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Deep Agents, Folge 14 von 16. Was wäre, wenn du deinen lokalen Terminal-Agenten mit der proprietären Datenbank deiner Firma verbinden könntest, ohne eine einzige Zeile Python-Code zu schreiben? Genau wegen dieser Möglichkeit schauen wir uns heute die Deep Agents CLI und externe MCP-Tools an. Das Deep Agents SDK bringt von Haus aus ein eingebautes Command Line Interface mit. Du startest den Prozess und bekommst einen Terminal Prompt, wo du mit deinem Agenten chatten kannst. Du kannst das Core Brain des Agenten direkt aus diesem Prompt heraus steuern. Wenn du eine leistungsfähigere Reasoning Engine brauchst, tippst du einfach slash model, gefolgt vom neuen Model Identifier. Die CLI macht sofort einen Hot-Swap des Providers, und du machst einfach mit deiner Session weiter. Aber ein Terminal-Agent, der nur chattet, ist nicht besonders nützlich. Er braucht Zugriff auf deine eigentliche Arbeit. Normalerweise musst du eigenen Python-Wrapper-Code schreiben, um die API Calls zu handlen, wenn du einem Agenten Zugriff auf ein GitHub Repository oder eine lokale Datenbank geben willst. Die CLI vermeidet das komplett, indem sie das Model Context Protocol nutzt, besser bekannt als MCP. Es gibt oft Verwirrung darüber, was MCP eigentlich genau ist. Es ist keine Python Library, die du in deinen Agenten-Code importierst. Ein MCP-Server ist ein komplett separater Prozess oder eine Remote URL. Er fungiert als standardisierter Wrapper um ein externes System. Wenn die CLI startet, redet sie mit diesem separaten Prozess, fragt, welche Tools er bereitstellt, und lädt diese dynamisch. Du konfigurierst diese Connection über eine einfache Textdatei namens dot mcp dot json. Diese Datei ist das Herzstück von Zero-Code-Integrations. Wenn du die Deep Agents CLI startest, führt sie eine Auto-Discovery durch. Sie sucht in deinem aktuellen Directory nach dieser JSON-Config. Wenn sie eine findet, verbindet sie sich mit den dort gelisteten Servern, registriert deren Tools und übergibt sie an deinen Agenten. Diese Config-Datei unterstützt zwei Transport-Mechanismen. Der erste ist Standard Input und Output, oder stdio. Das ist für lokale Server. Die CLI spawnt den Server als Background-Prozess auf deiner Maschine und kommuniziert mit ihm über Standard Terminal Streams. Der zweite Transport-Typ basiert auf HTTP und Server-Sent Events. Das nutzt du, wenn dein MCP-Server remote gehostet wird, vielleicht irgendwo in einem privaten Firmennetzwerk. Weil stdio-Server lokale Commands ausführen, hat Security höchste Priorität. Die CLI pflegt einen lokalen Trust Store für Server auf Project-Level. Wenn die CLI zum allerersten Mal einen neuen lokalen Server-Command in deiner dot mcp dot json Datei erkennt, hält sie an und fragt nach expliziter Permission. Sobald du das bestätigst, wird der Hash dieses Commands in deinem Trust Store gespeichert, und zukünftige Runs verbinden sich automatisch. Schauen wir uns ein konkretes Szenario an. Du willst, dass dein Agent Files von deiner lokalen Disk liest. Du erstellst eine dot mcp dot json Datei. Darin definierst du einen Server-Block und nennst ihn local-filesystem. Du setzt den Transport-Typ auf stdio. Für die Command Line sagst du ihm, dass er das Node Package Manager Tool, npx, ausführen soll. Das lässt du auf einen pre-built Community-Server namens server-filesystem zeigen, zusammen mit dem Directory-Pfad, den du exposen willst. Du speicherst das File und startest die Deep Agents CLI. Hier ist der entscheidende Punkt. Die CLI spawnt diesen npx Command automatisch im Background. Der Filesystem-Server bootet und broadcastet, dass er Tools zum Lesen von Files und Auflisten von Directories hat. Die CLI fängt diesen Broadcast ab und rüstet deinen Agenten damit aus. Du kannst sofort in dein Terminal tippen und den Agenten bitten, dein System Log File zu lesen. Der Agent versteht, dass er das Tool hat, callt den Background-Prozess, holt sich die File-Contents und beantwortet deine Frage. Du hast gerade einem AI-System sicheren Zugriff auf deine lokale Disk gegeben, und das mit nur ein paar Zeilen Config-Text. Indem es die Tool-Logik von deiner Python Application entkoppelt, verwandelt MCP dein Terminal von einem simplen Chat Interface in ein erweiterbares Control Center. Das war's für diese Folge. Bis zum nächsten Mal!

Hallo, hier ist Alex von DEV STORIES DOT EU. Deep Agents, Folge 15 von 16. Warum sich mit einem generischen Coding Assistant zufriedengeben, wenn du deinen eigenen, stark angepassten LangGraph-Agenten direkt in deinen Code-Editor integrieren kannst? Das Protokoll, das deinen maßgeschneiderten Agenten aus dem Terminal in deinen täglichen Workflow holt, ist die Editor Integration via ACP. Bevor wir weitermachen, müssen wir eine Akronym-Kollision klären. Du hast wahrscheinlich schon von MCP, dem Model Context Protocol, gehört. MCP verbindet deinen Agenten mit externen Tools und ermöglicht ihm so, eine Datenbank zu durchsuchen oder ein File System zu lesen. ACP, das Agent Client Protocol, ist etwas völlig anderes. ACP verbindet deinen Agenten mit externen IDEs wie Zed oder VSCode. Das eine verbindet den Agenten mit externen Daten, das andere verbindet den Agenten mit deinem Workspace. ACP ist ein standardisierter Communication Layer. Er definiert genau, wie eine Integrated Development Environment Text Selections, File Structures und User Prompts an einen AI-Agenten sendet. Er legt außerdem fest, wie dieser Agent Code Insertions, File Diffs und Chat Responses zurücksendet. Indem du dieses Protokoll implementierst, verhält sich dein Custom Deep Agent genau wie ein Standard-Assistant in deinem Editor. Der Unterschied ist, dass er über all die spezifischen Memory Structures, Custom Prompt Templates und spezialisierten internen Tools verfügt, die du in ihn eingebaut hast. Um diese Lücke zu schließen, installierst du das Package deepagents-acp. Die Integration erfordert ein sehr kurzes Python-Script als Entry Point. In diesem Script instanziierst du deinen vorkonfigurierten Deep Agent. Dann, anstatt einen Webserver oder einen Command-Line Loop zu starten, wrappst du deinen Agenten in ein ACP Server Interface. Das erreichst du, indem du eine dedizierte Run-Funktion aufrufst und ein AgentServerACP-Objekt übergibst, das selbst deine zugrundeliegende Agenten-Logik wrappt. Hier ist der entscheidende Punkt. Wenn du diesen Server konfigurierst, stellst du ihn so ein, dass er Standard Input und Output verwendet, allgemein bekannt als stdio-Modus. Das ist extrem wichtig, denn es bedeutet, dass keine Network Ports verwaltet, keine Firewall-Regeln umgangen und keine Web Sockets debuggt werden müssen. Der Agent-Prozess lauscht einfach auf eingehende Text Strings am Standard Input und gibt seine strukturierten Responses auf dem Standard Output aus. Als Nächstes musst du deinen Editor mit diesem Script verbinden. Nehmen wir den Zed-Editor als konkretes Szenario. In Zed öffnest du deine User Settings JSON-Datei. Du fügst einen Configuration Block hinzu, der den Editor anweist, einen Custom Agent zu verwenden. Anstatt Zed auf einen Remote REST API Endpoint zeigen zu lassen, verweist du direkt auf deine lokale Python Executable und übergibst den Pfad zu deinem neuen ACP-Script als primäres Argument. Wenn du eine Session startest, spawnt der Editor dein Python-Script als versteckten Background Process. Jedes Mal, wenn du nach einem Inline Edit fragst oder eine Funktion fürs Refactoring highlightest, sendet der Editor eine strukturierte ACP Message über den Standard Input direkt an dein laufendes Script. Dein Custom Agent verarbeitet den Request, durchläuft seinen internen Node Graph, fragt sein Memory ab und gibt die ACP-formatierte Response zurück auf dem Standard Output aus. Der Editor fängt diesen Output ab und wendet die Code Changes nativ in deinem Application Window an. Das mit Abstand wichtigste Takeaway hier ist Kontrolle. Indem du deinen Custom Agent über ACP via stdio routest, verlässt du dich nicht länger auf einen generischen Assistant, sondern fängst an, mit einer Entität zu kollaborieren, die deine spezifischen Codebase Conventions von Grund auf versteht. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Deep Agents, Folge 16 von 16. Du bittest deinen Agenten um ein massives Codebase Refactor, und das Chat-Interface friert sofort ein. Du starrst zwanzig Minuten lang auf ein sich drehendes Ladesymbol und kannst weder Fragen stellen noch deine Meinung ändern. Um das zu beheben, brauchst du Background Workers mit Async Subagents. Standard-Subagents sind synchron. Sie blockieren den Main Thread. Der Supervisor übergibt einen Task und wartet einfach, bis er abgeschlossen ist. Async Subagents ändern diese Dynamik komplett, indem sie als non-blocking Background Workers laufen. Wenn der Supervisor Arbeit zuweist, wartet er nicht auf das Ergebnis. Er bekommt sofort eine Job-ID und gibt die Kontrolle an den User zurück. Das User Interface bleibt responsive, während das Heavy Lifting woanders passiert. Du konfigurierst diese Background Workers über die Async SubAgent Spezifikation. Wenn du deine Applikation auf LangSmith Deployments deployst, werden diese Async Subagents unabhängig gehostet. Der Main Supervisor kommuniziert mit ihnen über Standard-Transportprotokolle. Wenn du den Worker auf exakt demselben Server wie den Supervisor deployst, kommunizieren sie über ASGI, was für lokales Routing extrem effizient ist. Wenn der Worker auf einem separaten Remote-Server liegt, verbindet sich der Supervisor über HTTP mit ihm. Um diese Remote Workers zu orchestrieren, ist der Supervisor mit einer speziellen Suite von Async Tools ausgestattet. Denk nochmal an diese Codebase Refactor Anfrage zurück. Der User bittet um den Rewrite. Der Supervisor entscheidet, dass das lange dauern wird, und ruft das start async task tool auf. Dieses Tool startet den Coder Subagent und übergibt dem Supervisor eine Job-ID. Der Supervisor antwortet dem User und bestätigt, dass der Background Job läuft. Weil der Main Thread frei ist, kann der User die Konversation fortsetzen. Ein paar Minuten später fragt der User vielleicht, wie das Refactor läuft. Der Supervisor ruft das check async task tool auf, übergibt die Job-ID und holt sich den aktuellen Execution Status vom Worker. Hier ist der entscheidende Punkt. Der User ist nicht aus dem Prozess ausgesperrt, während der Worker läuft. Wenn der User plötzlich merkt, dass das Refactor striktes Type Hinting erzwingen soll, kann er das dem Supervisor einfach sagen. Der Supervisor ruft dann das update async task tool auf. Das pusht neue Mid-Flight Steering Instructions direkt an den laufenden Subagent, ohne den Job komplett neu zu starten. Wenn der User entscheidet, dass das Refactor generell eine schlechte Idee war, nutzt der Supervisor das cancel async task tool, um den Background Process sauber zu beenden. Ein häufiger Verwirrungspunkt ist, wie sich der Supervisor diese Jobs während einer langen Session merkt. Mit der Zeit werden Chat Histories komprimiert, um Context Tokens zu sparen. Wenn die Job-ID nur als Text in der Conversation History existieren würde, würde der Supervisor sie irgendwann vergessen und den Worker aus den Augen verlieren. Um das zu verhindern, werden Task Metadata niemals nur im Chat Log gespeichert. Sie werden in einem dedizierten State Channel namens async tasks gespeichert. Dieser State Channel arbeitet unabhängig von der Message List und garantiert, dass aktive Job-IDs jede Conversation Compaction überleben. Der Wechsel von Blocking Calls zu Background Workers verschiebt deine Architektur von einem simplen Chat-Interface zu einer Parallel Orchestration Engine, die massive Workloads bewältigen kann. Da das unsere aktuelle Serie abschließt, ermutige ich dich, die offizielle Dokumentation zu lesen, selbst mal einen Async Worker zu deployen oder devstories dot eu zu besuchen, um Themen für unsere nächste Runde vorzuschlagen. Danke, dass du ein paar Minuten mit mir verbracht hast. Bis zum nächsten Mal, mach's gut.