LangChain startet Managed Deep Agents als öffentliche Beta in der LangSmith Cloud

Ein Agent als Projektordner

Laut LangChain ist ein Managed Deep Agent ein ganz normales Python-Projekt. Die einzige Pflichtdatei ist agent.py, die den Agenten mit define_deep_agent definiert. Der System-Prompt liegt in instructions.md, und jeder Ordner unter skills/ enthält ein Playbook, das der Agent lädt, wenn eine Aufgabe es erfordert. Tools sind gewöhnliche Python-Funktionen unter tools/, während tools/mcp.py Tools von entfernten MCP-Servern einbindet.

Entwickler testen den Agenten lokal mit mda dev. Der Befehl startet einen lokalen Agent Server und öffnet den Agenten in LangSmith Studio, wo sich mit ihm chatten und seine Traces untersuchen lassen. mda deploy überträgt das Projekt zu LangSmith und hinterlegt den Schlüssel des Modellanbieters im Deployment. Nach Angaben des Unternehmens lief das Produkt erstmals am 13. Mai 2026 in einer privaten Beta. Der Beitrag wurde am 2. November 2026 aktualisiert, um die öffentliche Beta zu beschreiben.

Produktionsfunktionen als Dateien

LangChain argumentiert, dass es immer einfacher wird, einen leistungsfähigen Agenten zu bauen, der Betrieb in der Produktion aber weiterhin viel Arbeit macht. Agenten brauchen Threads, die Neustarts überstehen, einen sicheren Ort zur Codeausführung, Speicher, der über Gespräche hinweg erhalten bleibt, und ein Protokoll ihrer Aktionen. Geplante Läufe erfordern zudem einen Cron-Server. Managed Deep Agents soll den Teams diese Schicht abnehmen, und jedes Deployment läuft auf dem LangSmith Agent Server.

Jede verwaltete Funktion ist eine Datei oder ein Ordner, und mda deploy richtet alles ein, was es findet:

• Memory: Standardmäßig merkt sich ein Agent nur den aktuellen Thread. Mit memory.py bleibt Wissen über Threads hinweg erhalten, in einer gemeinsamen Ebene, einer privaten Ebene pro Nutzer oder in beiden.
• Schedules: Eine Datei unter schedules/ führt den Agenten nach Cron-Zeitplan aus.
• Channels: Über channels/slack.py können Nutzer Läufe aus Slack starten. Jeder Dienst, der einen Webhook senden kann, startet Läufe per HTTP.
• Sandbox: sandbox/ gibt dem Agenten ein isoliertes Dateisystem und eine Shell, in der er den von ihm geschriebenen Code ausführt.
• Identität und Verbindungen: identity.py authentifiziert Aufrufer, und Verbindungen speichern API-Schlüssel und führen OAuth aus, damit Endnutzer ihre eigenen Konten freigeben.
• Subagenten und Evals: Subagenten werden in der Agentendefinition deklariert, und mda evals init -i richtet unter evals/ einen Harbor-Eval-Workspace ein.

Einige Funktionen kommen ohne Datei aus. Der Agent kann eine integrierte Websuche von Parallel nutzen, ohne separates Konto oder eigenen API-Schlüssel, und er kann in einem Browser arbeiten und die Kontrolle an den Nutzer übergeben, wenn eine Website einen Login verlangt. Ausgewählte Tool-Aufrufe lassen sich über interrupt_on pausieren, bis ein Mensch sie freigibt.

Agenten aufrufen und verbessern

Jedes Deployment stellt die Agent-Server-API bereit, sodass eine Anwendung Threads anlegen und Läufe streamen kann oder ein Team ein eigenes Frontend baut. Zudem bieten Deployments einen MCP-Endpunkt unter /mcp, über den MCP-Clients wie Claude Code den Agenten als Tool aufrufen können.

Anweisungen und Skills liegen im LangSmith Context Hub. Bei jedem Deploy werden instructions.md und skills/ aus dem Projekt synchronisiert, und sie lassen sich im Hub ohne erneutes Deployment bearbeiten. Hat sich die Hub-Kopie seit dem letzten Deploy geändert, fragt die CLI, welche Version behalten werden soll. Auch der dauerhafte Speicher liegt im Context Hub. Läufe werden in LangSmith getrackt, und LangSmith Engine nutzt diese Traces, um wiederkehrende Probleme aufzuspüren und ihre Ursache zu diagnostizieren. Ist es mit dem Context-Hub-Repository des Agenten verbunden, kann es Korrekturen für Anweisungen und Skills vorschlagen.

Was Teams bauen und wie der Dienst zu Open Source steht

LangChain zufolge betreiben Teams in der öffentlichen Beta Agenten für die Störungsanalyse, die Slack-Alarme in einer Sandbox untersuchen, Engineering-Agenten, die per Issue-Tracker-Webhook gestartet werden, interne Assistenten etwa für HR oder Finanzen, kundennahe Agenten mit Speicher pro Nutzer, langlaufende Projektagenten sowie geplante Agenten, die Unternehmensfunktionen wie Vertrieb oder Produkt nachbilden. Außerdem laufen laut Unternehmen der eigene GTM Agent, Open SWE und Content Studio auf dem Dienst, wobei der Code von Content Studio nach dem Umzug um rund 80 Prozent schrumpfte.

Der verwaltete Dienst führt dasselbe quelloffene Harness aus, mit derselben Agentenschleife, denselben Dateisystem-Tools, Subagenten und Skills. Der Unterschied liegt darin, wer den Agenten kompiliert: create_deep_agent liefert einen kompilierten Agenten, den der Entwickler selbst ausführt und hostet, während define_deep_agent eine Definition zurückgibt, die die verwaltete Laufzeit kompiliert. Teams, die volle Kontrolle über das Hosting wollen, können das Deep Agents SDK weiterhin auf eigener Infrastruktur nutzen.

Für Entwickler lautet das Versprechen: ein kürzerer Weg vom Prototyp zum ausgerollten Agenten, ohne Server, Scheduler oder Speicherdienste zu betreiben. LangChains Quickstart führt von einem leeren Verzeichnis zu einem ausgerollten Recherche-Assistenten, und ein Tutorial ergänzt anschließend ein eigenes Suchwerkzeug, dauerhaften Speicher und einen täglichen Zeitplan.