Jak wdrożyć Grokbota w firmie — przewodnik dla administratorów

2026-10-21 • Grok • AI zagraniczne •tutorial •waga 4/5 •20 min czytania

Webinar dla administratorów wdrażających Grokbota w organizacji: kontrola działań botów, bezpieczeństwo danych, etapowe wdrożenie, boty zespołowe oraz monitoring użycia i kosztów. Materiał dla zespołów IT i bezpieczeństwa.

Robocza publikacja redakcyjna na podstawie publicznego transkryptu YouTube. Źródło: YouTube.

Oryginalny tytuł filmu

Grok Bot for Admins

O czym jest ten film

  1. Webinar dla administratorów Grokbota poprowadzili Rohan (zespół odpowiedzialny za wejście produktu na rynek) oraz John (menedżer produktu w SpaceX, odpowiedzialny za wersję enterprise).
  2. Główna teza: Grokbot to nie chatbot i nie klasyczny agent, lecz „członek zespołu” oparty na AI, który prowadzi całe procesy od początku do końca i włącza ludzi tylko wtedy, gdy potrzebuje decyzji.
  3. Przykłady z praktyki: bot sprzedażowy prowadzący leady od researchu po briefing dla handlowca oraz wewnętrzny supportbot — dzięki niemu zespół obsługi skalował się o 175% bez zatrudnień, przy 2 mln dolarów oszczędności i bez pracy inżynierskiej.
  4. Architektura: wszystko działa w chmurze; każdy użytkownik dostaje własną maszynę wirtualną z Linuksem (hostowaną w USA), a połączenia z narzędziami idą przez MCP, przy zerowej retencji danych u dostawców modeli.
  5. Kontrola działań botów sprowadza się do trzech decyzji: dozwolone wtyczki i serwery MCP, dostęp do plików lokalnych oraz sieciowa lista dozwolonych adresów; konfiguracja MCP z Cursora działa od razu.
  6. Warstwa reguł: zespołowe reguły wstrzykiwane do promptu systemowego, model przeglądowy auto review oceniający każdą akcję, obowiązkowe zatwierdzanie wrażliwych działań oraz — nowość — hooki bezpieczeństwa kierujące prompty do własnego endpointu (np. Palo Alto Networks, Zscaler).
  7. Bezpieczeństwo danych: firmowe skrypty startowe na maszynach botów (VPN, EDR typu CrowdStrike), sekrety niedostępne dla botów, masowe aktualizowanie i czyszczenie maszyn, retencja (np. usuwanie po 30 dniach bezczynności) oraz eksport akcji botów do OpenTelemetry.
  8. Rekomendowane wdrożenie: start od małej grupy pilotażowej przy konfiguracji polityk, dopiero potem otwarcie dostępu; posiadacze licencji Cursora mają dostęp automatycznie, a w planach team Grokbit jest włączony domyślnie.
  9. Boty zespołowe: jeden wspólny bot (narzędzia + umiejętności + instrukcje) zamiast stu prywatnych kopii tej samej automatyzacji, z rozdzieloną pamięcią — wspólną dla rozmów w kanałach i osobistą dla rozmów prywatnych.
  10. Analityka i koszty: taksonomia zadań, trzy poziomy automatyzacji, wydatki per zespół i użytkownik z limitami; w części Q&A — pamięć kontekstu, wsparcie Microsoft Teams, self-hosting, relacja z Cursor i przypadki użycia poza inżynierią.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Wdrażaj wokół pełnych procesów, nie pojedynczych pytań

Na czym polega: Grokbot jest pozycjonowany jako skok o klasę wyżej względem chatbotów i agentów: użytkownik nie zleca zadania i nie czeka na wynik, tylko bot prowadzi cały proces — od researchu, przez wykonanie, po raport — i włącza człowieka tam, gdzie potrzebna jest decyzja.

Jak stosować: przy planowaniu wdrożenia nie pytaj „o co ludzie będą pytać bota”, tylko „jaki proces możemy mu oddać w całości” — np. obsługę leadów od kwalifikacji po briefing dla handlowca.

Na co uważać: mierzenie produktu wskaźnikami chatbota (liczba rozmów, jakość odpowiedzi) nie pokaże jego wartości; właściwą miarą jest czas całego procesu — np. dni pracy na lead zamienione na minuty.

2.Zanim puścisz pierwszego użytkownika, ustaw trzy bariery

