Vom Terminal zur Fabrik — Headless AI Agents im 24/7-Betrieb

Das ist der bedeutendste architektonische Wandel im AI-gestützten Coding für 2026. Wir bewegen uns weg von einem lokalen Tool — bei dem man ein Terminal beobachtet, einen Agent beaufsichtigt und den Laptop zuklappt, wenn man fertig ist — hin zu einem Headless Backend, in dem Agents auf einem Server leben und man ihnen von überall aus Aufgaben zuweist.

Der Unterschied ist fundamental: Der AI-Coding-Assistent ist kein Tool mehr, das man benutzt. Er ist ein Service, den man betreibt.

Ich fahre dieses Setup seit einigen Monaten, und es hat mein Verständnis von Entwicklungskapazität grundlegend verändert. Hier ist die vollständige Anleitung zum Aufbau einer eigenen Headless-Agent-Infrastruktur mit den Remote Control und Dispatch Features von Claude Code.

Die Architektur: Lokales Tool vs. Headless Backend

Bevor wir ins Detail gehen, muss man verstehen, was sich ändert:

Dimension	Lokales Tool (2025)	Headless Backend (2026)
Ausführung	Läuft auf dem eigenen Laptop	Läuft auf einer persistenten Cloud-VM oder einem Server
Interface	Man tippt in ein Terminal	Man sendet Befehle via Dispatch (Handy/Web)
Persistenz	Stoppt beim Zuklappen des Laptops	Läuft 24/7 via Remote Control und `/loop`
Überwachung	Man beobachtet jede Codeänderung	Man reviewt Diffs, Artefakte und Logs asynchron
Skalierung	Ein Agent, eine Aufgabe	Mehrere Agents, parallele Aufgaben, koordiniert über Channels

Das ist nicht nur ein Komfort-Upgrade. Es ist ein Kapazitäts-Multiplikator. Statt 8-10 Stunden am Tag mit AI-Unterstützung zu coden, hat man Agents, die rund um die Uhr arbeiten — Issues triagieren, Tests fixen, PRs reviewen und Features bauen, während man schläft, fliegt oder sein Leben lebt.

Schritt 1: Den Headless Server vorbereiten

Statt des eigenen Laptops braucht man eine persistente Umgebung — einen VPS, einen dedizierten lokalen Server oder einen Docker-Container — der 24/7 läuft. Ich nutze einen Mac Studio in meinem Homeoffice, aber jeder Linux-VPS (Hetzner, DigitalOcean, AWS EC2) funktioniert genauso.

Claude Code auf dem Server installieren:

npm install -g @anthropic-ai/claude-code

Für den Headless-Modus konfigurieren — in ~/.claude/settings.json:

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1",
    "CLAUDE_CODE_HEADLESS": "true"
  }
}

Das HEADLESS-Flag signalisiert Claude Code, ohne interaktive Terminal-Eingaben zu arbeiten. Das AGENT_TEAMS-Flag aktiviert die Multi-Agent-Koordination über Channels.

Wichtig: Headless Sessions immer innerhalb von tmux oder screen starten. Das gibt einem ein physisches “Attach”-Fallback — wenn eine Aufgabe hängenbleibt, kann man sich per SSH auf den Server verbinden, die tmux-Session attachen und direkt eingreifen. Das ist das Human-in-the-Loop Sicherheitsnetz.

tmux new-session -s agent-factory

Schritt 2: Remote Control einrichten (Die Mobile Bridge)

Remote Control ist die Brücke zwischen dem Handy (oder einem beliebigen Gerät) und dem serverseitigen Agent. Das macht das Setup wirklich “headless” — man muss nicht an einem Terminal sitzen, um mit den Agents zu interagieren.

Die Bridge auf dem Server initialisieren:

claude remote-control

Im Terminal erscheint ein QR-Code. Mit der Claude Mobile App auf dem Handy scannen.

