Was ein Outgate-Agent ist

Ein echter Coding-Agent in einer eigenen Cloud-Sandbox, erreichbar über Chat oder API.

Ein Outgate-Agent ist kein dünner Chat-Wrapper um ein Modell. Jeder Agent ist eine vollwertige agentische CLI — Claude Code oder Codex —, die in einem isolierten Sandbox-Container in einer Outgate-Region läuft. Er hat eine Shell, ein persistentes Dateisystem, Git und denselben Tool-Zugriff wie auf einem Entwicklerrechner.

Sie sprechen mit ihm wie mit einem Kollegen: Nachricht senden, bei der Arbeit zusehen, Ergebnis prüfen. Der Chat auf chat.outgate.ai ist die eingebaute Oberfläche, und alles, was der Chat kann, ist auch programmatisch über die Agents API verfügbar — der Chat selbst ist auf denselben öffentlichen Endpoints gebaut.

you (chat or API)
      |
      v
  Outgate control plane ──── thread registry, auth, events
      |
      v
  region ─── sandbox container
              ├─ Claude Code or Codex
              ├─ /workspace (persistent volume)
              └─ model traffic via the gateway
                  └─ guardrails apply on the way out

Modell-Traffic aus der Sandbox fließt durch dasselbe Gateway wie jeder andere Outgate-Traffic — Routing, Guardrails und Observability greifen bei Agenten-Arbeit also genauso wie bei direkten API-Aufrufen.

Threads

Ein Thread ist ein Agent: eine Konversation, eine Sandbox und eine dauerhafte Event-Historie.

Die Arbeitseinheit ist der Thread. Ein Thread bündelt drei Dinge: die Konversation mit dem Agenten, den Sandbox-Container, in dem der Agent läuft, und eine dauerhafte, geordnete Event-Historie von allem, was passiert ist — Nachrichten, Tool-Aufrufe, Lifecycle-Änderungen.

Threads sind langlebig. Die Sandbox kann schlafen gehen und wieder aufwachen, aber der Thread behält die ganze Zeit seine Identität, seine Historie und seinen Workspace. Sie können den Laptop mitten in einer Aufgabe zuklappen und die Konversation Tage später fortsetzen.

• Jeder Thread hat eine stabile ID und gehört zu Ihrer Organisation.
• Die vollständige Event-Historie ist abfragbar — nichts an dem Lauf ist eine Black Box.
• Threads aus dem Chat und Threads aus der API sind dasselbe Objekt und lassen sich auf dieselbe Weise inspizieren.

Sandbox-Lifecycle

Sandboxes starten, laufen, schlafen bei Inaktivität und wachen bei Bedarf auf; Threads sind standardmäßig langlebig.

create                    message / resume
   |                              |
   v                              v
starting ────────> live <──────────────── idle
   |                 |    idle timeout       |
   |                 └──────────────────────>┘
   v
spawn_failed                 thread TTL reached
                                   |
                                   v
                                 ended

Agent-Typen, Modelle und Effort

Wählen Sie Claude Code oder Codex, jedes Modell, auf das Ihr Account Zugriff hat, und den Reasoning-Effort.

Jeder Thread führt einen Agent-Typ aus: claude (Claude Code) oder codex (Codex CLI). Der Agent-Typ ist pro Thread fest; Modell und Effort-Level sind es nicht.

Der Modell-Picker zeigt den Live-Katalog Ihres tatsächlichen Accounts — die Modelle, die Ihr Provider-Abo wirklich anbietet, keine fest verdrahtete Liste. Sie können das Modell mitten im Thread wechseln; die Sandbox startet mit dem neuen Modell neu, und die Konversation läuft weiter.

Effort wird auf die nativen Reasoning-Steuerungen des jeweiligen Agenten abgebildet — Claude-Code-Effort-Level für claude-Threads, Model-Reasoning-Effort für codex-Threads. Setzen Sie ihn pro Thread im Chat über das Composer-Menü oder pro Request über die API.

Anmeldung bei Modell-Providern

Agenten authentifizieren sich bei Anthropic oder OpenAI mit Ihrem eigenen Abo — oder laufen gegen Gateway-Provider.

Es gibt zwei Wege, wie ein Agent Modellzugriff bekommt. Der einfachste ist die Anmeldung mit Ihrem eigenen Provider-Abo: Der Chat zeigt die Buttons Connect Claude und Connect ChatGPT, die durch den Anmelde-Flow des Providers führen. Sie öffnen eine URL, bestätigen auf Provider-Seite, und die Sandbox schließt den Login ab — derselbe Flow, den die CLIs auf einem Laptop nutzen, angepasst für einen Headless-Container.

Alternativ kann ein Thread gegen einen in Ihrem Outgate-Gateway konfigurierten Provider laufen — auch Nicht-Anthropic- und Nicht-OpenAI-Upstreams hinter kompatiblen APIs. In diesem Modus erhält die Sandbox automatisch gescopte Zugangsdaten, eine interaktive Anmeldung ist nicht nötig.