Na czym polega: pierwszym krokiem administratora są trzy decyzje: jakich wtyczek i serwerów MCP mogą używać boty, czy mogą działać na lokalnym komputerze użytkownika oraz do jakich adresów sieciowych sięgać.

Jak stosować: skonfiguruj te ograniczenia na grupie pilotażowej, zanim otworzysz dostęp szerzej — wtedy obowiązują wszystkie boty w organizacji od pierwszego dnia.

Na co uważać: sieciowa lista dozwolonych adresów obejmuje nie tylko przeglądarkę maszyny bota, ale też wywołania narzędzi MCP — trzeba ją zaprojektować całościowo, a nie tylko dla „surfowania po sieci”.

3.Konfiguracja MCP z Cursora działa od razu — ale zawęź ją per narzędzie

Na czym polega: jeśli firma używa Cursora, zdefiniowane tam wtyczki i własne serwery MCP są dostępne w Grokbot bez dodatkowej konfiguracji; dodatkowo można wejść w każdy serwer i określić, które konkretnie narzędzia są dozwolone.

Jak stosować: przejrzyj integracje pod kątem operacji destrukcyjnych — przykład z webinaru: wyłączenie narzędzi usuwających pliki w MCP Google Drive.

Na co uważać: przeniesienie konfiguracji bez audytu uprawnień przenosi zbyt szerokie zgody z narzędzia dla programistów w ręce botów używanych przez cały zespół.

4.Reguły zespołowe trafiają do promptu systemowego każdego bota

Na czym polega: administrator definiuje reguły obowiązujące wszystkie boty (przykład z webinaru: „nigdy nie wysyłaj maila na adres zewnętrzny bez zgody użytkownika”) — są wstrzykiwane do promptu systemowego, więc zawsze obecne w kontekście. Uzupełnia je model przeglądowy auto review oceniający każdą akcję; wszystkie wrażliwe działania wymagają zatwierdzenia przez człowieka.

Jak stosować: formułuj reguły jako jednoznaczne zakazy i wymogi, a w auto review zdecyduj, które akcje przechodzą automatycznie, a przy których bot zawsze pyta użytkownika.

Na co uważać: reguły promptowe to „miękka” warstwa — krytyczne ograniczenia warto dodatkowo spiąć auto review lub hookami, zamiast polegać wyłącznie na instrukcji.

5.Hooki bezpieczeństwa pozwalają podpiąć własną politykę przed modelem

Na czym polega: nowa funkcja (wczesny dostęp) kieruje każdy prompt użytkownika do własnego endpointu — typowo oprogramowania bezpieczeństwa typu Palo Alto Networks czy Zscaler — które zwraca decyzję „zezwól” albo „odmów”, zanim cokolwiek trafi do dostawcy modelu. Można łączyć reguły deterministyczne (np. wyrażenia regularne) z własnym modelem oceniającym.

Jak stosować: jeśli firma ma politykę DLP lub filtrowania treści, to naturalne miejsce integracji; włączenie wymaga zgłoszenia do opiekuna konta.

Na co uważać: to dodatkowy punkt kontrolny między użytkownikiem a modelem — trzeba zagwarantować jego dostępność i przemyśleć zachowanie systemu przy jego awarii.

6.Maszyny botów da się objąć firmowym reżimem bezpieczeństwa

Na czym polega: każdy użytkownik ma własną maszynę wirtualną z Linuksem, na której bot pracuje jak na zwykłym komputerze. Administrator definiuje skrypty startowe uruchamiane przy każdym boocie (np. instalacja VPN lub EDR typu CrowdStrike) oraz sekrety konfiguracyjne — nigdy niedostępne dla botów. Maszyny można masowo aktualizować, odtwarzać i czyścić, a polityka retencji może je usuwać np. po 30 dniach bezczynności.

Jak stosować: skrypty startowe sprawiają, że maszyny botów podlegają tym samym wymogom bezpieczeństwa co laptopy pracowników; operacje masowe przydają się po każdej zmianie konfiguracji.

Na co uważać: maszyny hostowane są w USA — przy wymogach dotyczących lokalizacji danych (compliance) trzeba to uwzględnić we wdrożeniu.

7.Logi do OpenTelemetry i admin API pozwalają zautomatyzować nadzór

Na czym polega: poza logami audytowymi działań ludzi Grokbot umożliwia eksport wszystkich akcji botów — promptów, odpowiedzi i wywołań MCP — do własnego kolektora OpenTelemetry; admin API pozwala wykonywać operacje programistycznie.

