LangChain beschreibt Speicher und Sandboxes für interne Unternehmensagenten

LangChain, Anbieter von Software für KI-Agenten, hat am 24. Oktober 2026 beschrieben, auf welchen fünf Bausteinen seine internen Agenten laufen: Slack als Arbeitsort, Identität, Speicher, eine Sandbox für Code und zeitgesteuerte Läufe. Im Firmenblog schreiben Harrison Chase und Caspar Broekhuizen, alle beteiligten Teams seien bei denselben Grundbausteinen gelandet.

Alle drei vorgestellten Agenten laufen auf Managed Deep Agents, einem Dienst von LangChain, der solche Agenten betreibt. Sandbox, dauerhafter Speicher, die Anbindung an Messaging-Dienste wie Slack und Zeitpläne sind dort laut Dokumentation Einträge in einer Projektdatei statt Dienste, die ein Team selbst baut und betreibt.

Es ist ein Herstellerbericht über eigene Agenten. Eine unabhängige Prüfung, auch der Sicherheit, ist er nicht.

Drei Agenten, ein Bauplan

Im Beitrag geht es um drei Agenten. Der GTM Agent läuft ständig und arbeitet von sich aus: Er beantwortet E-Mails, reagiert auf neue qualifizierte Leads, verschickt tägliche Briefings und beantwortet Fragen zu Kundenkonten. OpenSWE ist der Engineering-Agent: Er kann an Pull Requests arbeiten, sie entwerfen und führt außerdem Code-Reviews über alle PRs aus. Content Studio entwirft Marketingmaterial vom Blogtext bis zum Video, im Stil des Unternehmens.

Alle drei sind nach demselben Muster gebaut. Als Oberfläche dient Slack: Jeder Agent hat eine eigene Slack-App und lässt sich per Direktnachricht oder Erwähnung in einem Kanal ansprechen. Damit ein Agent eine laufende Unterhaltung zwischen Menschen nicht stört, hat LangChain eine Möglichkeit eingebaut, ihn in einen eigenen Thread im Kanal auszulagern.

Für manche Abläufe passt Slack nicht. Einzelne E-Mails, die der GTM Agent verschicken will, lassen sich laut Beitrag gut in Slack prüfen. Bei einem großen Rückstau wird das Nachverfolgen über Slack-Nachrichten jedoch mühsam, und für solche Fälle hat LangChain eine eigene Oberfläche gebaut.

Identität: In wessen Namen handelt der Agent?

Als heikelstes Problem bezeichnet LangChain die Identität, also die Frage, in wessen Namen ein Agent handelt. Üblich sind zwei Wege. Bei „On-behalf-of“ handelt der Agent im Namen der Person, die ihn aufruft. Bei festen Zugangsdaten verwendet er dieselben Credentials, egal wer ihn aufruft, etwa ein Dienstkonto.

OpenSWE nutzt je nach Auslöser beide Muster. Spricht eine Person ihn mit einer Nachricht an, handelt er in ihrem Namen und öffnet Pull Requests mit ihrem GitHub-Handle. Läuft er im Hintergrund, etwa als Code-Review-Agent, tritt er mit eigener Identität als GitHub-App auf.

Beim GTM Agent laufen manche Werkzeuge wie der Salesforce-Zugang mit fester Identität, damit sich nicht jeder anmelden muss. Andere Werkzeuge wie E-Mail handeln im Namen des Nutzers und stehen nur in Direktnachrichten zur Verfügung, in gemeinsamen Kanälen nicht. Content Studio greift auf Notion im Namen der Nutzer zu und auf Twitter mit den Zugangsdaten des Firmenkontos. Bestimmte Twitter-Operationen darf dabei nur eine freigegebene Gruppe auslösen; nicht jeder kann posten, manche können nur lesen oder entwerfen.

Auf der Plattform ist Identität ein eigener Baustein. Wer in einer Mehrbenutzer-Umgebung einen Agenten aufruft, bekommt laut Dokumentation zu Managed Deep Agents private Threads; auch Speicher und Zugangsdaten gelten dort pro Aufrufer. Verbindungen laufen über OAuth, sodass Endnutzer ihre eigenen Konten autorisieren. Ergänzend: OAuth-Berechtigungen für Agenten: Scopes erst anfordern, wenn sie gebraucht werden.

Zwei Speicherebenen

Alle Agenten haben zwei Speicherebenen: globalen Speicher, der für alle Nutzer gilt, und Nutzerspeicher, der nur für eine bestimmte Person gilt. Welche Fakten auf welcher Ebene landen, entscheiden die Agenten selbst. LangChain nennt diesen Bereich den bisher wohl am wenigsten erforschten.

Ob eine persönliche Angabe nur für eine Person gilt oder für alle Nutzer, hängt damit an einer Entscheidung des Agenten.

Auf der Plattform bleiben Präferenzen und Wissen laut Dokumentation über einzelne Threads hinweg erhalten.

Code läuft in der Sandbox, der Agent nicht

Code zu schreiben und auszuführen gehört laut LangChain für alle drei Agenten oft dazu, um Aufgaben zu erledigen. Die Agenten selbst laufen dabei außerhalb der Sandbox. Sie verbinden sich mit ihr und führen den Code dort aus. Die Sandboxen starten je Agent mit leicht unterschiedlichen Softwarepaketen, und OpenSWE wählt seine Ausgangsumgebung sogar je nach Kanal oder Nutzer.

Braucht der Code Zugang zu Diensten mit Anmeldung, nutzen alle drei den Secret-Proxy von LangSmith Sandboxes. Er soll im Beitrag sichere Verbindungen aus der Sandbox heraus ermöglichen. In der Plattform-Dokumentation ist die Sandbox ein isoliertes Dateisystem mit Shell für Code, den der Agent geschrieben hat.

Weiterlesen: OpenClaw mit Crabbox: Tools remote, Gateway lokal.

Hintergrundläufe statt Zuruf

Ein großer Teil der Läufe startet laut LangChain zeitgesteuert oder durch Ereignisse im Hintergrund, nicht auf Zuruf einer Person. Manche dieser Läufe richtet der Entwickler des Agenten ein. OpenSWE etwa prüft jeden neu erstellten Pull Request. Andere legen Nutzer an, indem sie den Agenten darum bitten: Auf die Bitte um ein tägliches Briefing hin legte der GTM Agent dafür selbst einen Cron-Job an.

Auf der Plattform heißen solche Zeitpläne Schedules: verwaltete Cron-Zeitpläne, die den Agenten laut Dokumentation regelmäßig ausführen.

Auslöser und Kanal begrenzen persönliche Zugriffe

• Bei OpenSWE hängt die Identität vom Auslöser ab: Eine Nachricht an den Agenten läuft im Namen der Person, ein Hintergrundlauf mit eigener Identität als GitHub-App.
• Beim GTM Agent ist etwa der E-Mail-Zugang, der im Namen der aufrufenden Person handelt, nur in Direktnachrichten verfügbar, nicht in gemeinsamen Kanälen.
• Ob ein Fakt für alle oder nur für eine Person gilt, entscheiden die Agenten selbst; beim Speicher sieht LangChain noch viel offene Arbeit.