Działy i grupy

Firmy dzielą się na działy: sprzedaż, finanse, HR, wsparcie. W AgenticOS dział to grupa, a grupa decyduje, kto może z czego korzystać. Finanse mogą mieć własnych agentów, skille, pliki kontekstu, bazy wiedzy i serwery MCP, których sprzedaż nigdy nie zobaczy, a to, czego potrzebują wszyscy, zostaje otwarte dla całej organizacji.

Dodawanie działów

Grupy w głównej nawigacji pokazują grupy organizacji. Członek z members:manage dodaje je pojedynczo przyciskiem Nowa grupa albo kilka naraz przyciskiem Dodaj działy, który proponuje Sprzedaż, Finanse, HR, Wsparcie, Inżynierię, Marketing, Dział prawny i Operacje, każdy z ikoną i krótkim opisem. Potem można zmienić im nazwę, ikonę albo je usunąć jak każdą inną grupę.

Ludzi dodaje się do grupy na jej stronie, ręcznie, albo przez mapowanie grupy katalogowej, jeśli firma prowadzi już swoje zespoły w katalogu.

Lider grupy

Administrator może ustawić członka jako lidera grupy - korona przy nim na liście członków. Lider dodaje osoby do swojej grupy i je z niej usuwa bez administrowania organizacją, więc kierownik działu może dodać nowego pracownika bez proszenia IT. Lidera wyznacza i odwołuje tylko ktoś z members:manage, bo lider rozdaje dostęp do wszystkiego, co udostępniono grupie.

Kto może korzystać z nowej rzeczy

Tworzenie agenta, skilla, bazy wiedzy, pliku kontekstu albo wspólnego serwera MCP zadaje jedno pytanie: kto może z tego korzystać.

Wybór	Kto do tego sięga	Zapisane jako
Wszyscy - domyślnie	Każdy członek organizacji	Widoczność org
Tylko ja	Ty i osoby, którym udostępnisz to później	Widoczność private (baza wiedzy staje się osobista)
Wybrane osoby	Członkowie wybranych grup i osoby, które wskażesz	Widoczność private, udostępnione każdej z nich na poziomie use

Grupy pojawiają się od razu po wybraniu trzeciej opcji; osoby znajduje się, wpisując imię albo adres e-mail. Każda wybrana zostaje jako chip, dopóki jej nie usuniesz.

Członkowie grupy znajdują to, co jej udostępniono, korzystają z tego i podpinają do własnych agentów. Osoby spoza grupy nie widzą tego na listach, w wyszukiwaniu, w wyborach Buildera, przez API ani przez Architekta, który działa z uprawnieniami pytającej osoby. Członkowie, których rola sięga do każdego zasobu - domyślnie właściciel, administrator i builder - nadal widzą wszystko; zobacz Uprawnienia.

Aplikacje publikują agenci i na początku są prywatne dla osoby, dla której był run; grupie udostępnia się je w panelu Share. Panel Sharing każdego zasobu dodaje i usuwa grupy także po utworzeniu.

Serwery MCP działu

Serwer MCP organizacji - jedno wspólne konto, podłączone raz - można zawęzić w ten sam sposób, żeby serwer księgowy Finansów był Finansów. Członkowie zarządzający serwerami MCP widzą serwery całej organizacji, te, które sami podłączyli, i te udostępnione ich grupom albo im; właściciele i administratorzy widzą wszystkie. Builder spoza Finansów nie znajdzie ich serwera na liście, nie otworzy go po identyfikatorze i nie opublikuje agenta, który go używa. Zobacz MCP.

Agent, który już go używa, działa dalej dla każdego, kto może go uruchomić. Ten wybór decyduje o tym, kto może serwer wybrać, a nie o tym, kto dostaje przez niego odpowiedzi - zobacz skąd pochodzi wiedza agenta.

Strona grupy

Otwarcie grupy pokazuje jej ludzi i wszystko, co jej udostępniono, pogrupowane według rodzaju - agenci, bazy wiedzy, skille, kontekst, aplikacje i serwery MCP - z poziomem udostępnienia każdego. Czytający widzi tylko to, co i tak mógłby otworzyć, więc członek Sprzedaży czytający stronę Finansów nie dowie się, co Finanse trzymają.

Dodaj do tej grupy udostępnia kilka rzeczy naraz: pokazuje wszystko, co czytający może edytować, a czego grupa jeszcze nie ma, z wyszukiwarką, polem do zaznaczenia przy każdej rzeczy i poziomem udostępnienia. Każde to ten sam grant, który zapisuje panel Share, więc wymaga tego samego prawa do edycji.

