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.

Permission-Anfragen gelten für Tool-Aufrufe: Sie dauern Sekunden, und eine unbeantwortete Anfrage wird abgelehnt. Braucht der Agent eine Entscheidung von Ihnen, die Stunden dauern kann — eine Designfrage, die Freigabe eines Plans, eine kostspielige Aktion — stellt er stattdessen einen Decision Request. Diese werden im Abschnitt Approvals und Entscheidungen weiter unten beschrieben.

Approvals und Entscheidungen

Lassen Sie den Agenten eine Frage stellen, die Stunden oder Tage warten kann, und mit Ihrer Antwort weiterarbeiten.

Ein Decision Request ist eine Frage, die der Agent Ihnen stellt und dann parkt. Er nutzt ihn, wenn der nächste Schritt unumkehrbar oder teuer ist, wenn ein Plan Ihre Freigabe braucht oder wenn eine Wahl anliegt, die Sie noch nicht getroffen haben — welcher Kanal zuerst gebaut wird, ob die Sandbox für einen neuen Host geöffnet werden darf, wie eine Konfiguration ausgefüllt werden soll. Anders als eine Permission-Anfrage blockiert ein Decision Request den Agenten nicht: Das Tool kehrt sofort zurück, der Agent beendet seinen Turn, und die Sandbox kann in den Leerlauf gehen, bis Sie antworten.

Jeder Request hat eine Priorität: high, normal oder low. Offene Requests werden nach Dringlichkeit sortiert: zuerst hohe Priorität, dann der Request, der am ehesten abläuft. Hohe Priorität wird rot angezeigt, niedrige Priorität umrandet, und die Restzeit wechselt in den letzten 15 Minuten in eine Warnfarbe.

Jeder Request hat eine Gültigkeitsdauer (TTL). Der Standard beträgt 12 Stunden, und der Agent kann zwischen einer Minute und 7 Tagen wählen. Zusammen mit der Frage erklärt der Agent einen Default — die Aktion, die er ausführt, wenn niemand antwortet. Läuft die Zeit ab, wird der Request als abgelaufen markiert und der Agent fährt mit diesem Default fort. Die Detailansicht zeigt das als „If unanswered by HH:MM, Claude proceeds with: …“, sodass Sie immer wissen, was Schweigen bedeutet.

• Der Tab Approvals im Thread. Er erscheint, sobald der Thread eine Entscheidung hatte, und trägt ein Badge mit der Zahl der offenen Requests. Am Desktop können Sie ihn neben dem Chat anpinnen.
• Die Chat-Karte. Jeder Request erscheint in der Unterhaltung als Zeile mit Titel, Priorität und Restzeit; Open springt direkt hin. Beantwortete und abgelaufene Zeilen bleiben mit ihrem Ergebnis im Verlauf.
• Die Seite Approvals im Menü Ihres Avatars. Sie listet jeden offenen Request aus allen Ihren Threads, gruppiert nach Thread, sodass Sie alles abarbeiten können, ohne jeden Thread zu öffnen. Das Badge an Ihrem Avatar zeigt die Gesamtzahl über alle Threads.

Nach Ihrer Antwort erreicht die Rückmeldung den Agenten als neue Nachricht im Thread. War die Sandbox im Leerlauf, wacht sie zuerst auf, sodass eine Antwort nach einem Tag genauso zugestellt wird wie eine nach einer Minute. Ist der Agent mitten in einem Turn, kommt die Antwort mitten im Turn an. Jeder Request wird genau einmal beantwortet: Antworten zwei Personen auf denselben Request oder trifft eine Antwort gleichzeitig mit dem Ablauf ein, gewinnt die erste, und die andere sieht, dass der Request bereits geschlossen ist.

Sie erhalten nicht für jeden Request eine E-Mail. Outgate sendet einen Digest pro Zwei-Stunden-Fenster: Die Uhr startet mit dem ersten unbeantworteten Request, und nach Ablauf erhalten Sie eine einzelne E-Mail mit allem, was noch offen ist, gruppiert nach Thread und mit einem Link zu jedem Request. Innerhalb des Fensters beantwortete Requests entfallen, und ist beim Schließen des Fensters nichts mehr offen, wird keine E-Mail gesendet. Requests mit niedriger Priorität sind enthalten, denn der Digest ist eine Zusammenfassung, kein Alarm.

Agenten rufen drei Tools auf dem eingebauten og-thread MCP-Server auf. og_decision_request erstellt einen Request, og_decision_status liest ihn zurück, und og_decision_cancel zieht einen Request zurück, den der Agent nicht mehr braucht. Ein typischer Request sieht so aus:

og_decision_request {
  type: "single",
  title: "Which messaging channel should I build first?",
  body: ["Telegram validates the idea at minimal cost.", "Teams fits business users better."],
  options: [{ id: "tg", label: "Telegram", recommended: true }, { id: "teams", label: "Microsoft Teams" }],
  default: "Telegram first",
  priority: "high",
  ttl_minutes: 720
}

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.