Das Ergebnis: Das Handy ist jetzt eine Fernbedienung für den serverseitigen Agent. Man kann den Laptop zuklappen, den Schreibtisch verlassen, eine Runde laufen gehen — der Agent-Prozess lebt weiterhin auf dem Server und wartet auf Befehle über das Mobile Interface.

Man kann:

Sehen, woran der Agent gerade arbeitet
Neue Anweisungen oder Korrekturen senden
Vorgeschlagene Änderungen genehmigen oder ablehnen
Einen außer Kontrolle geratenen Task abbrechen

Das ist der Moment “Ich reviewe Code aus dem Cockpit während des Reiseflugs”, der das ganze Setup lohnenswert macht.

Schritt 3: Dispatch — Strukturiertes Task-Management

Statt in einen Chat zu tippen und auf das Beste zu hoffen, erlaubt Dispatch das Senden strukturierter Aufgaben, die der Agent aufgreift, ausführt und über deren Ergebnis er berichtet.

Einen Dispatch-Job senden:

claude dispatch "Refactor the auth service to use the new Redis cache"

Anders als Standard-Chat erzeugt Dispatch eine nachverfolgbare Job-ID. Man kann den Status vom Handy oder einem anderen Terminal prüfen, ohne die aktuelle Arbeit des Agents zu unterbrechen. Jeder Dispatch-Job hat:

Eine eindeutige ID zur Nachverfolgung
Status (queued, running, completed, failed)
Vollständiges Ausführungslog
Diff aller durchgeführten Änderungen
Möglichkeit, das Ergebnis zu genehmigen oder abzulehnen

Batch Dispatching entfaltet die eigentliche Stärke. Mehrere Aufgaben vor dem Schlafengehen einreihen:

claude dispatch "Add rate limiting to the /api/documents endpoint"
claude dispatch "Write integration tests for the validation engine"
claude dispatch "Update the Swagger docs for v2 API changes"

Jede Aufgabe wird sequenziell (oder parallel mit Agent Teams) ausgeführt, und man reviewt die Ergebnisse am nächsten Morgen.

Schritt 4: Agent Teams für parallele Ausführung

Bei größeren Projekten nicht einen einzelnen Agent nutzen, sondern ein Team. Mit aktivierten Agent Teams kann man mehrere spezialisierte Agents starten, die über Channels koordinieren.

Rollen durch eingeschränkten Dateizugriff definieren:

Backend Agent — Zugriff beschränkt auf /src/backend, /src/api
Frontend Agent — Zugriff beschränkt auf /src/frontend, /src/components
DevOps Agent — Zugriff auf /infrastructure, /.github/workflows
Test Agent — Zugriff auf /tests, Lesezugriff auf Quelldateien

Channels für Inter-Agent-Kommunikation nutzen:

Wenn der Backend Agent einen neuen API-Endpoint fertigstellt, kann er den Frontend Agent über einen Channel benachrichtigen, die entsprechende UI-Komponente zu aktualisieren. Der DevOps Agent beobachtet Infrastrukturänderungen und passt Deployment-Konfigurationen entsprechend an.

Das bildet die Arbeitsweise eines echten Engineering-Teams nach — spezialisierte Rollen, klare Grenzen, asynchrone Kommunikation. Nur dass diese Teammitglieder 24/7 arbeiten und nie ein Standup brauchen.

Schritt 5: Eventgesteuerte Automatisierung (Die Fabrik)

Der letzte Schritt verwandelt manuelles Dispatching in eine autonome Fabrik mit eventgesteuerten Triggern.

Cron-basierte Health Checks mit dem nativen /loop-Protokoll:

# Innerhalb einer detached Claude Code Session
/loop 2h "Check for any failing tests in the CI pipeline and attempt to fix them"

Das läuft alle 2 Stunden, erkennt und behebt automatisch Testfehler. Der persönliche Nacht-QA-Engineer.

