Każdy ekran w konsoli¶

Jedna strona, każdy moduł, opisany. Zrzuty ekranu podążają za motywem, w którym czytasz tę stronę - przełącz go przełącznikiem w nagłówku, a każdy obraz na tej stronie przełączy się razem z nim.

Zarejestrowane 01.09.2026 z działającego wdrożenia: 35 ekranów, 27 z nich w obu motywach pod docs/assets/screens/, nazwanych identycznie w light/ i dark/. Osiem ekranów Buildera jest tylko w ciemnym motywie i mówią o tym tam, gdzie się pojawiają.

Czat, w dwadzieścia sekund¶

CSV upuszczony do rozmowy, jedno zdanie instrukcji, a agent pisze Pythona, uruchamia go w sandboksie i odpowiada wykresami, które narysował z tych danych. Nic tutaj nie było konfigurowane akurat pod ten plik.

Gdzie lądujesz¶

Dashboard¶

Układalne widgety, najpierw całe wdrożenie, a potem ta organizacja. Runy, wydatki, kondycja usług i jakość odpowiedzi; każda karta jest bramkowana uprawnieniem, którego wymagają jej własne dane, więc karta, której podstawowego odczytu nie możesz wykonać, to karta, której nie dostajesz do wyboru.

Chat, w trakcie runa¶

Agent w trakcie myślenia, a potem komendy powłoki, które faktycznie wykonał w sandboksie, każda do rozwinięcia. Przejrzystość jest tu produktem: to, co zrobiło narzędzie, jest na ekranie, a nie w logu, który może przeczytać ktoś inny.

Budowanie agenta¶

Agents¶

Katalog. Każdy agent niesie wersję, która jest na żywo, informację o tym, kto może do niego sięgnąć, i o tym, czy czeka wersja robocza. Agent jest konfiguracją, a nie kodem - i dlatego tę listę może edytować ten, kto zna odpowiedź.

Agent templates¶

Szablony według branży, nad katalogiem. Zainstalowanie jednego tworzy wersję roboczą, którą kończysz i publikujesz; nic nie działa, dopóki tego nie zrobisz.

Skills¶

Know-how spisane raz i dzielone przez każdego związanego z nim agenta - jak obsługuje się zwroty, jaki jest styl firmy. Zedytuj je tutaj, a każdy związany z nim agent jest aktualny przy swoim następnym runie.

Skill gallery¶

Skille według branży. Instalacja kopiuje jeden do Twojej organizacji, gdzie możesz go edytować - kopia, więc źródło nie może zmienić tego, co mówią Twoi agenci.

Jeden skill¶

Otwarty do edycji, ze swoją kategorią. Nazwa, którą posługuje się model, jest ustalana przy tworzeniu i nie może się zmienić; wszystko inne tutaj może.

Context¶

Stały kontekst, z którego może czerpać każdy agent - słownik pojęć, polityka, ton marki. Wstrzykiwany do promptu albo czytany na żądanie, i aktualny w chwili, w której go zedytujesz.

Wewnątrz jednego agenta¶

Builder, zakładka po zakładce. Te osiem jest tylko w ciemnym motywie - jasna połowa nie została zarejestrowana, więc w odróżnieniu od każdego innego ekranu na tej stronie nie podążają za Twoją paletą.

Build¶

Instrukcje, model i endpoint. Zachowanie mieszka tutaj, a nie w kodzie, w Markdownie, z którego model czyta strukturę - a nagłówek niesie published obok Draft differs from v40, i o to właśnie chodzi: edytowanie nie wydaje.

Toolbox¶

Każda capability jako przełącznik - wyszukiwanie w wiedzy, przeglądarka, Python w sandboksie, wykresy, delegacja - a obok każdego bramka approvalu per narzędzie. Konfiguracja sięga wyłącznie tego, co zarejestrował kod.

MCP servers¶

Do których połączeń ten agent może sięgnąć i do których z ich narzędzi. Lista organizacji nadal go ogranicza; agent może zawęzić się wewnątrz niej i nie może sięgnąć poza nią.

Limits¶

Jeden limit miesięczny i sufit kroków. Limit jest sprawdzany przed każdym żądaniem do modelu, a limit kroków łapie tę drugą rozbieganą sytuację - pętlę narzędzia, która jest tania na wywołanie i nigdy się nie kończy.

Availability¶

Gdzie ten agent odpowiada: dashboard i API zawsze, plus każdy bot czatowy tutaj z nim związany. Agenta da się wywołać przez @handle tylko na tych botach, z którymi jest związany.

Routines, na agencie¶

Co robi, gdy nikt nie pisze, na tej samej zakładce - harmonogram, który da się wstrzymać, albo trigger zdarzeniowy.

History¶

Każda wersja, jaką ten agent miał. Ta, która była na żywo w marcu, nadal jest czytelna, i to właśnie czyni z rollbacku wybór, a nie projekt archeologiczny.

Visual map¶

Ten sam agent jako graf: co do niego sięga i po co on sięga. Przerywana ramka to coś, do czego nic nie jest podpięte - budżet bez własnego sufitu czyta się jako luka, a nie jako wartość domyślna.

Knowledge¶

Knowledge bases¶

Kolekcje. Zgrupuj powiązane dokumenty w jedną, a potem wybierz na czacie, które kolekcje agent może przeszukiwać.

