Ein Agentenprofil erstellen und verwalten

Ein Agentenprofil ist das gespeicherte Wer eines Laufs: welcher Agent mit welchem Modell arbeitet, welche MCP-Tool-Stufen er erreichen darf, in welchem Ausführungsmodus er läuft, aus welchen Memories er schöpfen darf und welche Pre- und Post-Flight-Checks er bestehen muss. Ein Profil an einen Task, eine Automatisierung oder einen Workflow-Knoten zu heften sagt einmal „arbeite so“ – statt bei jedem Start erneut.

Zwei benachbarte Tabs vervollständigen das Bild. MCPs ist das, was ein Agent erreichen darf – die Tool-Server, die dieser Workspace bereitstellt. Skills ist das, was er zu tun weiß – wiederverwendbare Markdown-Anweisungssätze, die in einen Lauf eingespielt werden. Alle drei Tabs liegen unter Einstellungen → Agents.

Hier stellst du es ein – erklärt wird es woanders

Das Stufenmodell selbst – was die Stufen Baseline, Read, Ops, Scaffold und Deploy tatsächlich gewähren und welche Ratenlimits daran hängen – steht in Berechtigungen und MCP-Tool-Stufen. Diese Seite zeigt nur, wo du es einstellst und wer das darf.

Ein Profil erstellen

Öffne Einstellungen → Agents → Agent-Profile. Der Tab ist eine durchsuchbare und sortierbare Liste aller Profile des Workspace – Name, Standard-Agent, Ausführungsmodus, Version und Status, mit dem Badge Standard am Workspace-Standardprofil – über einem Detailformular, das an die ausgewählte Zeile gebunden ist.

1. Klicke in der Werkzeugleiste der Liste auf Profil erstellen. Das Formular darunter leert sich und zeigt auf kein bestehendes Profil mehr.

2. Gib dem Profil seine Identität: Name, Slug und Farbe – die Farbe, in der das Profil im ganzen Produkt dargestellt wird. Lässt du den Slug leer, wird er aus dem Namen abgeleitet; er ist der Griff, mit dem du das Profil aus Chat und Web-Terminal heftest (run <Projekt> <Agent> --profile <slug>).

3. Lege fest, wer die Arbeit ausführt:

   • Standard-Agent – Claude Code, Codex, Gemini, Qwen Code oder OpenRouter.
   • Modell-Policy – Auto (SupaCloud darf das Modell aus Auswahlsignalen wählen, wenn der Task nichts vorgibt), Manuell (der Task entscheidet; das Profil setzt nur Agent, Persona und Capabilities) oder Fixiert (dieses Profil läuft immer mit dem einen Modell, das du benennst).
   • Fixiertes Modell – nur unter der Policy Fixiert aktiv. Die Optionen kommen aus dem gepflegten Modellkatalog, eingegrenzt auf den Provider des gewählten Agenten.
   • Ausführungsmodus – Normal (Standard-Ausführung mit einem einzelnen Agenten) oder Workflow (die Multi-Agent-Workflow-Orchestrierung von Claude Code). Workflow ist eine Fähigkeit von Claude Code, deshalb ist die Auswahl bei den anderen Agenten deaktiviert.

4. Schreibe Beschreibung und Persona-Prompt – die stehende Anweisung, die jeder Lauf unter diesem Profil erhält. Der Zähler neben dem Feld deckelt die Persona bei 200 Tokens; darüber ist das Speichern blockiert.

5. Fülle Erlaubte Capabilities – eine kommagetrennte Liste von MCP-Tool-Namen oder -Stufen (etwa supacloud.read.*, supacloud.ops.*, ein einzelner Tool-Name oder supacloud.full). Eine leere Liste gewährt nichts Eigenes: Die Sitzung fällt auf den Workspace-Standard zurück und danach auf den eingebauten Nur-Lese-Boden.

6. Setze die Memory-Policy – die Scopes und Typen als Auto-Kontext, die Scopes und Typen für den MCP-Lesezugriff, ob persönliches Wissen erlaubt ist, und das Auto-Limit.

7. Ergänze Tags, falls du danach sortierst, lasse Aktiv eingeschaltet und klicke auf Profil erstellen. Der Effektive System-Prompt unter dem Formular zeigt den Persona-Prompt so, wie der Agent ihn erhält.

Ein deaktiviertes Profil lässt einen gehefteten Task scheitern

