Das Agentenmodell

Was ist ein Agent?

Ein Agent ist ein benannter Akteur mit einer Persona, einem Satz Skills und einem Adapter, auf dem er läuft. Agenten sind Prinzipale im selben Sinn wie Menschen. Agenten verfassen Nachrichten, besitzen Tickets, hinterlassen Reviews und stehen auf derselben Liste. Die Arbeit erledigen sie.

Jeder Agent gehört zu genau einem Arbeitsbereich. Das ist eine harte Invariante: agent.workspaceId ist nicht null, der eigene Arbeitsbereich des Agenten wählt die Datenbankdatei, in der seine Zeilen landen, und das Anlegen eines Agenten ohne Arbeitsbereich wird abgelehnt.

Ein Agent ist auch ein Verzeichnis. Seine Definition liegt unter agents/<slug>/AGENTS.md im Datenverzeichnis des Arbeitsbereichs, und die Skills, die er hält, sind per Symlink unter agents/<slug>/.agents/skills eingehängt. Die Datenbankzeile und die Datei werden gemeinsam geschrieben. Das Seeding ist idempotent: Existiert die Agentenzeile schon, werden die Dateien auf der Platte und die Skill-Links trotzdem neu geschrieben. In der Produktion ist der Aufrufer das Anlegen des Arbeitsbereichs, nicht jeder Serverstart.

Was ein Agent mitbringt

Attribut	Wirkung
`name`	Kurzer, slug-artiger Bezeichner (`architect`, `qa`). Darauf lösen auch `@mentions` auf
`title`	Lesbare Berufsbezeichnung
`persona`	Freitext zu Persönlichkeit und Verhalten, als Abschnitt in den Prompt eingefügt
`systemPrompt`	Optionale Zusatzanweisungen, eingefügt als Abschnitt „Agent instructions“. Den Rest des zusammengesetzten Prompts ersetzen sie nicht
`skills`	Menge von Skill-Namen ohne Unterscheidung der Groß- und Kleinschreibung, auf der Platte als Skill-Links gespiegelt
`adapterId`	An welchen Runner der Agent seine Läufe gibt. Null fällt auf die eingebaute Schleife zurück
`modelId`	Welches Modell innerhalb dieses Adapters
`effort`	Denkstufe, aus dem eigenen Vokabular des gewählten Modells
`contextSize`	Überschreibung des Kontextfensters
`silenceTimeoutMinutes`	Überschreibung je Agent (1–240) für die Stilleüberwachung
`reportsTo`	ID des übergeordneten Agenten, die Berichtslinie, die das Organigramm zeichnet

All das bearbeitest du unter Einstellungen → Arbeitsbereich → Agenten. Neuer Agent legt einen Agenten ohne Namen an, den du danach ausfüllst.

Skills

Skills sind Namen auf der Agenten-Entität, ohne Unterscheidung der Groß- und Kleinschreibung. Damit geschehen zwei getrennte Dinge:

Die Namen stehen im zusammengesetzten Prompt unter der Überschrift „Skills“. Mehr tut die Menge der Entität von sich aus nicht: Es gibt keine Prompt-Bibliothek je Skill, die daran hängt.
Das Verzeichnis jedes benannten Skills (skills/<slug>/SKILL.md im Arbeitsbereich) wird in den eigenen Ordner des Agenten verlinkt. Auf dem eingebauten Harness lädt das Frontmatter der verlinkten Skills automatisch in den System-Prompt, und der Agent liest einen Body bei Bedarf. Tippt du in einem Gespräch /skill:<name>, lädt das diesen Body als Direktive für den Zug.

Skills von außen durchlaufen zwischen Abruf und Schreiben einen Supply-Chain-Scan, der im Zweifel schließt: Kein Skill-Inhalt erreicht die Platte oder einen Prompt ohne Urteil. Außen heißt GitHub-Repositories, die du selbst als Skill-Quellen registrierst. Einen kuratierten Katalog gibt es nicht, deshalb sind die eigenen Metadaten des Repositorys (Beschreibung, Sterne, Name des Skills) unvertrauenswürdige Anzeigedaten, und das Scan-Urteil ist das einzige Sicherheitssignal. Eine Installation holt das ganze Verzeichnis des Skills, pinnt es in skills-lock.json auf den Commit, von dem es stammt, und ein späteres Update durchläuft das Tor erneut, bevor irgendetwas ersetzt wird. Die Anleitung steht unter Skills installieren und verwalten.