Członkowie dostają powiadomienie, gdy coś udostępniono ich grupie - w skrzynce i, jeśli chcą, e-mailem; Shared with your group w ustawieniach powiadomień to wyłącza. Karty w całej konsoli mówią, dla kogo jest każda rzecz: Wszyscy, jej działy z nazwy - jedno i drugie, gdy jest dla wszystkich i należy do działu - albo Prywatne.

Grupowanie listy po dziale

Strony Apps, Skills, Context i Knowledge bases mają filtr grupy. Wybranie Finance zawęża listę do tego, co udostępniono grupie Finance, a wybór zostaje w adresie, więc widok jest linkiem, który można komuś wysłać. Grupa to jedyny sposób grupowania - folderów nie ma - bo grupa już decyduje, do kogo trafia zasób, a druga hierarchia byłaby drugą odpowiedzią na to samo pytanie.

Filtr nigdy nie poszerza listy: czego czytający nie może otworzyć, tego nie widzi. Pickery w Builderze pokazują przy każdym zasobie jego działy, a cztery endpointy list przyjmują group_id, żeby zawęzić tak samo przez API.

Budżet działu

Administrator może nadać działowi miesięczny budżet przy jego tworzeniu lub edycji. Liczy to, co uruchamiają członkowie działu - każdy agent, bieżący miesiąc kalendarzowy - i zatrzymuje run członka, gdy dział go wyczerpie, z odmową, która nazywa dział. Osoba w dwóch działach podlega obu limitom. Zobacz poziomy budżetu.

Gdy dział przekroczy 80% swojego miesiąca, jego lider i administratorzy dostają jedno powiadomienie - w skrzynce i e-mailem, chyba że wyłączą Department budget at 80%. Gdy limit zatrzyma run, dowiadują się ci sami ludzie.

Strona grupy pokazuje miesiąc na tle limitu i eksportuje go do CSV, wiersz na członka i agenta. Karta Wydatki działów na dashboardzie pokazuje miesiąc każdego działu. Obie wymagają runs:view; lider działu może też pobrać jego CSV z GET /orgs/{org_id}/groups/{group_id}/spend.csv.

Jak dział jest obsługiwany

Obok budżetu strona grupy pokazuje, jak osoby z działu oceniały odpowiedzi w ostatnich 30 dniach: odsetek pomocnych, agentów, z których korzystały najczęściej, i ostatnie odpowiedzi ocenione jako niepomocne, każdą z komentarzem i linkiem do jej runa. Ocena liczy się dla działu osoby, która ją wystawiła, i dla każdego działu, w którym ta osoba jest. Karta Jakość odpowiedzi według działów na dashboardzie układa działy od najmniej pomocnych, w okresie wybranym na dashboardzie.

Karta na stronie jest dla każdego z runs:view i dla lidera działu; zwykły członek ani członek innego działu nie widzi z niej nic. Karta na dashboardzie wymaga runs:view. API: GET /orgs/{org_id}/groups/quality oraz GET /orgs/{org_id}/groups/{group_id}/quality, oba przyjmują from i to.

Skąd pochodzi wiedza agenta

Agenta można podpiąć do bazy wiedzy, skilla, pliku kontekstu albo serwera MCP udostępnionego węższemu gronu niż on sam i nic tego nie zablokuje. Każdy, do kogo agent dociera, dostaje wtedy odpowiedzi z tego źródła, także osoby, które same nie mogłyby go otworzyć.

GET /agents/{agent_id}/knowledge-reach odpowiada, skąd pochodzi wiedza agenta: do kogo agent dociera, a przy każdym źródle, czy jest całej organizacji, czy których grup, z oznaczeniem źródeł udostępnionych węższemu gronu niż agent. Jeśli to nie to, co planowano, zawęź agenta do tych samych grup albo poszerz źródło.

Grupy osoby w instrukcjach

Instrukcje mogą nazwać grupy osoby, z którą rozmawia agent, przez {{groups}} - na przykład „Pomagasz komuś z działu {{groups}}.” Zmienna staje się nazwami jej grup rozdzielonymi przecinkami albo pustym tekstem dla odwiedzającego. Zobacz Zmienne.

Czego jeszcze nie obejmuje

Run, którego nie uruchomił nikt z organizacji - harmonogram, gość na kanale - nie liczy się do budżetu żadnego działu, bo miesiąc działu to to, co uruchomili jego członkowie.