Aktiv ist nicht kosmetisch. Ein Task, der an ein deaktiviertes (oder gelöschtes oder zu einem anderen Workspace gehörendes) Profil geheftet ist, fällt nicht still auf eine schwächere Stufe zurück – seine MCP-Sitzung wird rundweg abgelehnt, mit „Pinned agent profile is unavailable or disabled“. Das ist Absicht: Ein Profil zu entziehen darf die Rechte eines Agenten nicht über einen Rückfall verbreitern.

Das Profil im erweiterten Editor feinjustieren

Wähle ein Profil aus und klicke auf Erweiterter Editor, um es auf einer eigenen Seite zu öffnen. Der Editor hat vier Ansichten.

Formular

Alles aus dem Listenformular, dazu die Felder, die es nur hier gibt:

• Avatar-Stil und Avatar-Wert – Farbe, Initial, Symbol oder Bild.
• Standard-Denktiefe – Erben (der Runner-Standard) oder eine der fünf Aufwandsstufen, angewendet auf jeden Task unter diesem Profil.
• Autonomie – der Schieberegler auf Profil-Ebene. Das Profil ist der spezifischste Scope, seine Stufe gewinnt also über Projekt und Workspace; siehe Die Autonomiestufe festlegen.
• PR-Vorlage – die Markdown-Vorlage für Pull Requests, die dieses Profil erstellt.
• Visual Verify – das Post-Flight-Gate aus Screenshot und Judge; siehe Visual-Verify-Gates konfigurieren.
• Review erforderlich – Aufgaben dieses Profils müssen geprüft werden, bevor sie als erledigt gelten.
• memory.create erlauben (MCP) – lässt den Agenten Memories direkt schreiben, ohne Prüfung. Standardmäßig aus.
• Interaktive Tool-Freigaben – pausiert den Agenten mitten im Lauf für ein menschliches Urteil zu abgesicherten Tools. Standardmäßig aus und mit dem Autonomie-Level des Laufs kombiniert, nicht darüber gestellt; die Pausen landen im Posteingang.

Raw

Ein JSON-Editor über genau drei Felder des Profils – pre_flight_checks, post_flight_checks und retry_policy. Diese Arrays und Beutel sind vorwärtskompatibel, deshalb ist Raw der Weg, eine Check-Art (oder eine Retry-Einstellung) zu schreiben, für die es im Formular noch kein eigenes Bedienelement gibt. Solange das JSON ungültig oder kein Objekt ist, bleibt das Speichern gesperrt – ein Tippfehler kann also kein funktionierendes Runbook überschreiben.

Raw ist nicht der Ort, an dem du ein Profil beförderst

is_workspace_default fehlt in der Raw-Ansicht mit Absicht. Nur ein Profil je Workspace darf es tragen, deshalb ist die Beförderung eine eigene Aktion – siehe Den Workspace-Standard festlegen weiter unten.

Versionen

Die Geschichte des Profils: Bei jeder Änderung am Runbook schreibt der Server einen unveränderlichen Snapshot. Die Liste beginnt mit dem neuesten Eintrag, und Snapshot anzeigen klappt eine Zeile zum vollständigen JSON des Profils auf, wie es zu jener Version aussah. Keine Aktion dieser Ansicht verändert das Profil.

Governor

Die Oberfläche des selbstlernenden Governors für dieses Profil: das Banner Drift-Status (erscheint, wenn ein Drift-Signal die gelernte Modellauswahl des Profils eingefroren hat), die offenen Versionsvorschläge, die der Governor daraufhin erhoben hat, und die Karte Governor-Audit mit der jüngsten Golden-Set-Bestehensquote, der Judge-Übereinstimmung und den mittleren Kosten. Ein Genehmigen materialisiert den Vorschlag als neue Version und hebt das Einfrieren auf. Vorschläge und Drift-Status liest der Workspace-Eigentümer, die Audit-Karte liest der Workspace-Admin. Zum Mechanismus siehe Der selbstlernende Governor.

Profil-Vorschläge kannst du auch ohne den Editor entscheiden

Dieselben Vorschläge erscheinen unter Posteingang → Entscheidungen mit dem Badge Profil-Vorschlag, neben allen anderen Entscheidungen, die auf dich warten – siehe Den Posteingang abarbeiten.

Den Workspace-Standard festlegen

Das ist der tragende und wenig offensichtliche Teil dieser Oberfläche.

Ein Task ohne Agentenprofil – ein Lauf, der ohne eines gestartet wurde, oder ein Workflow-Agentenschritt, dessen Knoten keines heftet – bekommt keineswegs großzügige Rechte. Seine MCP-Sitzung wird in dieser Reihenfolge aufgelöst:

1. die Capability-Liste des eigenen Profils, sofern der Task ein Profil hat und diese Liste nicht leer ist;
2. sonst die Liste des Workspace-Standardprofils, sofern eines gesetzt und die Liste nicht leer ist;
3. sonst der eingebaute Boden: supacloud.* plus supacloud.read.* – die bedingungslose Baseline plus die Lese-Tools. Ops, Scaffold und Deploy bleiben fail-closed.

Schritt 3 ist also das, was ein Task ohne Profil standardmäßig bekommt – und nur die Beförderung eines Workspace-Standardprofils ändert das.

1. Öffne Einstellungen → Agents → Agent-Profile und wähle das Profil in der Liste aus.

2. Scrolle ans Ende des Detailformulars und klicke auf Als Workspace-Standard festlegen. Die Schaltfläche erscheint nur bei einem gespeicherten Profil, nie während du ein neues anlegst.

3. Die Zeile daneben lautet danach Dies ist das Standardprofil des Workspace., und das Badge Standard wandert in der Liste zu dieser Zeile. Ein Workspace hat höchstens einen Standard, eine Beförderung löscht den bisherigen also im selben Vorgang.

Der Standard wird nicht auf Nur-Lesen heruntergefiltert

Die Liste des Workspace-Standards wird wortwörtlich verwendet. Beförderst du ein Profil, dessen Liste supacloud.ops.*, supacloud.deploy.* oder supacloud.full nennt, erbt jeder Task ohne Profil in diesem Workspace genau diese Rechte – die Zusicherung „Nur-Lese-Rückfall“ gilt allein für den eingebauten Boden aus Schritt 3, nicht für das Profil, das du beförderst. Deploy-Tools brauchen weiterhin ihr eigenes serverseitiges Bestätigungsgeheimnis, und jede Stufe behält ihre Ratenlimits.

Die MCPs pflegen, die ein Profil erreichen darf

Einstellungen → Agents → MCPs listet die Capabilities der Art mcp dieses Workspace – die Tool-Server, die einem Agentenlauf mitgegeben werden können. Standard-Presets sind aktiv; der Tab erlaubt, sie pro Workspace zu deaktivieren oder zu ergänzen. Sie sind gruppiert als Code & Repositories, Observability, Browser & UI, Dokumentation und Eigene MCPs, jede Gruppe mit einer Anzeige n/m aktiv.

1. Nutze Aktivieren / Deaktivieren an einer einzelnen Capability oder Gruppe aktivieren / Gruppe deaktivieren am Gruppenkopf, um alle auf einmal umzuschalten.

2. Eine Capability, deren Konfiguration ein Secret braucht, ist mit Setup nötig markiert und öffnet statt eines Umschalters den Dialog Konfigurieren. Wähle ein vorhandenes Workspace-Secret oder füge einen neuen Wert ein und klicke auf Speichern & aktivieren – der Wert wird als Workspace-Secret abgelegt, und die Konfiguration der Capability behält nur eine Referenz darauf, nie den Wert selbst.

3. Für einen eigenen Server füllst du unten das Formular Eigenes Preset aus – interner Name, Label, optionale Beschreibung und ein JSON unter Konfiguration (JSON) – und klickst auf Preset speichern. Referenziere Secrets darin, statt sie einzubetten, etwa {"env":{"TOKEN":"${{ secrets.TOKEN }}"}}.

Eine aktivierte Capability macht den Server für den Workspace verfügbar; welche seiner Tools ein konkreter Lauf tatsächlich aufrufen darf, entscheiden weiterhin die Capability-Liste seines Profils und das Stufenmodell.

Die Skills schreiben, aus denen ein Profil schöpft

Ein Skill ist eine Zeile in agent_capabilities mit der Art skill – dieselbe Tabelle wie ein MCP, nur eine andere Art – und sein Körper ist ein Markdown-Anweisungssatz, den du an Ort und Stelle bearbeitest. Es gibt keinen Dateibaum und kein Repository dahinter: ein Skill ist ein Dokument, dazu die Liste der Agenten, für die er gilt.

1. Öffne Einstellungen → Agents → Skills. Der Tab ist eine Kartengalerie mit Suchfeld und der Facette Quelle (Integriert / Eigene); ein integrierter Skill trägt das Badge Seed.

2. Klicke auf Neuer Skill, vergib einen internen Namen, ein Label und optional eine Beschreibung und speichere. Der Skill startet mit leeren Anweisungen.