Jak stosować: podłącz eksport do istniejącego monitoringu firmy; da się zbudować pętlę automatyzacji — np. wykrycie określonej akcji w logach uruchamia czyszczenie danej maszyny.

Na co uważać: pełny zapis promptów i odpowiedzi to dane wrażliwe — miejsce ich przechowywania i krąg osób z dostępem również muszą być objęte polityką.

8.Wdrażaj etapami: pilotaż przy politykach, potem cała firma

Na czym polega: u klientów z planem team Grokbot jest włączony domyślnie, a w wersji enterprise włącza go ręcznie administrator. Dostęp można ograniczyć do wybranych grup (SCIM lub własna grupa pilotażowa), a każdy posiadacz licencji Cursora uzyskuje dostęp automatycznie.

Jak stosować: barierki i polityki bezpieczeństwa ustawiaj na małej grupie, dopiero potem przydziel licencje szerszej części organizacji i roześlij zaproszenia — wspólny link (np. na Slacku) albo maile.

Na co uważać: jeśli macie plan team, część osób może już mieć dostęp „z automatu” — zweryfikuj to przed wprowadzeniem polityk, żeby nie konfigurować ich w ciemno.

9.Jeden zespół, jeden bot — zamiast stu kopii tej samej automatyzacji

Na czym polega: zamiast stu osób budujących u siebie identyczną automatyzację, lider funkcyjny tworzy jednego bota zespołowego (dostęp do narzędzi + umiejętności + instrukcje) i udostępnia go całej organizacji lub wybranym grupom; można go ustawić jako domyślny dla działu. Pamięć jest rozdzielona: rozmowy w kanałach Slacka zasila pamięć wspólną, rozmowy prywatne — osobistą. Domyślnie bot korzysta z osobistych konektorów użytkownika, więc kontrola nad uprawnieniami nie umyka.

Jak stosować: wybierz proces powtarzalny w skali działu (np. bot handlowy dla sprzedaży), wskaż jednego właściciela i ewentualnych menedżerów bota odpowiedzialnych za instrukcje i narzędzia.

Na co uważać: pamięć wspólna rośnie z każdą rozmową w kanale — przy informacjach wrażliwych przemyśl, co naprawdę powinno trafiać do wątku publicznego.

10.Największa wartość poza inżynierią — tam szukaj przypadków użycia

Na czym polega: według prowadzących najczęstsze i najcenniejsze zastosowania to sprzedaż, marketing, operacje, finanse, HR, IT i rekrutacja; w inżynierii skok wartości jest mniejszy, bo dobre agentowe narzędzia do kodu już istnieją. Bonusem jest integracja: Grokbot potrafi uruchamiać i nadzorować agentów Claude w Cursorze, podając linki do pull requestów oraz podglądy ich pracy.

Jak stosować: listę kandydatów do automatyzacji buduj od działów nieinżynierskich — to tam narzędzia dotąd nie oferowały poziomu „wirtualnego kolegi z zespołu”.

Na co uważać: nie tłumacz wartości liczbą PR-ów czy zadań programistycznych; miernikiem są efekty biznesowe, np. liczba obsłużonych zgłoszeń albo czas reakcji na lead.

Redakcyjne tłumaczenie

Wstęp: dla kogo jest to spotkanie

Rohan: Nazywam się Rohan i pracuję w zespole, który zajmuje się wprowadzaniem Grokbota na rynek — pomagamy firmom wdrożyć go u siebie i sprawić, żeby ludzie faktycznie z niego korzystali.

John: A ja jestem John, menedżerem produktu w SpaceX. Odpowiadam za Grokbota w wersji dla przedsiębiorstw, więc na co dzień dużo rozmawiam z administratorami i zespołami bezpieczeństwa w dużych firmach. Chętnie pokażę, co zbudowaliśmy wspólnie z naszymi klientami.

Rohan: Kilka uwag organizacyjnych: spotkanie nagrywamy, pytania można zadawać przez funkcję Q&A. Głównie poprowadzi John, ja będę przekazywał pytania — na końcu znajdziemy czas na dyskusję, więc śmiało piszcie. Nagranie i materiały udostępnimy po spotkaniu.

Spotkanie jest skierowane do administratorów Grokbota. Przejdziemy przez to, o czym trzeba pomyśleć, wdrażając Grokbota w organizacji: jak ustawić barierki dla działań botów, jak zabezpieczyć dane, jak — według naszych rekomendacji — wprowadzać produkt do zespołu (w tym jak tworzyć boty współdzielone, działające w ramach całej drużyny), a na końcu jak rozumieć użycie i co napędza koszty. Na dobry początek Rohan w dwóch słowach wyjaśni, czym w ogóle jest Grokbot.

