docs/departments.de.md

Rama main · réplica de lectura del repositorio original.

---
source_sha: "a73281723216"
---

# Abteilungen und Gruppen { #departments-and-groups }

Unternehmen sind in Abteilungen organisiert: Vertrieb, Finanzen, Personal,
Support. In AgenticOS ist eine Abteilung eine [Gruppe](directory.md#groups), und
eine Gruppe entscheidet, wer was nutzen darf. Die Finanzabteilung kann eigene
Agents, Skills, Kontextdateien, Wissensdatenbanken und MCP-Server haben, die der
Vertrieb nie sieht, während das, was alle brauchen, für die ganze Organisation
offen bleibt.

## Abteilungen hinzufügen { #adding-your-departments }

**Gruppen** in der Hauptnavigation listet die Gruppen der Organisation. Ein
Mitglied mit `members:manage` legt sie einzeln mit **Neue Gruppe** an oder
mehrere auf einmal mit **Abteilungen hinzufügen**, das Vertrieb, Finanzen,
Personal, Support, Entwicklung, Marketing, Recht und Betrieb anbietet, jeweils
mit Symbol und kurzer Beschreibung. Umbenennen, Symbol ändern oder löschen geht
danach wie bei jeder anderen Gruppe.

Personen kommen auf der Seite der Gruppe hinzu, von Hand oder über eine
[Zuordnung einer Verzeichnisgruppe](directory.md#directory-group-mappings), wenn
Ihr Unternehmen seine Teams bereits in einem Verzeichnis führt.

### Die Leitung einer Gruppe { #a-groups-lead }

Ein Admin kann ein Mitglied zur **Leitung** der Gruppe machen - die Krone neben
ihm in der Mitgliederliste. Die Leitung fügt Personen ihrer Gruppe hinzu und
entfernt sie, ohne die Organisation zu verwalten, sodass eine Abteilungsleitung
eine neue Kollegin aufnehmen kann, ohne die IT zu fragen. Nur wer
`members:manage` hat, bestimmt oder entfernt eine Leitung, denn sie vergibt
Zugriff auf alles, was mit der Gruppe geteilt ist.

## Wer etwas Neues nutzen darf { #who-can-use-a-new-thing }

Wer einen Agent, einen Skill, eine Wissensdatenbank, eine Kontextdatei oder einen
gemeinsamen MCP-Server anlegt, beantwortet eine Frage: **wer es nutzen darf**.

| Auswahl | Wen es erreicht | Gespeichert als |
|---|---|---|
| **Alle** - der Standard | Jedes Mitglied der Organisation | Sichtbarkeit `org` |
| **Nur ich** | Sie und alle, mit denen Sie es später teilen | Sichtbarkeit `private` (eine Wissensdatenbank wird persönlich) |
| **Bestimmte Personen** | Die Mitglieder der gewählten Gruppen und die Personen, die Sie nennen | Sichtbarkeit `private`, mit jeder davon auf `use` geteilt |

Gruppen werden angeboten, sobald Sie die dritte Option wählen; Personen findet
man, indem man einen Namen oder eine E-Mail-Adresse eintippt. Jede Auswahl bleibt
als Chip stehen, bis Sie sie entfernen.

Die Mitglieder einer Gruppe finden, was mit ihr geteilt ist, nutzen es und binden
es an ihre eigenen Agents. Personen außerhalb der Gruppe sehen es weder in
Listen, in der Suche, in den Auswahlen des Builders, über die API noch über den AI
Architect, der mit den Berechtigungen der fragenden Person handelt. Mitglieder,
deren Rolle jede Ressource erreicht - standardmäßig Owner, Admin und Builder -,
sehen weiterhin alles; siehe [Berechtigungen](permissions.md).

Apps veröffentlichen Agents, und sie sind zunächst privat für die Person, für die
der Run lief; mit einer Gruppe teilt man eine im Bereich **Share**. Der Bereich
**Sharing** jeder Ressource fügt Gruppen auch nach dem Anlegen hinzu oder
entfernt sie.

## Die MCP-Server einer Abteilung { #a-departments-mcp-servers }

Ein MCP-Server der Organisation - ein gemeinsames Konto, einmal verbunden - lässt
sich genauso einschränken, damit der Buchhaltungsserver der Finanzabteilung ihr
gehört. Mitglieder, die MCP-Server verwalten, sehen die Server der ganzen
Organisation, die, die sie selbst verbunden haben, und die, die mit ihren Gruppen
oder mit ihnen geteilt sind; Owner und Admins sehen alle. Ein Builder außerhalb
der Finanzabteilung findet ihren Server nicht in der Liste, öffnet ihn nicht über
seine ID und veröffentlicht keinen Agent, der ihn nutzt. Siehe
[MCP](mcp.md#personal-or-organization-wide).

Ein Agent, der ihn bereits nutzt, funktioniert weiter für alle, die ihn ausführen
dürfen. Die Auswahl entscheidet, wer den Server wählen darf, nicht, wer über ihn
Antworten bekommt - siehe [woher das Wissen eines Agents kommt](#where-an-agents-knowledge-comes-from).

## Die Seite einer Gruppe { #a-groups-page }

Eine Gruppe zu öffnen, zeigt ihre Personen und alles, was mit ihr geteilt ist,
nach Art gruppiert - Agents, Wissensdatenbanken, Skills, Kontext, Apps und
MCP-Server - mit der Stufe, auf der jedes geteilt wurde. Wer liest, sieht nur, was er ohnehin
öffnen könnte; ein Mitglied des Vertriebs erfährt auf der Seite der
Finanzabteilung also nicht, was diese aufbewahrt.

**Zu dieser Gruppe hinzufügen** teilt mehreres auf einmal: Es listet alles, was
die lesende Person bearbeiten darf und die Gruppe noch nicht hat, mit Suche,
einem Häkchen je Eintrag und der Stufe, auf der geteilt wird. Jedes ist dieselbe
Freigabe, die der Bereich Share schreibt, und braucht dasselbe Recht zu
bearbeiten.

Mitglieder werden benachrichtigt, wenn etwas mit ihrer Gruppe geteilt wird - im
Posteingang und, wenn gewünscht, per E-Mail; *Shared with you or your group* in den
Benachrichtigungseinstellungen schaltet das ab. Karten in der ganzen Konsole
sagen, für wen etwas ist: *Alle*, seine Abteilungen mit Namen - beides, wenn es
für alle ist und zu einer Abteilung gehört - oder *Privat*.

## Eine Liste nach Abteilung gruppieren { #grouping-a-list-by-department }

Die Seiten Apps, Skills, Context und Knowledge bases haben je einen Filter
**Gruppe**. Wer Finance wählt, sieht nur, was mit Finance geteilt ist, und die
Auswahl bleibt in der Adresse, sodass die Ansicht ein Link ist, den man
weitergeben kann. Eine Gruppe ist die einzige Gruppierung - Ordner gibt es nicht -,
weil eine Gruppe schon entscheidet, wen eine Ressource erreicht, und eine zweite
Hierarchie wäre eine zweite Antwort auf dieselbe Frage.

Der Filter erweitert eine
Liste nie: Was der Lesende nicht öffnen darf, wird nicht gezeigt. Die Picker im
Builder nennen bei jeder Ressource ihre Abteilungen, und die vier
Listen-Endpunkte nehmen `group_id` für dieselbe Einschränkung über die API.

## Das Budget einer Abteilung { #a-departments-budget }

Ein Administrator kann einer Abteilung beim Anlegen oder Bearbeiten ein
**monatliches Budget** geben. Es misst, was die Mitglieder der Abteilung
ausführen - jeder Agent, im laufenden Kalendermonat - und stoppt den Run eines
Mitglieds, sobald die Abteilung es erreicht hat, mit einer Ablehnung, die die
Abteilung nennt. Wer in zwei Abteilungen ist, unterliegt beiden Caps. Siehe
[die Budgetebenen](governance.md#budgets).

Überschreitet eine Abteilung 80 % ihres Monats, werden ihre Leitung und die
Administratoren einmal benachrichtigt - im Posteingang und per E-Mail, sofern
sie *Abteilungsbudget bei 80 %* nicht abschalten. Stoppt das Cap einen Run,
erfahren es dieselben Personen.

Die Seite der Gruppe zeigt den Monat gegenüber dem Cap und exportiert ihn als
CSV, eine Zeile pro Mitglied und Agent. Die Karte **Ausgaben nach Abteilung** im
Dashboard listet den Monat jeder Abteilung. Beides erfordert `runs:view`; die
Leitung einer Abteilung kann deren CSV auch über
`GET /orgs/{org_id}/groups/{group_id}/spend.csv` herunterladen.

## Wie gut ihre Leute Antworten bekommen { #how-well-its-people-are-answered }

Neben dem Budget zeigt die Seite der Gruppe, wie die Personen der Abteilung
Antworten in den letzten 30 Tagen bewertet haben: den hilfreichen Anteil, die
Agents, die sie am meisten genutzt haben, und die zuletzt als nicht hilfreich
bewerteten Antworten, jede mit ihrem Kommentar und einem Link zu ihrem Run.
Eine Bewertung zählt für die Abteilung der Person, die sie abgegeben hat, und
für jede Abteilung, in der diese Person ist. Die Karte **Antwortqualität nach
Abteilung** im Dashboard ordnet die Abteilungen, die am wenigsten hilfreichen
zuerst, über den Zeitraum des Dashboards.

Die Karte auf der Seite ist für alle mit `runs:view` und für die Leitung der
Abteilung; ein gewöhnliches Mitglied oder ein Mitglied einer anderen Abteilung
sieht nichts davon. Die Dashboard-Karte braucht `runs:view`. API:
`GET /orgs/{org_id}/groups/quality` und
`GET /orgs/{org_id}/groups/{group_id}/quality`, beide mit `from` und `to`.

## Woher das Wissen eines Agents kommt { #where-an-agents-knowledge-comes-from }

Ein Agent kann an eine Wissensdatenbank, einen Skill, eine Kontextdatei oder einen
MCP-Server gebunden werden, die enger geteilt sind als der Agent selbst, und nichts verhindert
das. Alle, die der Agent erreicht, bekommen dann Antworten aus dieser Quelle,
auch Personen, die sie selbst nicht öffnen könnten.

`GET /agents/{agent_id}/knowledge-reach` beantwortet, woher das Wissen des Agents
kommt: wen der Agent erreicht und bei jeder Quelle, ob sie der ganzen Organisation
gehört oder welchen Gruppen, wobei Quellen markiert sind, die enger geteilt sind
als der Agent. Wenn das nicht gewollt ist, schränken Sie den Agent auf dieselben
Gruppen ein oder erweitern Sie die Quelle.

## Die Gruppen der Person in Anweisungen { #the-persons-groups-in-instructions }

Anweisungen können mit `{{groups}}` die Gruppen der Person nennen, mit der der
Agent spricht - zum Beispiel *„Du hilfst jemandem aus {{groups}}.“* Daraus werden
ihre Gruppennamen, durch Kommas getrennt, oder nichts für einen Besucher. Siehe
[Variablen](reference/spec.md#variables).

## Was noch nicht abgedeckt ist { #what-is-not-covered-yet }

Ein Run, den niemand aus der Organisation gestartet hat - ein Zeitplan, ein
Besucher in einem Kanal - zählt zu keinem Abteilungsbudget, denn der Monat einer
Abteilung ist das, was ihre Mitglieder ausgeführt haben.