Repo-bezogene Skills

Ein Repo kann eigene Skills mitbringen, an jedem der üblichen Orte (.agents/skills/, .claude/skills/, .opencode/skills/). Ein Bereich checkt jedes verknüpfte Repo nebeneinander unter repos/<name>/ aus, ein Agent arbeitet aber jeweils in einem Repo. Er trägt also nur die Skills dieses Repos, und sie wechseln, wenn er wechselt.

Welches Repo aktiv ist, ergibt sich aus den Dateien, die der Agent anfasst: Eine Datei unter repos/<name>/ zu schreiben macht dieses zum aktiven Repo, bloßes Lesen über Repos hinweg tut das nicht. Ein Symbol in einen benachbarten Dienst zu verfolgen tauscht die Menge also nie unter einer laufenden Aufgabe aus. In einem Bereich mit einem einzigen Repo steht die Antwort schon vor dem ersten Zug fest.

Die Eingrenzung ist eine Entscheidung über das Kontextbudget. Der Skill-Index sitzt bei jedem Zug im Prompt, die Bodies nicht. Alle Skills jedes Repos auf einmal zu listen kostet also durchgehend Token, und ein testing-Skill aus einem Dienst führt aktiv in die Irre, wenn die Arbeit in einem anderen liegt. Dieselbe Überlegung erklärt, warum der Index eines Agenten ein Repo trägt, das Eingabefeld aber nicht so eingegrenzt ist: Einen Skill selbst zu benennen ist ein ausdrücklicher Akt, deshalb erreicht /skill:<repo>:<name> jedes Repo im Bereich.

Repo-Skills werden für jeden Adapter geladen, nicht nur für den eingebauten Harness. Die Skills des aktiven Repos werden ins Arbeitsverzeichnis des Agenten materialisiert, also auf den Pfad, den Claude Code schon absucht; derselbe Index wird in die AGENTS.md geschrieben, die der eingebaute Harness liest. Die Skills eines Repos durchlaufen denselben Scan, der im Zweifel schließt, wie ein installierter Skill, bevor irgendetwas davon geschieht. Ein ausgechecktes Repo ist geklonter Inhalt, und sein Frontmatter erreicht einen Prompt.

Berechtigungen

Ein Agent trägt keine eigenen Berechtigungs-Flags. Ob er committen, pushen, einen Pull Request öffnen, in einen Tracker schreiben oder das Netzwerk erreichen darf, entscheiden die Aktions-Schutzregeln — zulassen, zuerst fragen oder verweigern, im Geltungsbereich Arbeitsbereich, Agent oder Bereich —, und dieselben Regeln gelten, egal welcher Adapter ihn ausführt.

Was einem Lauf gereicht wird, ändert sich mit diesen Regeln nicht. Ein Lauf in einem GitHub-Worktree bekommt immer ein GitHub-Token, das nur lesen darf, und nach einem Push wird gefragt, wenn er passiert: Die Git-Konfiguration des Agenten schickt jeden GitHub-Push durch Control Center, das die Regel Zu einem Remote pushen anwendet, bevor es ihn weiterleitet.

Wie das funktioniert, einschließlich dessen, was auf Dateisystemebene durchgesetzt wird und was nicht, steht unter Sandbox und Sicherheit.

Der Adapter entscheidet, was sich durchsetzen lässt

Das folgenreichste Feld eines Agenten ist sein Adapter, denn der Transport des Adapters bestimmt, wie viel von der Richtlinie von Control Center sich tatsächlich durchsetzen lässt.

Transport	Adapter	Was Control Center durchsetzt
Eingebauter Harness	Control Center (built-in)	Alles. Die Werkzeugfläche wird aus dem Modus gebaut, ein unerlaubtes Werkzeug ist deshalb unsichtbar und nicht bloß verweigert; jeder Aufruf passiert das Freigabetor und die Schutzregeln für Aktionen; der Abschlussvertrag kann anmahnen und danach einen Lauf scheitern lassen, der ohne sein Lieferergebnis endet
Claude CLI	Claude Code	Die `mcp__*`-Werkzeuge, die ihm gereicht werden, und seine `Bash`-Befehle, die ein Hook vor der Ausführung an die Aktionsrichtlinie schickt. Claudes eigene Werkzeuge zum Lesen, Schreiben und Bearbeiten leben in seinem Prozess und laufen ungesehen, und gestartet wird er mit `--dangerously-skip-permissions`, weil ein nicht interaktives `claude -p` sonst endlos an seiner eigenen Rückfrage hängen bliebe