Od chatbota do wirtualnego kolegi z zespołu

Rohan: Zacznę od ustalenia wspólnego punktu odniesienia. W 2022 roku ruszyła fala chatbotów — wkrótce po ChatGPT pojawił się Claude. Wspólny mianownik: rozmowa w stylu pytanie–odpowiedź. Potem przyszli agenci — tu dziś jest większość produktów. Można pogadać, ale też zlecić zadanie: wysłać maila, zajrzeć do dokumentów w Notion, napisać na Slacku. Takie zachowanie agentowe jest bardzo rozpowszechnione w zastosowaniach inżynierskich, a pozostałe dziedziny dopiero nadrabiają zaległości.

Grokbot to w naszym rozumieniu skok o klasę wyżej. Zamiast zlecać zadanie i czekać, dostajesz kolegę z zespołu opartego na AI, który prowadzi pracę — twoją albo całej drużyny — od początku do końca (end-to-end) i włącza cię, kiedy potrzebuje decyzji. To zmiana paradygmatu: nie kolejna wersja chatbota ani klasycznego agenta, tylko myślenie o Grokbot jak o członku zespołu, który doprowadza pracę do końca.

Przypadek pierwszy: leady sprzedażowe

Pokażę dwa szybkie przykłady, zaczynając od zastosowań pozainżynierskich — zwłaszcza obsługi przychodzących leadów. Dziś osoba odpowiedzialna za rozwój sprzedaży (SDR) bada firmę, sprawdza właściciela konta, kwalifikuje lead względem profilu idealnego klienta, pisze odpowiedź — czasem z pomocą chatbota — umawia spotkanie i przekazuje je handlowcowi, który przed rozmową skleja materiały. Z Grokbotem tworzysz jednego bota, nazwijmy go leadbotem, który robi to wszystko: podchwytuje lead, bada go, punktuje według profilu idealnego klienta, szkicuje spersonalizowaną odpowiedź, przygotowuje krótki brief i sam, z własnej inicjatywy wysyła go handlowcowi. Działa nieprzerwanie, prowadzi proces od deski do deski i wciąga człowieka tylko wtedy, gdy to konieczne.

Co to oznacza w praktyce? Dziś obsługa jednego leadu potrafi zająć SDR-owi dni. Z Grokbotem to kwestia minut — a handlowiec po prostu zatwierdza.

Przypadek drugi: wewnętrzny supportbot

To był wąski przykład. Wewnętrznie poszliśmy o krok dalej i mocno uogólniliśmy ten schemat: zbudowaliśmy własnego supportbota. Zaciąga dane z Plane, Linear, Datadog i naszych pozostałych systemów, a zadań wykonuje wiele naraz: bada zgłoszenia, pilnuje kolejki, czyta sygnały z X, robi przeglądy jakości, a nawet podejmuje pierwsze podejście do rozwiązania problemu — i eskaluje do człowieka, kiedy trzeba, wciągając odpowiednie osoby. Efekt? Skalowaliśmy zespół o 175% bez ani jednego nowego etatu i zaoszczędziliśmy 2 miliony dolarów na pensjach. Co najważniejsze: nie było przy tym żadnej pracy inżynierskiej — wszystko zbudowaliśmy w samej platformie, samą konfiguracją botów. Dlatego tak bardzo zachęcamy do myślenia w kategoriach pełnych procesów.

Wspólna praca na botach

I jeszcze jeden poziom wyżej: pełne procesy w trybie wieloosobowym. Po lewej stronie slajdu — jak to zwykle wygląda w marketingu: PM pisze brief, przekazuje go marketerowi, ten szkicuje plan, dalej content manager, projektant… Mnóstwo przekazywania z rąk do rąk. Po prawej — wątek na Slacku. Maya, menedżerka marketingu, otwiera wątek: premiera aplikacji na iOS przesunęła się na czwartek. Priya z działu produktu przywołuje Launchbota: „Możesz przeprowadzić to od początku do końca?”. Launchbot przygotowuje trzy artefakty. Jordan, projektant, prosi o wersję dostosowaną do klientów biznesowych — Launchbot poprawia. Maya zatwierdza, Jordan zatwierdza, bot wpisuje publikację w harmonogram, a dwa dni później sam wraca z raportem: 42 tysiące wyświetleń. To właśnie nasza wizja Grokbota: kilka osób współpracujących przez bota. Działa w Slacku, a wkrótce także w Microsoft Teams.