• Der Anmeldezustand überlebt Idle und Aufwachen — Sie authentifizieren sich nicht in jeder Session neu.
• Der Auth-Status ist im Chat sichtbar und über die API abfragbar — Sie wissen also immer, ob ein Thread angemeldet ist, bevor Sie Arbeit schicken.
• Abmelden ist jederzeit möglich; der Thread bleibt, nur die Provider-Session wird gelöscht.

Permission-Modi

Entscheiden Sie, ob der Agent vor Tool-Läufen fragt oder autonom arbeitet.

Jeder Thread hat einen Permission-Modus. Im ask-Modus hält der Agent vor folgenreichen Tool-Läufen an und stellt eine Permission-Anfrage — der Chat zeigt eine Freigabe-Karte, und API-Konsumenten erhalten ein permission_request-Event, das sie programmatisch beantworten können. Im skip-Modus arbeitet der Agent autonom weiter, ohne zu fragen.

ask ist der sicherere Standard für exploratives Arbeiten; skip passt zu Automatisierung, bei der kein Mensch zusieht. Der Modus lässt sich an einem laufenden Thread ändern.

Workspace und Volumes

/workspace ist ein persistentes Volume, das Schlafen, Aufwachen und Modellwechsel übersteht.

Jede Sandbox mountet ein Workspace-Volume unter /workspace — das Arbeitsverzeichnis, in dem der Agent Repositories klont, Dateien schreibt und Ausgaben baut. Das Volume ist echter persistenter Speicher: Es überlebt Idle-Schlaf, Aufwachen, Modell- und Effort-Wechsel sowie Sandbox-Neustarts.

Im Chat sind Threads in Projekte organisiert, und Threads im selben Projekt teilen sich ein Workspace-Volume. Das ist Absicht: Ein Folge-Thread im selben Projekt sieht die Dateien, die der vorherige Thread hinterlassen hat — mehrere Sessions an einer Codebasis starten also nicht bei null.

Für einmalige Jobs können Sie stattdessen einen ephemeren Thread anlegen: Es wird kein Volume angehängt, der Agent bekommt Scratch-Speicher, der beim Stoppen der Sandbox verschwindet. Ephemere Threads sind die richtige Wahl für zustandslose Automatisierung, bei der Persistenz nur Ballast ansammeln würde.

• Laden Sie Dateien per Chat in einen Thread hoch (Drag-and-drop, bis zu 500 Dateien pro Nachricht) oder über die Files-API.
• Durchsuchen Sie Workspace-Inhalte über den Files-Tab im Chat oder listen Sie sie über die API auf.
• Die Workspace-Größe ist pro Volume messbar, sodass Sie das Wachstum im Blick behalten können.

Git und GitHub

Agenten arbeiten mit echten Repositories; die GitHub App gewährt kurzlebigen, gescopten Zugriff.

Sandboxes bringen Git mit, und Agenten nutzen es nativ — klonen, branchen, committen, pushen. Der Chat hat einen Git-Tab, der den Repository-Status zeigt, und die API stellt Git-Operationen direkt bereit.

Für private GitHub-Repositories installieren Sie die Outgate GitHub App in Ihrer Organisation oder auf ausgewählten Repositories. Berührt ein Thread ein Repo, das die App abdeckt, erzeugt Outgate ein kurzlebiges Installations-Token (rund eine Stunde gültig) und reicht es über einen Credential-Helper an Git in der Sandbox weiter.

Repositories auf anderen Hosts funktionieren ebenfalls: Jedes Git-Remote, das Token-Authentifizierung akzeptiert, lässt sich nutzen, indem Sie der Git-Operation ein Token mitgeben — es wird für diese Operation verwendet und nicht gespeichert.

Thread-Benennung

Agenten benennen ihre Threads selbst — Ihre Thread-Liste bleibt lesbar.

Neue Threads starten mit einem Platzhalter-Namen. Sobald der Agent versteht, woran er arbeitet, benennt er den Thread selbst über ein eingebautes Tool — aus einer unbenannten Session wird "Flaky Auth-Tests fixen", ohne dass Sie etwas tun.

Sie können einen Thread im Chat jederzeit manuell umbenennen, und API-Konsumenten setzen den Titel mit einem thread.title-Event.

Wie es weitergeht

Steuern Sie Agenten programmatisch oder lassen Sie sie geplante Apps bauen.

• Agents API — erstellen und steuern Sie Threads aus Ihrem eigenen Code: REST-Endpoints, Streaming-Events und Webhooks.
• Apps — lassen Sie einen Agenten wiederkehrende Arbeit als geplante, veröffentlichbare App verpacken, die nach dem Ende der Konversation weiterläuft.