Jedna kolekcja¶

Jej dokumenty, liczby fragmentów i wszystko, czego nie udało się zaingestować, wraz z powodem. To granice fragmentów są tym, do czego dopasowuje się wyszukiwanie, więc dokument wgrany ponownie po zmianie ustawień jest dzielony na nowo.

Parsowanie, per wgranie¶

Wybór, którego nikt inny nie wystawia: PyMuPDF, LiteParse albo LlamaParse, strategia dzielenia na fragmenty, rozmiar fragmentu i zakładka, OCR i jego język. Ustawiane na kolekcji i nadpisywalne przy następnym pliku, który dodasz - bo zeskanowany cennik i runbook w Markdownie nie chcą tego samego parsera, a zły parser jest różnicą między odpowiedzią a odmową.

Co się wydarzyło i co czeka¶

Runs¶

Każdy run, który wykonała ta organizacja, ze swoim statusem, powierzchnią, modelem, osobą i kosztem. Run jest procesem: startuje, można go zatrzymać i zostawia zapis.

Jeden run, otwarty¶

Tokeny wejściowe i wyjściowe, koszt do czterech miejsc po przecinku, ile to trwało oraz oś czasu każdej tury i każdego wywołania narzędzia. Czat, w którym to się wydarzyło, jest o jedno kliknięcie stąd.

Approvals¶

Wszystko, co czeka na człowieka, razem z tym, co agent zamierza zrobić. Approval jest rozstrzygany dokładnie raz - druga decyzja na rozstrzygniętym jest odrzucana, i to ten szczegół sprawia, że warto mieć tę bramkę.

Spend¶

Ile faktycznie wydano, w podziale na okresy. Budżet jest sprawdzany przed żądaniem do modelu, a nie sumowany po fakcie, więc run, który go przekroczy, zatrzymuje się w środku odpowiedzi i mimo to zapisuje swój koszt.

Routines¶

Co agenci robią, gdy nikt nie pisze - według harmonogramu albo kiedy przyjdzie zdarzenie. Te runy są budżetowane, zatwierdzane i audytowane jak każde inne.

Nowy trigger zdarzeniowy¶

Nazwanie zdarzenia, które uruchamia run, nad listą rutyn.

Organizacja¶

Organizations¶

Przełączaj się między nimi, zarządzaj członkami i twórz nowe. Autorytet wewnątrz organizacji to wiersz członkostwa plus katalog uprawnień - na użytkowniku nie ma kolumny z rolą.

Vault¶

Każdy klucz, który ta organizacja przechowała, zapieczętowany per tenant. Wymienialny, nigdy więcej odczytywalny; a rotacja jest niewidoczna dla opublikowanego agenta, który odwołuje się do sekretu, a nie do jego wartości.

MCP servers¶

Podłącz dowolny serwer MCP po URL, a jego narzędzia stają się przełącznikami w Builderze. Podłącz go dla organizacji, a może z niego korzystać każdy agent; podłącz go dla siebie, a zostaje w Twoim własnym czacie.

Channels¶

Platformy czatowe, na których odpowiada ta organizacja - Slack, Telegram, Mattermost. Bot obsługuje każdego związanego z nim agenta, a to powiązanie tworzy się na zakładce Availability tego agenta.

Sandboxes¶

Miejsce, w którym agenci tej organizacji uruchamiają komendy powłoki i trzymają pliki. Agent nazywa połączenie po id, więc przeniesienie się na inny host to jedna edycja tutaj, a nie ponowna publikacja każdego agenta.

Workspaces¶

Pliki, które agenci trzymają dla Ciebie. Workspace to przestrzeń robocza - jest kasowany razem z rozmową, do której należy, i nie jest miejscem na przechowywanie czegokolwiek trwałego.

Administracja wdrożeniem¶

Users¶

Każdy, kto może zalogować się do tego wdrożenia, oraz flaga administratora aplikacji, która jest niezależna od jakiejkolwiek roli w organizacji.

All organizations¶

Każdy tenant w tym wdrożeniu, ze swoim właścicielem, członkami i agentami.

System¶

Baza danych, Redis, magazyn wektorów i dostęp do modeli - te same sprawdzenia, które wykonuje agenticos cmd doctor, na jednej stronie.

Deployment¶

Własna tożsamość i polityka tego wdrożenia: rejestracja, zaproszenia, komunikaty i to, co spotyka odwiedzający po raz pierwszy.

Czego jeszcze tu nie ma¶

Jasna połowa Buildera - tych osiem ujęć istnieje tylko w ciemnym motywie.
Logowanie i onboarding, czyli to, co odwiedzający faktycznie spotyka za pierwszym razem.

Podsumowanie¶

27 modułów ma oba motywy w docs/assets/screens/, pod tą samą nazwą; osiem ekranów Buildera jest tylko w ciemnym.
Na tej stronie obraz zapisuje się dwa razy, z #only-light i #only-dark; Material pokazuje ten, który pasuje do palety czytelnika.
W README ta sama para trafia do <picture> z media="(prefers-color-scheme: dark)", i tak właśnie robi to GitHub.
Parsowanie to ustawienie, które warto znać, zanim cokolwiek wgrasz: parser i rozmiar fragmentu decydują o tym, czy na pytanie o tabelę da się w ogóle odpowiedzieć.