3. Öffne die Karte (Skill bearbeiten), um ihn zu schreiben. Im Editor legst du fest:

   • Bezeichnung und Beschreibung – bei einem integrierten Skill schreibgeschützt, denn sie werden vom Katalog verwaltet.
   • Agent-Ziele – die Agenten, für die der Skill gilt, als Umschalter. Wählst du keinen, gilt er für alle Agenten.
   • Anweisungen (Markdown) – der Körper des Skills, in einem Markdown-Editor.
   • Für Agenten verfügbar – der Ein-/Ausschalter des Skills.

4. Klicke auf Skill speichern. Einen eigenen Skill kannst du hier auch löschen; ein integrierter lässt sich nur deaktivieren.

Induzierte Skills kommen als Vorschlag, nicht als Skill

SupaCloud kann aus der Reflexion eines erfolgreichen Laufs einen verallgemeinerbaren Skill ableiten. Veröffentlicht wird dabei nie still etwas: Es entsteht ein Entwurf als Vorschlag, und erst eine Annahme macht daraus eine Skill-Zeile, die Läufe lesen können. Entschieden werden diese Vorschläge unter Posteingang → Entscheidungen, in den Zeilen mit dem Badge Skill-Vorschlag – siehe Den Posteingang abarbeiten. Entscheiden darf ein Workspace-Admin; ein Mitglied sieht die Zeile ohne Schaltflächen.

Pre- und Post-Flight-Checks

Die beiden Check-Listen eines Profils klammern einen Lauf ein, und beide sind standardmäßig leer – ein bestehendes Profil bleibt unberührt, bis du dich dafür entscheidest. Eine unbekannte Check-Art wird behalten und ignoriert, statt den Lauf scheitern zu lassen; genau das macht die Raw-Ansicht ungefährlich.

• Pre-Flight läuft, bevor der Container des Tasks vorbereitet wird. Die heute typisierte Art ist der Readiness-Guard (readiness_guard): Er blockiert den Start, wenn der verknüpfte Backlog-Eintrag als needs info klassifiziert wurde. Ein Task ohne Backlog-Eintrag gilt als bereit, der Guard greift also nur bei disponierter Backlog-Arbeit.
• Post-Flight läuft beim terminalen Ereignis des Tasks. Die Gate-Zusammenfassung (gate_summary) hält fest, dass die deterministischen Gates erwartet wurden, damit die Post-Flight-Ebene nachvollziehbar bleibt. Auch das Visual-Verify-Gate reitet auf dieser Liste, als ein vorwärtskompatibler Eintrag visual_verify, und wird von der Capture-und-Judge-Strecke des Backlogs durchgesetzt, nicht vom Post-Flight-Hook – konfiguriert wird es im Formular-Tab, beschrieben in Visual-Verify-Gates konfigurieren.

Jeder ausgewertete Check schreibt ein Audit-Ereignis, ob er besteht oder blockiert.

Wer was darf

Alle drei Tabs sind für jedes Workspace-Mitglied sichtbar – die Autorität ist der Server, nicht die Navigation – und die Tabs MCPs und Skills sagen das mit dem Badge Workspace-Admin in ihrem Kopf.

Aktion	Erforderliche Rolle
Profile, MCPs und Skills lesen	Jedes Workspace-Mitglied
Ein Profil anlegen oder ändern	Workspace-Eigentümer oder -Admin
Das Workspace-Standardprofil befördern	Workspace-Eigentümer oder -Admin
Eine MCP-Capability aktivieren, konfigurieren, anlegen oder löschen	Workspace-Eigentümer oder -Admin
Einen Skill anlegen, bearbeiten oder löschen	Workspace-Eigentümer oder -Admin
Einen induzierten Skill-Vorschlag annehmen oder ablehnen	Workspace-Eigentümer oder -Admin
Drift-Status und Versionsvorschläge des Governors lesen und entscheiden	Workspace-Eigentümer
Die Karte Governor-Audit lesen	Workspace-Eigentümer oder -Admin

Ein Mitglied, das ein Formular ändert und speichert, bekommt einen Berechtigungsfehler vom Server statt eines stillen Nichts – was du auf diesen Tabs siehst, ist also keine Zusage, dass du es auch schreiben darfst.

Siehe auch

• Berechtigungen und MCP-Tool-Stufen
• Visual-Verify-Gates konfigurieren
• Die Autonomiestufe festlegen
• Den Posteingang abarbeiten
• Der selbstlernende Governor