Interfejs Grokbota

Skoro nie robimy dziś pełnego demo, pokażę chociaż zrzut ekranu. Po prawej stronie tworzy się boty do różnych zadań i pisze do nich jak do kolegów z zespołu — a kluczowe jest to, że boty pamiętają kontekst. Dwie rzeczy zasługują na szczególną uwagę. Pierwsza: możliwość udostępniania botów zespołom — wspólne konteksty, wspólna pamięć, wszyscy mogą z botem rozmawiać, a konfigurację ustawia lider lub administrator. Druga: automatyzacje i rutyny — bez nich nie da się myśleć o pełnych procesach end-to-end. Przekazuję约翰owi… to znaczy Johnowi, który oprowadzi nas po mechanizmach administracyjnych.

Architektura: co się dzieje pod spodem

John: Zanim przejdę do kontroli administracyjnych i bezpieczeństwa, pokrótce o architekturze Grokbota. Są trzy główne elementy. Po lewej: klient — aplikacja na komputer albo telefon. To tzw. thin client, czyli lekka aplikacja, która sama prawie niczego nie liczy: Grokbot działa w całości w chmurze i nic nie dzieje się lokalnie na maszynie użytkownika. To właśnie tu administrator definiuje polityki zespołu, o których opowiem dalej.

W chmurze każdy użytkownik dostaje własną maszynę wirtualną, z której korzystają jego boty. To komputer z Linuksem, który potrafi przeglądać internet i uruchamiać aplikacje — jednym słowem pracować jak zwykły komputer. Maszyna stoi w USA, a polityki sieciowe pozwalają określić, jakie adresy są z niej osiągalne — typowo strony internetowe i aplikacje SaaS.

Trzeci element to agent harness, główna pętla agenta. Odwołuje się do dostawców modeli — u nich obowiązuje zero retencji danych — a także łączy się z serwerami MCP, czyli najczęściej narzędziami, których już używacie: Slack, Gmail, GitHub i tak dalej. Można zdefiniować, które wywołania narzędzi są dozwolone, a nad każdym działaniem bota czuwa dodatkowo warstwa auto review. Do reguł wrócę za chwilę. Najważniejsze, co trzeba zapamiętać: Grokbot działa wyłącznie w chmurze, a boty dostają do dyspozycji maszynę i serwery MCP.

(Informacja dodatkowa: MCP — Model Context Protocol, otwarty standard łączenia modeli językowych z zewnętrznymi narzędziami i danymi.)

Barierki bezpieczeństwa: co botom wolno

Pierwsza rzecz, jaką robi się po rozpoczęciu wdrażania Grokbota, to ustawienie barier dla działań botów. Trzy decyzje: jakie wtyczki i serwery MCP mogą używać boty; czy bot może pracować na lokalnym komputerze użytkownika; jakie adresy sieciowe są osiągalne.

Jeśli używacie Cursora, zapewne macie już zdefiniowane wtyczki i własne serwery MCP dla zespołu — w Grokbot są dostępne bez żadnej dodatkowej konfiguracji. Do tego można wejść w poszczególny serwer i określić dozwolone narzędzia — na przykład wyłączyć destrukcyjne operacje w MCP Google Drive.

Co do pracy lokalnej: dostęp bota do plików na komputerze bywa użyteczny, ale jeśli nie chcecie, żeby użytkownicy z niego korzystali, można go wyłączyć.

Na koniec sieć: maszyna bota ma przeglądarkę i terminal, więc można ustawić listę dozwolonych adresów — i obowiązują ją wszystkie połączenia sieciowe z tej maszyny oraz wywołania narzędzi MCP.

Reguły, auto review i hooki bezpieczeństwa

Drugi zestaw mechanizmów kontroli to reguły i hooki. Kluczowa informacja: każda wrażliwa akcja wymaga zatwierdzenia użytkownika. Ocenia ją automatycznie model przeglądowy, który nazywamy auto review — zawsze działa dla wszystkich botów, a wy możecie dokładając własne reguły i konfigurację.

Pierwsza kategoria to reguły zespołowe: obowiązują wszystkie boty w organizacji i są wstrzykiwane do promptu systemowego, więc zawsze są w kontekście. Przykład: „Nigdy nie wysyłaj wiadomości do firmy zewnętrznej bez zgody użytkownika”.

