Externe Agenten

Tale liefert einen integrierten externen Agenten — Claude Code —, dessen gesamte Runde in einer isolierten Sandbox läuft. Statt der normalen Chat-Schleife wird deine Nachricht an diesen Coding-Agenten übergeben, der in einem frischen Container lebt, Dateien bearbeitet, Befehle ausführt und zurückmeldet. Du sprichst im Chat direkt mit ihm, und er behält dasselbe Arbeitsverzeichnis und denselben Gesprächsverlauf über mehrere Runden, sodass eine Folgeanweisung wie „füge jetzt einen Test dafür hinzu" dort weitermacht, wo er aufgehört hat.

Es ist dieselbe Idee, als würde man ein solches Werkzeug auf einer entfernten Maschine ausführen — nur ist die Maschine eine verwaltete Sandbox, die der Workspace kontrolliert. Diese Seite behandelt, wie du ihn nutzt, was die Sandbox erreichen kann und was nicht, und wie abgerechnet wird.

Mit einem Coding-Agenten sprechen

Wähle im Chat-Auswahlmenü Claude Code und beschreibe eine Aufgabe in normaler Sprache — „schreibe ein kleines Python-CLI und teste es", „klone dieses Repo und behebe den Fehler in Issue #42". Der Agent arbeitet in seiner Sandbox: Er plant, schreibt Dateien, führt Shell-Befehle aus und installiert bei Bedarf Pakete, dann antwortet er mit dem, was er getan hat. Während er arbeitet, siehst du eine Denkanzeige; die Antwort erscheint, wenn die Runde abgeschlossen ist.

Du musst nicht warten, bis eine Runde fertig ist. Das Eingabefeld bleibt offen, während der Agent arbeitet: Alles, was du sendest, wird eingereiht, erscheint sofort mit dem Hinweis Eingereiht im Thread und wird dem laufenden Agenten bei nächster Gelegenheit übergeben — bei Claude Code mitten in der Runde, an der nächsten Werkzeuggrenze, sodass eine Korrektur wie „nimm pnpm statt npm" ankommt, während die Arbeit noch läuft. Eine eingereihte Nachricht lässt sich entfernen (das × neben dem Hinweis), bis der Agent sie übernimmt. Mit Stopp beendest du die aktuelle Runde; noch eingereihte Nachrichten werden wenige Sekunden später automatisch als nächste Runde gesendet, mit unverändertem Kontext des Agenten.

Jeder Chat-Thread wird von einer dauerhaften Sandbox-Sitzung getragen. Folgenachrichten verwenden dieselbe Sitzung und dieselben Dateien wieder, und der Agent setzt seine frühere Überlegung fort, statt bei null zu beginnen. Die Sitzung gehört dem Thread — wird der Thread gelöscht oder archiviert, wird die Sandbox abgebaut und ihre Ressourcen werden freigegeben.

Was die Sandbox erreichen kann

Die Sandbox startet mit einem leeren Arbeitsverzeichnis und ist standardmäßig abgeriegelt. Ausgehender Netzwerkverkehr ist bis auf eine kleine Erlaubnisliste (Paket-Registries und GitHub) gesperrt, sodass der Agent Abhängigkeiten installieren und öffentliche Repositorys klonen, aber keine beliebigen Hosts erreichen kann. Standardmäßig wird das Modell über das Gateway des Workspace angesprochen, nie über einen rohen Provider-Schlüssel — die Sandbox hält für eine Runde nur einen kurzlebigen, budgetbegrenzten Schlüssel. Das ist der verwaltete Anmeldedaten-Modus des Agenten; die Eigene-Anmeldedaten-Alternative, die weiter unten behandelt wird, legt bewusst stattdessen deinen eigenen Provider-Schlüssel in die Box.

Über diese Abriegelung hinaus kann der Agent jede Integration nutzen, die deine Organisation verbunden hat — das Web über Tavily durchsuchen, eine API aufrufen, eine Datenbank abfragen —, solange diese Integration an den Agenten gebunden ist. Du bindest sie genauso wie bei jedem anderen Agenten: Öffne den Tools-Tab des Agenten und wähle sie unter Gebundene Integrationen aus. Die Anmeldedaten gelangen dabei nie in die Sandbox; ruft der Agent eine Integration auf, geht die Anfrage an Tale zurück, das den Aufruf mit den gespeicherten Anmeldedaten ausführt und nur das Ergebnis zurückgibt — ein kompromittierter Container kann deine Schlüssel also nicht auslesen. Ein Schreibvorgang läuft nicht stillschweigend ab: Er erscheint als Genehmigungskarte im Chat und wird ausgeführt, sobald du ihn genehmigst.

GitHub ist die Ausnahme, bei der auch ein Token in die Sandbox gelangt, weil git und das gh-CLI es lokal brauchen: Verbinde GitHub unter Integrationen und binde es an den Agenten, dann erhält die Sitzung ein begrenztes Token, mit dem der Agent in deinem Namen klonen, pushen und Pull Requests öffnen kann. Alle Anmeldedaten — das GitHub-Token in der Sandbox ebenso wie die vermittelten — sind auf die Sitzung beschränkt, werden bei jedem Aufruf auditiert und beim Ende der Sitzung widerrufen.

Verwaltete und eigene Anmeldedaten

Wie der Agent sein Modell erreicht, ist eine Entscheidung pro Agent, die du im Anweisungen-Tab des Agenten unter Anmeldedaten triffst. Die beiden Modi tauschen Plattformkontrolle gegen direkten Zugriff.

