Ein Begriff, eine Bedeutung – dasselbe Wort in der Benutzeroberfläche, in der API
und in dieser Dokumentation. Wo es zu einem Begriff eine ausführlichere Seite
gibt, verweist die Definition darauf. Das konzeptionelle Modell hinter den
Mandanten-Begriffen findest du unter
Workspaces und Organisationen.
| Begriff |
Bedeutung |
| Organisation |
Der oberste Mandant. Er verwaltet Abrechnung, Sitzplätze, Single Sign-on und Einladungen. Jedes Konto gehört zu genau einer Organisation; eine persönliche wird bei der Registrierung für dich angelegt. Die Benutzeroberfläche bezeichnet eine Organisation entweder als Persönlich oder als Organisation – niemals als Team. Siehe Workspaces und Organisationen. |
| Workspace |
Der Container, in dem alles andere liegt: Projekte, Tasks, Runs, Workflows, Zeitpläne, Secrets, Verbindungen und API-Tokens. Die Mitgliedschaft gilt pro Person, und du wechselst den Workspace über die Seitenleiste oder mit workspace switch. Das Wort team wird für dieses Konzept nie verwendet. |
| Sitzplatz (Seat) |
Das, was einer Organisation in Rechnung gestellt wird. Die Workspace-Mitgliedschaft gewährt den Zugang; der Sitzplatz ist die Abrechnungseinheit, und jedes aktive Mitglied belegt einen. Der Sitzplatz-Typ eines Mitglieds kann dessen Berechtigungen einschränken oder erweitern. Siehe Sitzplätze und Abrechnung verwalten. |
| Projekt |
Ein benanntes Repository- bzw. Codebasis-Ziel innerhalb eines Workspaces. Es trägt die Git- und Issue-Tracker-Verbindung, die Automatisierungs-Einstellungen sowie die Tasks, Issues und Workflows, die dazugehören. Siehe Automatisierungen. |
| Begriff |
Bedeutung |
| Aufgabe (Task) |
Eine dauerhafte Definition agentischer Arbeit – Projekt, Prompt, Agent, Modell und Issue-Verknüpfung. Du legst einen Task einmal an und kannst ihn beliebig oft ausführen. Er ist die Einheit, auf die sich follow, logs, intervene und cancel beziehen. Siehe Runs und Tasks. |
| Run |
Eine einzelne Ausführung. Ein Task kann viele Runs haben – ein Neustart ist ein neuer Run mit einem frischen Ereignisprotokoll – und die Ausführung eines Workflows ist ein Run, dessen Kinder die Runs der einzelnen Knoten sind. Siehe Runs und Tasks. |
| Zeitplan (Schedule) |
Ein wiederkehrender oder einmaliger Auslöser, der einen Task oder Workflow in einem cron-artigen Takt startet. Siehe Einen Zeitplan einrichten. |
| Workflow |
Ein Graph aus Knoten – Agent, Code, Datenbankabfrage, Connector, Gate, menschliche Freigabe –, der als Run ausgeführt wird. Du baust ihn im visuellen Builder oder schreibst ihn als YAML. Siehe Deinen ersten Workflow erstellen. |
| Begriff |
Bedeutung |
| Agent |
Der Coding-Agent-Prozess, den SupaCloud in einem Container startet, um einen Run auszuführen. Welcher Agent es ist und wie frei er handelt, ergibt sich aus dem Agent-Profil. Siehe Dein erster Agent-Run. |
| Agent-Profil |
Eine gespeicherte, wiederverwendbare Agenten-Konfiguration: Modell, Reasoning-Effort, die Tools, die der Agent aufrufen darf, sowie seine Pre- und Post-Flight-Checks. Ein Profil kann als Workspace-Standard markiert werden. Siehe Berechtigungen und MCP-Tool-Stufen. |
| Teammates |
Eine Gruppe von Agenten, die gemeinsam an einem Task arbeitet. Team und Teammates beziehen sich in SupaCloud immer auf Agenten, niemals auf den Mandanten. Siehe Workspaces und Organisationen. |
| Skill |
Eine benannte, wiederverwendbare Anweisung in Markdown, auf die Agenten zurückgreifen können. Skills bearbeitest du in den Einstellungen; ein Agent kann außerdem einen Skill vorschlagen, den er nützlich fand – du gibst ihn mit skills proposals frei oder lehnst ihn ab. Siehe Befehle des Web-Terminals. |
| Council |
Mehrere Agenten beraten dieselbe Frage, und ihre Antworten werden zu einer Empfehlung zusammengeführt. Councils haben ihre eigene Oberfläche unter Intelligence, und eine Pipeline-Stufe kann so eingestellt werden, dass sie einen Council nutzt. Siehe Automatisierungen. |
| Memory |
Dauerhaftes Wissen, das Agenten als Kontext erhalten – im Scope für dich persönlich, für ein Projekt oder für den gesamten Workspace. Du kannst eine Memory selbst schreiben, und Agenten schlagen am Ende eines Tasks Memories zur Freigabe vor. Siehe Memories verwalten. |
| MCP |
Model Context Protocol – die Tool-Schnittstelle zwischen SupaCloud und einem Agenten. Die Tools sind in vier Stufen gruppiert (baseline, read, ops, deploy), und das Agent-Profil entscheidet, welche Stufen der Agent nutzen darf. Siehe Berechtigungen und MCP-Tool-Stufen. |
| Begriff |
Bedeutung |
| Autonomiestufe |
Eine Zahl von 0 bis 100, gesetzt pro Workspace, Projekt oder Agent-Profil, die festlegt, wie weit SupaCloud unbeaufsichtigt gehen darf: ob es selbst Arbeit aufnimmt, wie bereitwillig es innehält und dich fragt, und wie weit es mergen darf. Sie rastet auf fünf benannten Stufen ein, von Manuell bis Entfesselt. Siehe Autonomie und die Delivery-Engine. |
| Freigabe (Gate) |
Ein Punkt, an dem die Arbeit anhält und auf einen Menschen wartet – entweder hält ein Agent mitten im Run bei einem riskanten Tool-Aufruf, einer offenen Frage oder einer visuellen Prüfung an, oder ein Workflow erreicht sein menschliches Gate. Offene Freigaben sammeln sich im Posteingang und in approvals. Siehe Agenten-Aktionen freigeben oder ablehnen. |
| Backlog |
Die Warteschlange importierter, klassifizierter Issues, aus der ein Projekt in Prioritätsreihenfolge Arbeit anstößt – begrenzt durch die Autonomiestufe, die Parallelitäts-Obergrenzen und das Budget. Siehe Das Backlog ausführen. |
| Backlog-Eintrag |
Eine Arbeitseinheit in dieser Warteschlange. Er trägt die Klassifizierung, nach der das Backlog sortiert – Art, Priorität (die auf einen Schweregrad abbildet) und Umfang (klein, mittel oder groß) – sowie seinen Dispatch-Status und einen etwaigen Blockierungsgrund. Siehe Das Backlog ausführen. |
| Konzept-Freigabemodus |
Ein Freigabemodus, in dem der Agent zuerst ein code-fundiertes Umsetzungs-Konzept schreibt und innehält, damit du es liest. Nach deiner Freigabe setzt derselbe Run die Umsetzung fort. Siehe Automatisierungen. |
| Abschlussaktion |
Was mit dem verknüpften Issue geschieht, wenn ein issue-verknüpfter Task fertig ist: kommentieren und schließen, nur kommentieren oder keines von beiden. Siehe Automatisierungen. |
| Closeout |
Das Ritual, das ein Agent am Ende eines Tasks ausführt – das Quell-Issue schließen, die Projektdokumentation aktualisieren, die Benutzerdokumentation aktualisieren, eine Wiki-Notiz schreiben, eine Memory vorschlagen. Jeder Schritt wird einzeln aktiviert, pro Workspace, pro Projekt oder für einen einzelnen Run. Siehe Den Standard-Closeout konfigurieren. |
| Begriff |
Bedeutung |
| App |
Eine kleine Weboberfläche, die du in SupaCloud baust und ausrollst – mit eigenem Quellbaum und optional eigenem Datenbankschema. Apps liegen unter Build. |
| Script |
Ein in sich geschlossenes Stück Code – JavaScript, TypeScript oder Python –, das SupaCloud in einer Sandbox ausführt. Es erreicht das Netzwerk nur über eine Verbindung, die du daran bindest. Scripts liegen unter Build. |
| Connector |
Eine Sandbox-Komponente, die eine Drittanbieter-API kapselt, sodass ein Workflow sie als Knoten aufrufen kann. Installiere einen aus dem Marketplace oder baue deinen eigenen. Siehe Einen Marketplace-Connector installieren. |
| Ressource |
Eine benannte, mit Zugangsdaten hinterlegte Integration – ein Mailserver, ein Bot-Token, eine Datenbank, eine Storage-Bibliothek. In der Benutzeroberfläche heißen diese Verbindungen. Siehe Eine Custom-Verbindung anlegen. |
| Runner |
Eine separate Maschine, die bei deiner SupaCloud-Installation registriert ist und Runs abholt und ausführt. Ohne Runner läuft alles auf dem Server selbst. Siehe Die Runner-Flotte. |
| Begriff |
Bedeutung |
| Marketplace |
Der Katalog installierbarer Angebote: Apps, Workflows, Scripts, Connectors, Bundles und Runner-Angebote. Ein Angebot kann kostenlos oder kostenpflichtig sein und durchläuft ein Review-Gate, bevor es installiert werden kann. Siehe Einen Marketplace-Connector installieren. |
| Bundle |
Ein einzelnes Marketplace-Angebot, das mehrere Primitive zusammen ausliefert – etwa eine App plus den Workflow dahinter –, sodass eine Installation das ganze Produkt bringt. Ein Bundle braucht mindestens zwei. Siehe Ein Marktplatz-Paket veröffentlichen. |
| Begriff |
Bedeutung |
| Live-Modus |
Die Streaming-Ansicht, in der du nach run oder follow landest: Ereignisse kommen an, während sie passieren, und alles, was du eingibst, geht als Intervention an den Agenten. Verfügbar im Web-Terminal, in Telegram und in Discord. Siehe Befehle des Web-Terminals. |
| Ausführlichkeit (Verbosity) |
Wie viel ein Live-Feed zeigt – reduced für einen ruhigen Feed oder chatty für den vollen Strom samt Denkprozess und Tool-Details des Agenten. Setze sie mit density. Siehe Die Live-Feed-Ausführlichkeit festlegen. |
| Debug-Modus |
Ein Schalter pro Sitzung, der interne Vorgänge im Live-Feed sichtbar macht: Tool-Aufrufe, Scope-Auflösung, automatisch aufgelöste Gates, Eskalationen bei gefährlichen Aktionen. Er wirkt nur, solange ein Workspace-Administrator die Debug-Obergrenze geöffnet hat, und überdauert die Sitzung nie. Siehe Debug-Modus verwenden. |
| Delivery-Board |
Die Übersicht laufender Agenten-Arbeit, gruppiert nach Agent-Profil und Lieferstatus. Du erreichst sie unter Berichte. Es ist kein Mandanten-Konzept. Siehe Navigation und Hubs. |
Das Vokabular oben ist die benutzerseitige Hälfte. Die maßgebliche Tabelle und
Spalte hinter jedem Begriff – und die Namensregeln, die dafür gelten – findest du
im Data Dictionary.