Druga kategoria to reguły auto review. Administrator może objąć przeglądem wszystkie akcje botów — odpowiedzi, wywołania MCP i działania na maszynie — i wybrać, które akcje mają przechodzić automatycznie (czyli politykę rozluźnić), a przy których bot zawsze ma najpierw zapytać użytkownika.

Najświeższa rzecz to inference hooks — hooki wnioskowania. Pozwalają podpiąć Grokbota do waszego własnego endpointu, typowo oprogramowania bezpieczeństwa, jak Palo Alto Networks czy Zscaler. Każdy prompt użytkownika trafia najpierw do was — dostajecie decyzję „zezwól” albo „odmów” — i dopiero potem cokolwiek idzie do dostawcy modelu. Można więc stosować reguły deterministyczne, na przykład wyrażenia regularne, i dodatkowo uruchamiać własne modele oceniające po waszej stronie. Funkcja jest na etapie wczesnego dostępu — chętnie ją włączymy, wystarczy zgłosić się do opiekuna konta.

Bezpieczeństwo danych

Drugi wielki temat: jak zabezpieczyć dane. Maszyna bota to linuksowa maszyna wirtualna, którą można wyposażyć we własne narzędzia — na przykład firmowy VPN albo oprogramowanie EDR w stylu CrowdStrike. Służą do tego skrypty startowe zespołu, uruchamiane przy każdym boocie maszyny; typowe zastosowanie to instalacja VPN lub EDR. Można też zdefiniować sekrety używane do konfiguracji tych narzędzi — i nigdy nie są one udostępniane botom.

Maszynami botów można zarządzać masowo: wymusić aktualizację, odtworzyć albo wyczyścić — także hurtowo. Jeśli na przykład dodacie nowy skrypt, możecie jednym ruchem zrestartować wszystkie maszyny w organizacji. Jak już wspomniałem, pełną kontrolę nad tym, do jakich adresów maszyny sięgają, dają mechanizmy sieciowe.

Nadzór: logi, eksporty, admin API

Po stronie bezpieczeństwa dostępny jest też monitoring działań botów. Logi audytowe obejmują wszystkie akcje ludzi wykonane w produkcie. Można dodatkowo skonfigurować eksporty OTel, które obejmą wszystkie akcje botów — prompty, odpowiedzi i wywołania MCP — wysyłane do waszego kolektora OpenTelemetry. Maszynami w organizacji zarządzi się łatwo, a polityki retencji pozwalają na przykład automatycznie usuwać je po 30 dniach bezczynności. Wreszcie admin API, za pomocą którego te operacje wykonuje się programistycznie — otwiera to ciekawe możliwości: eksport logów może wypatrywać określonych akcji, a wykrycie uruchamia akcję porządkującą na danej maszynie.

(Informacja dodatkowa: OpenTelemetry to otwarty standard zbierania logów i metryk; „kolektor” to serwer, do którego te dane spływają.)

Jak wdrażać Grokbota w organizacji

Jak więc wprowadzać Grokbota do zespołu? U klientów z planem team produkt jest włączony domyślnie; w wersji enterprise administrator włącza go ręcznie. Wdrożyliśmy ostatnio sporo firm i dobrze sprawdza się następujący schemat: zacznijcie od mniejszej grupy, dopiero konfigurując barierki i polityki bezpieczeństwa. Dostęp można ograniczyć do wybranych grup — korzystając z istniejących grup SCIM albo tworząc grupę pilotażową z garstką osób — i dopiero potem otworzyć go dla całej firmy.

Jeśli chodzi o dostęp: każdy użytkownik z licencją Cursora ma automatycznie dostęp również do Grokbota. Żeby zaprosić szerszą część organizacji, trzeba przydzielić tym osobom miejsca. A kiedy to zrobicie, można zaprosić cały zespół — na dwa sposoby: udostępnić wspólny link (np. na Slacku), który działa dla wszystkich, albo rozesłać zaproszenia mailem do nowych użytkowników.

(Informacja dodatkowa: SCIM to standard automatycznej synchronizacji kont i grup między systemami — np. między firmowym dostawcą tożsamości a aplikacją.)

Boty zespołowe

Ostatni wątek wdrożeniowy: boty zespołowe, które ułatwiają skalowanie automatyzacji w organizacji. Logika jest prosta. Zamiast stu osób budujących u siebie tę samą automatyzację, każda na własnym bocie — tworzycie jednego wspólnego bota, z którego korzysta sto osób, a jedna osoba nad nim czuwa i dba, żeby działał bez zarzutu.