Konkret unterstützt nur der eingebaute Harness Subagenten, Lenken mitten im Lauf, Pause und Fortsetzen (und damit die Übernahme) sowie die strukturelle Durchsetzung des Modus. Claude Code kann nichts davon.

Die Matrix oben beschreibt, was Control Center sehen und am Tor prüfen kann. Darunter legt cc_server die Claude-Code-CLI in die OS-Sandbox des Hosts, wo es eine gibt: Seatbelt unter macOS, bubblewrap unter Linux und WSL2. Ein ungesehenes rm oder ein ungesehenes Schreiben bleibt so an das Betriebssystem gebunden. Unter Windows gibt es überhaupt kein Backend, und unter Linux oder WSL2 ohne bwrap und socat meldet die Prüfung keines. Dort fallen diese Läufe auf die Bereinigung der Umgebung, vermittelte Zugangsdaten, die Schutzregeln für Aufrufe, die Control Center sieht, und den eigenen Worktree des Gesprächs zurück (Copy-on-Write, wo rift ausgeliefert wird; git worktree unter Windows).

Die Sandbox ist eine Begrenzung, kein Tor. Festgelegt wird, wo ein Prozess lesen, schreiben und Verbindungen öffnen darf. Ein Nur-Lese-Modus erreicht sie, als schreibgeschützte Bind-Mounts. Einen Aufruf abfangen, eine Freigabe auslösen oder dir danach sagen, was die CLI versucht hat, kann sie nicht. Genau das, plus die vier Befugnisse direkt oben, hat der eingebaute Harness, die anderen nicht. Siehe Sandbox und Sicherheit.

Ein Agent ohne Adapter fällt auf Control Center (built-in) zurück, die Schleife im Server, für die keine CLI zu installieren ist. Im Laufprotokoll steht cc-harness. Jeder mit dem Arbeitsbereich angelegte Agent entsteht ohne Adapter und ohne Modell, die fünf Agenten eines frischen Arbeitsbereichs laufen also alle dort, auf dem Standardmodell von Anthropic, bis du je Agent einen Adapter und ein Modell setzt. Die Onboarding-Wahl „Standardadapter“ ist eine Einstellung auf dem Client, die der Server nie liest, und sie gilt nicht nachträglich für schon angelegte Agenten.

Woher Agenten kommen

Mit dem Arbeitsbereich angelegt. Jeder Arbeitsbereich, nicht nur der erste, bekommt einen CEO und vier Spezialisten (qa, architect, engineer, librarian), die an ihn berichten, idempotent im Hintergrund angelegt, wenn der Arbeitsbereich entsteht. Siehe Arbeitsbereiche und Isolation.
Von Hand ergänzt unter Einstellungen → Arbeitsbereich → Agenten. Einen Agenten zu bitten, eine Kollegin oder einen Kollegen einzustellen, legt keine Zeile an. Dafür ist dieser Bildschirm da.

Live-Zustand

Ein Agent hat keine gespeicherte Statusspalte. Sein Live-Zustand wird bei jedem Lesen aus den jüngsten Laufprotokollen abgeleitet:

Zustand	Bedeutung
`neverRun`	Es gibt kein Laufprotokoll
`running`	Mindestens ein Lauf ist gerade aktiv
`failed`	Der jüngste Lauf ist mit einem Fehler geendet, oder seine Liveness ist fehlgeschlagen oder tot
`blocked`	Die Liveness des jüngsten Laufs ist blockiert, ins Stocken geraten oder in einer Schleife
`idle`	Alles andere: Der Agent ist schon gelaufen und hat nichts unterwegs

Zwei weitere Zustände, queued und succeeded, gibt es für einzelne Läufe im Laufbaum des Gesprächs. Die Liste erzeugt sie nie, denn ein grün abgeschlossener Lauf ist eine Tatsache über den Lauf, nicht über den Agenten.

Die Präsenzliste zeigt parallel ein gröberes Bild, serverseitig aus den Live-Ereignissen der Läufe zusammengesetzt: denkt nach, läuft, bei einer Freigabe blockiert, fertig. Dadurch stehen Agenten neben Menschen. Siehe Multiplayer.