Verwaltet (Plattform-Gateway) ist die Voreinstellung und das, was alle obigen Abschnitte beschreiben. Die Plattform prägt für die Runde einen kurzlebigen virtuellen Schlüssel, leitet den Agenten über ihr Gateway, erzwingt die erlaubten Modelle des Agenten, erfasst die Nutzung und wendet die Ausgabengrenzen der Organisation an. Die Sandbox hält nie einen echten Provider-Schlüssel.

Eigene Anmeldedaten (BYO) nimmt die Plattform aus dem Anfragepfad heraus. Es wird kein virtueller Schlüssel geprägt; der Agent authentifiziert sich mit Anmeldedaten, die du unter Umgebung & Geheimnisse hinterlegst, und erreicht den Provider direkt. Das Modell wird zu einer rohen Provider-ID, die du wortwörtlich eintippst, statt zu einem Katalogeintrag, und die native Websuche und das native Abrufen des Agenten bleiben aktiviert, statt deaktiviert zu werden. Weil das Gateway umgangen wird, gelten die Modell-Erlaubnisliste, die Ausgabengrenzen und die Nutzungserfassung der Organisation nicht für BYO-Runden — Abrechnung und Limits wandern in dein eigenes Provider-Konto. Wechselst du einen Agenten von verwaltet auf BYO, werden seine gespeicherten Plattform-Modelle gelöscht, da Katalogverweise für eine rohe Durchleitung bedeutungslos sind; du gibst die rohen IDs neu ein.

Das verschiebt auch die Vertrauensgrenze. Im verwalteten Modus hält die Sandbox nur einen budgetbegrenzten Gateway-Schlüssel; im BYO-Modus wird deine echte Provider-Anmeldedaten in die Sandbox-Umgebung eingespeist — dieselbe Lage wie beim GitHub-Token in der Sandbox —, sodass jeder Code, den der Agent in der Box ausführt, sie lesen kann. Das ist Absicht: Es ist deine Box und deine Anmeldedaten. Einen Agenten zu konfigurieren ist ohnehin eine privilegierte Aktion, daher ist der Schalter pro Agent die einzige Stellschraube; es gibt keinen separaten Schalter auf Organisationsebene.

Engines und Modelle

Claude Code ist ein eigener Eintrag im Chat-Auswahlmenü. Im verwalteten Modus ist das Modell davon unabhängig: Es stammt aus der Liste der unterstützten Modelle des Agenten, genau wie bei jedem anderen Agenten — wähle es im Modellauswahlmenü. Beachte, dass die Prompts eines Coding-Agenten am besten mit der Modellfamilie funktionieren, für die er entworfen wurde; die Kombination mit einem nicht verwandten Modell funktioniert zwar, die Qualität schwankt aber.

Ein Agent mit eigenen Anmeldedaten wählt sein Modell anders. Statt des Provider-Katalogs gibst du rohe Provider-Modell-IDs ein — etwa claude-opus-4-20250514 — in Prioritätsreihenfolge, die erste als primäres Modell und der Rest als Rückfallebenen. Die Liste ist optional; lässt du sie leer, entscheidet das Standardmodell deiner Anmeldedaten. Das Chat-Modellauswahlmenü spiegelt das wider: Für einen BYO-Agenten zeigt es eine schreibgeschützte Anzeige — den Kurznamen des Modells oder Standardmodell, wenn die Liste leer ist — statt des Katalog-Dropdowns, weil das Modell durch die Konfiguration des Agenten und deine Anmeldedaten festgelegt ist und nicht pro Nachricht gewählt wird.

Kosten und Budget

Runden des Externen Agenten können lang sein und das Modell viele Male aufrufen, daher kosten sie mehr als eine einzelne Chat-Antwort. Jede verwaltete Runde läuft gegen ein Pro-Runde-Budget, und die Richtlinien und Limits der Organisation begrenzen die Ausgaben pro Nutzer, pro Team oder pro Agent. Die Nutzung wird wie bei jedem anderen Agenten in der Nutzungsanalyse erfasst und dem Externen Agenten zugeordnet, sodass du siehst, was diese Läufe kosten.

Diese Abrechnung ist eine Eigenschaft des Gateways und gilt daher nur für verwaltete Runden. Ein Agent mit eigenen Anmeldedaten läuft mit deinen eigenen Provider-Anmeldedaten außerhalb des Gateways: Seine Runden werden nicht in der Nutzungsanalyse erfasst und die Ausgabengrenzen der Organisation gelten nicht — die Kosten und etwaige Ratenlimits liegen stattdessen bei deinem Provider-Konto.

Wo das hineinpasst

Ein externer Agent verwandelt einen Chat-Thread in eine Live-Sitzung mit einem Coding-Werkzeug in einer Sandbox — du steuerst ihn in normaler Sprache, er arbeitet in einem isolierten Arbeitsbereich, und die Sitzung bleibt für Folgefragen bestehen, bis du den Thread schließt. Die Anmeldedaten sind die Achse, die entscheidet, wie viel davon unter der Kontrolle der Organisation läuft: Ein verwalteter Agent bleibt am Plattform-Gateway unter den Grenzen und der Erfassung der Organisation, während ein Agent mit eigenen Anmeldedaten mit den Schlüsseln läuft, die du unter Umgebung & Geheimnisse hinterlegst, und deinem eigenen Provider-Konto gegenüber rechenschaftspflichtig ist. Die Drift-Kandidaten hier sind die Agenten- und Modellnamen; kombiniere diese Seite mit der laufenden Provider-Liste, statt dir bestimmte Modellzeichenketten zu merken, und mit Integrationen für die verbundenen Integrationen, die der Agent erreichen kann — von GitHub für einen echten Pull-Request-Workflow bis zu einer Such- oder Datenintegration, die externe Fakten in die Arbeit holt.