W praktyce partnerujemy przy tym zwykle z liderem funkcyjnym — Rohan wspomniał o obsłudze klienta i sprzedaży, gdzie widzieliśmy mnóstwo ciekawych zastosowań. To właśnie lider buduje bota zespołowego: połączenie dostępu do narzędzi, umiejętności i instrukcji. Gotowego bota udostępnia się całej organizacji albo wybranym osobom, a administrator może dodatkowo wskazać go jako domyślnego dla całej firmy lub grupy. Przykład: jeśli tworzycie dealbota przydatnego handlowcom, możecie automatycznie udostępnić go działowi sprzedaży — i mieć pewność, że każdy nowy użytkownik z tego zespołu dostanie go w pakiecie na starcie.

Analityka użycia i koszty

Ostatni blok: jak rozumieć użycie i koszty. Są dwa zestawy funkcji. Pierwszy to analiza użycia: sprawdzamy wszystkie zadania, do których zespół wykorzystuje Grokbota, i porządkujemy je według stałej taksonomii. Dla zobrazowania — u nas wewnętrznie sprzedaż jest najaktywniejszym użytkownikiem produktu, a inżynieria i produkt plasują się tuż za nią. Mierzymy też stopień automatyzacji zadań: od braku automatyzacji (styl chatbota — pytasz, on odpowiada), przez półautomatyzację (człowiek zatwierdza akcję, zanim bot ją wykona), po pełną automatyzację — proces, który chodzi całą dobę, siedem dni w tygodniu.

Po stronie wydatków: koszty Grokbota można śledzić per zespół, grupa i użytkownik, a limity ustawiać zarówno dla zespołów, jak i pojedynczych osób — w tym osobne dla użycia na żądanie. Rozwijamy też kolejne sposoby pokazywania użycia i zwrotu z inwestycji: na przykład zaoszczędzone godziny zestawione z wydatkami. To obszar, który ciągle doskonalimy, bo jest naprawdę krytyczny.

Rohan: Dla potwierdzenia: mamy już wewnętrznie prototyp, który wylicza czas zaoszczędzony dzięki Grokbotowi i zestawia go z poniesionymi wydatkami. Pracujemy nad tym obecnie z partnerami projektowymi.

John: Zgadza się.

Pytania i odpowiedzi

Rohan: Przejdźmy do pytań. Kilka wraca bardzo często, więc od nich zacznę.

Pytanie: Jak działa pamięć botów? Co się dzieje, gdy okno kontekstu się „spuchnie”?

John: Modele mają ograniczone okno kontekstu, więc stosujemy kompaktowanie: kontekst użytkownika oraz akcje wykonane przez bota zamieniamy w pamięć. Wyobraźcie sobie zbiór wydarzeń i faktów, których bot dowiedział się o tobie — rośnie on z czasem. Ale jako użytkownik nie musisz w ogóle myśleć o zarządzaniu kontekstem, i to jedna z najprzyjemniejszych cech tego produktu. Sam mam boty, z którymi pracuję codziennie od początku lipca — ani razu nie zapomniały faktów ani nie zaczęły działać inaczej, niż im wcześniej ustaliłem.

Pytanie: A jak wygląda pamięć w botach zespołowych?

John: Są dwie pamięci: wspólna i osobista. Bota zespołowego można dodać do kanału na Slacku — wtedy rozmawia z nim kilka osób naraz i ta część trafia do pamięci wspólnej. Można też pisać do niego w wiadomości prywatnej albo w samej aplikacji Grokbota — i to zasila pamięć osobistą. Granice między członkami zespołu są więc wyraźnie odseparowane.

Rohan: Do botów zespołowych i współdzielonych jest bardzo dużo pytań — w tym obszarze wprowadzamy całą serię zmian, więcej już w przyszłym tygodniu. Na razie jednak: jak działa uprawnianie w botach zespołowych? Można dodawać kolejne osoby, w tym konta serwisowe?

John: Boty zespołowe można konfigurować z kontami serwisowymi, ale domyślnie korzystają z osobistych konektorów użytkownika, który właśnie z nimi rozmawia. Dzięki temu nie tracicie kontroli nad tym, co dana osoba może kazać botowi zrobić. Pełną kontrolę macie też nad tym, kto w ogóle może rozmawiać z danym botem. Można dodatkowo mianować menedżerów bota — żeby kilka osób mogło konfigurować umiejętności, zmieniać instrukcje czy podpinać kolejne narzędzia.