Webhook-Trigger aus der CI/CD-Pipeline:

Integration mit GitHub Actions, sodass bei einem geöffneten PR die serverseitige Claude-Instanz automatisch:

Den neuesten Code pullt
Den PR auf Probleme reviewt
Die Testsuite ausführt
Review-Kommentare postet
Optional Korrekturen auto-fixt und pusht

# .github/workflows/agent-review.yml
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  agent-review:
    runs-on: self-hosted  # Your agent server
    steps:
      - uses: actions/checkout@v4
      - run: claude dispatch "Review this PR: ${{ github.event.pull_request.title }}"

Geplante Wartungsaufgaben:

/loop 24h "Run dependency audit, check for CVEs, and create a PR if updates are needed"
/loop 12h "Review open issues labeled 'bug' and attempt to reproduce and fix"

Mein aktuelles Setup

So sieht meine Agent-Fabrik in der Praxis aus:

Hardware: Mac Studio M2 Ultra (immer an, im Homeoffice)
Sessions: 3 tmux-Fenster — Backend Agent, Frontend Agent, Maintenance Agent
Remote Control: Gekoppelt mit meinem iPhone über die Claude Mobile App
Dispatch Queue: Ich reihe jeden Abend 5-10 Aufgaben vor dem Schlafengehen ein
Loop Tasks: Test-Monitoring (2h), Dependency Audit (24h), Stale-PR-Cleanup (12h)
Morgenroutine: Overnight-Diffs beim Kaffee reviewen, genehmigen/ablehnen, neuen Batch dispatchen

Das Ergebnis ist ungefähr der 3-fache Entwicklungs-Durchsatz im Vergleich zu rein lokalen Claude Code Sessions. Nicht weil die Agents schneller sind — sondern weil sie nie aufhören zu arbeiten.

Praktische Überlegungen

Kosten: Agents im 24/7-Betrieb verbrauchen erhebliche API-Credits. Ich nutze das Claude Max Abo, das dies wirtschaftlich tragbar macht. Nutzung überwachen und Budget-Alerts setzen.

Sicherheit: Der Server hat Zugriff auf die Codebase und API-Keys. Wie einen Produktionsserver behandeln — nur SSH-Keys, Firewall konfiguriert, Secrets in Umgebungsvariablen, regelmäßige Sicherheitsupdates.

Qualitätskontrolle: Agent-Output nie automatisch mergen. Diffs immer vor dem Merge reviewen. Die Nacht-Fabrik produziert Code; die Entscheidung, was live geht, trifft weiterhin der Mensch. Die Agents sind unermüdliche Junior-Entwickler, keine autonomen Entscheider.

Klein anfangen: Nicht versuchen, die komplette Fabrik an Tag eins aufzusetzen. Mit Remote Control und einzelnen Dispatch-Jobs starten. Agent Teams hinzufügen, wenn man sich sicher fühlt. Loop-Automatisierung zuletzt, wenn man der Qualität unbeaufsichtigter Ergebnisse vertraut.

Was kommt als Nächstes

Das Headless-Agent-Paradigma ist noch jung. Für 2026-2027 erwarte ich:

Natives Cloud-Hosting für Claude Code Agents (kein selbst gehosteter Server mehr nötig)
Visuelle Dashboards zur Überwachung von Agent-Fleet-Status, Kosten und Output-Qualität
Agent-to-Agent-Protokolle jenseits von Channels — geteilter Kontext, Code Ownership, Merge-Koordination
Selbstlernende Agents, die aus den eigenen Review-Mustern lernen und ihren Ansatz anpassen

Der Wandel von “AI als Tool” zu “AI als Service” passiert gerade jetzt. Die Entwickler, die lernen, Agent-Flotten zu betreiben — und nicht nur AI-Assistenten zu benutzen — werden einen strukturellen Vorteil haben, der sich über die Zeit potenziert.