Pytanie: Kiedy wsparcie dla Microsoft Teams?

Rohan: W drodze. Testujemy wersję beta wewnętrznie. Nie podam konkretnej daty, ale realnie — najbliższe tygodnie.

Pytanie: Czym różnią się konta osobiste od zespołowych?

John: W panelu bocznym Grokbota masz jednocześnie boty osobiste i zespołowe. Różnica jest w gruncie rzeczy jedna: bot zespołowy jest współdzielony z wieloma osobami.

Pytanie: Czy analiza wydatków przypisuje pozycje użycia do konkretnych botów?

John: Dziś jeszcze nie, ale właśnie nad tym pracujemy — więcej informacji wkrótce.

Pytanie: Co się stanie po osiągnięciu limitu wydatków?

Rohan: Grokbot przechodzi wtedy na wolniejszą pulę albo przestaje być dostępny. Jeśli jesteś administratorem, możesz po prostu podnieść przydział środków; jeśli nie — trzeba zwrócić się do administratora. Limit jest zwykle miesięczny, więc alternatywą jest odczekanie do końca miesiąca, ale ja po prostu polecam iść prosto do administratora.

John: Dużo zależy od konfiguracji: czy administrator włączył wydatki na żądanie i jakie ustawił miesięczne limity. Czyli — jak to zwykle bywa — od ustawień w waszej organizacji.

Pytanie: A co z wariantem self-hosted — botami działającymi na własnej infrastrukturze?

Rohan: Wiem, że temat wraca bardzo często. Nie mamy terminu, ale John opowie o naszym podejściu.

John: Nasze stanowisko jest takie: Grokbot musi dać się wdrożyć w każdej firmie — także w najbardziej wymagającej pod względem bezpieczeństwa. Właśnie aktywnie pracujemy i rozmawiamy z klientami, żeby dojść do właściwego kształtu opcji wdrożenia.

Pytanie: Jaka jest relacja między Grokbotem a Cursorem?

John: To produkty tej samej firmy, a między nimi powstały naprawdę fajne integracje. Jeśli używacie w Cursorze agentów Claude, możecie po prostu poprosić bota o uruchomienie takiego agenta. Bardzo ciekawy przypadek inżynierski: Grokbot jako przełożony agentów programistycznych — potrafi podać linki do pull requestów oraz podglądy ich pracy, obrazy i wideo.

Rohan: I jeszcze jedna ważna uwaga. W inżynierii widzieliśmy świetne zastosowania Grokbota, ale produkt błyszczy najbardziej poza inżynierią — chcę, żeby to było jasne. Najczęstsze przypadki użycia to sprzedaż, marketing, operacje, finanse, HR, IT, rekrutacja. To jest nasz chleb powszedni. Narzędzia agentowe do kodu już istnieją — Cursor i podobne — więc skok wartości w inżynierii jest mniejszy, choć nadal realny, na przykład przy uruchamianiu chmurowych agentów Cursora. Bardzo zachęcamy, żeby patrzeć właśnie na pozostałe dziedziny: tam dotychczasowe narzędzia nigdy nie oferowały poziomu zachowań agentowych i pracy „jak kolega z zespołu”.

Pytanie: Czy reguły zespołowe można różnicować między działami firmy?

John: Tak — wszystkie mechanizmy, o których mówiłem, da się konfigurować na poziomie grup. Można mieć grupę SCIM zrzeszającą członków konkretnego działu i ustawić dla niej inne reguły niż dla całej organizacji.

Pytanie: Czy jest jakaś biblioteka z aktualnymi tutorialami, filmami i odpowiedziami?

Rohan: Tak. Online znajdziecie nasze przewodniki ze znacznie szerszym opisem, a przypadki użycia — pod adresem x.ai/bot. To tam zbieramy wszystkie te materiały i gorąco zachęcam do korzystania. Będziemy dodawać kolejne poradniki, przewodniki i szablony botów, które pomogą Wam zacząć. Myślę, że to dobry akcent na koniec: rozwijamy produkt bardzo szybko, więc zaglądajcie na kolejne warsztaty i wypatrujcie nowości. Jeśli jeszcze nie próbowaliście Grokbota — spróbujcie, a potem przynieście go do swoich firm. Dziękujemy wszystkim za udział!

John: Dzięki!