O czym jest ten film
- Grok Bot to według autora najprostszy dziś sposób na postawienie zespołu wyspecjalizowanych agentów AI działających w chmurze.
- Wszystko synchronizuje się między komputerem a telefonem, a agenci działają non stop — także przy wyłączonym sprzęcie użytkownika.
- Każdy agent dostaje własny komputer w chmurze z przeglądarką, terminalem i menedżerem plików, do którego można się zalogować i który zapamiętuje sesje.
- Funkcja „teach a task” pozwala nagrać własne działania na komputerze agenta i zamienić je automatycznie w powtarzalną umiejętność (skill).
- Agenci mają nazwę, tytuł i opis — na podstawie opisu delegują sobie zadania nawzajem, dokładnie tak, jak wybierają skille.
- Rutyny można odpalać z harmonogramu (np. poranny briefing o 7:00) albo z triggerów: wiadomość na Slacku, zdarzenie na GitHubie, wiadomość w Teams.
- Autor pokazuje na żywo budowę trzech agentów: asystenta wykonawczego, porannego planisty i agenta od Slacka/sponsoringów.
- Skille i wtyczki są współdzielone przez wszystkich agentów, ale sesje komputerowe i opisy są indywidualne.
- Agent po wykonaniu skilla sam ocenił, co poszło nie tak, i poprawił własną instrukcję — bez proszenia.
- Ograniczenia: wymagany plan Cursor Ultra, model od Groka, wąska lista triggerów oraz ostrzeżenie przed budowaniem automatyzacji, których się nie potrzebuje.
Redakcyjne tłumaczenie
Czym jest Grok Bot
Dostaliśmy właśnie Grok Bota — prawdopodobnie najprostszy sposób, jaki znalazłem, żeby postawić zespoły różnych agentów AI, z których można korzystać zarówno z telefonu, jak i z komputera. Wszystko pozostaje zsynchronizowane, a agenci są zawsze włączeni. To trochę tak, jakby mieć Claude Code, Codeksa i agenta Hermesa naraz w kieszeni. Konfiguracja jest banalnie prosta, więc przejdźmy od razu do rzeczy.
Wystarczy wpisać w Google „Grok Bot”, kliknąć w link i pobrać aplikację na Windowsa, na Apple’a i na iOS-a, żeby wszystko trzymało się razem. Zastrzeżenie: żeby to wypróbować, trzeba mieć plan Cursor Ultra. Wykupujesz Ultra, pobierasz Grok Bota i możesz się bawić.
(Informacja dodatkowa: transkrypcja automatyczna miesza tu nazwy — narzędzie jest dystrybuowane w ramach ekosystemu Cursora, stąd wymóg planu Ultra i późniejsze odwołania do aplikacji Slacka o nazwie „cursor”.)
Pierwsze uruchomienie i układ aplikacji
Po otwarciu aplikacji przechodzisz krótkie wprowadzenie: „Cześć, to jest Grok Bot. Stwórz swojego pierwszego bota”. Nadajesz mu nazwę, kolor, kształt i tak dalej. Kiedy masz już kilku agentów, całość wygląda niemal jak kanał w iMessage albo w Telegramie — z lewej lista botów, między którymi się przełączasz.
Po prawej stronie masz ustawienia: nazwa, tytuł, opis, a także podgląd komputerów agentów. Widać tutaj, że Klaus — mój agent — siedzi w mojej społeczności na Skoolu, zalogowany jako ja, i przechodzi przez posty, lajkując te, które kazałem mu polajkować. Steruje tą przeglądarką, ale ja też mogę. Jeśli chcę wejść na przykład na YouTube’a, mogę zalogować się jako ja i ta sesja zostanie zapamiętana. Nawet każe mi rozwiązać captchę — no proszę, naprawdę nie chce mnie wpuścić. No dobrze, w końcu jestem na YouTubie.
Można też otworzyć menedżer plików albo terminal. Jest przycisk „teach a task”, pod którym nagrywam siebie wykonującego jakąś czynność, a Grok Bot automatycznie zamienia to w skill. Dokładnie tak powstała ta umiejętność, którą mam już zapisaną jako „post 7-day challenge na Skoolu” — agent ją odpalił i wykonał.
Podpiąłem też swoje repozytorium na GitHubie, bo tam buduję swój AI-owy system operacyjny. Jeśli budujecie własny drugi mózg albo system operacyjny dla siebie, możecie go wciągnąć do Grok Bota i wszyscy agenci automatycznie dostaną ten kontekst — nie zaczynacie od zera. A jeśli takiego systemu nie macie, to też nie problem, bo przy tworzeniu nowego agenta narzędzie samo przeprowadza onboarding: zadaje pytania i pyta wprost, co ma dla ciebie robić.
Specjalizacja i delegowanie między agentami
Mam tu Klausa — mojego asystenta wykonawczego — i deva, czyli inżyniera AI. Fajne jest to, że jeśli poproszę Klausa o pomoc przy zbudowaniu produktu, Klaus sam oddeleguje pracę do deva, bo wie, czym się dev zajmuje.
Zasada jest prosta: każdemu agentowi dajesz nazwę, tytuł i opis. Opis działa niemal identycznie jak opisy skilli. Agent myśli: „Dobrze, mam takie zadanie. Sprawdzę wszystkich innych agentów i zobaczę, czy czyjś opis pasuje do tego zadania. Jeśli tak — wyślę mu wiadomość, a on mi pomoże”. Dzięki temu każdy agent, którego zbudujesz, może być bardzo wyspecjalizowany.
Budowa agenta od porannego briefingu
Klikam „nowy czat” — mogę zacząć rozmowę z jednym z botów albo stworzyć własnego, nowego. Pyta mnie: „Miło cię poznać. Do czego mam ci służyć? Research i pisanie, coś konkretnego, praca na co dzień?”. Zróbmy z tego mojego porannego planistę: chcę, żebyś codziennie rano pomagał mi zaplanować dzień i przeglądał to, co mam do zrobienia.
Agent odpowiada: „Sprawdzam, co jest już podłączone, żeby wiedzieć, skąd zaciągać zadania”. Jak dotąd podłączyłem tylko GitHuba — a potrzebuję jeszcze Gmaila, Kalendarza Google, Slacka, Google Drive, ClickUpa i całej reszty narzędzi, których używam. To kwestia zwykłego logowania. Co ważne: jeśli podłączysz GitHuba dla jednego agenta, wszyscy pozostali też będą mogli z tego połączenia korzystać. Wtyczki są współdzielone.
Agent zapytał, gdzie mieszkają moje zadania i kalendarz. Odpowiedziałem: Kalendarz Google i Gmail. Zaproponował podłączenie obu — „szybkie logowanie, jednorazowa konfiguracja”. Klikam „tak, podłącz oba”, wyskakuje okienko autoryzacji i loguję się tak jak w każdej innej aplikacji.
Gmail i kalendarz podłączone. Teraz pyta, kiedy poranna rutyna ma się uruchamiać. Domyślnie: poranki w dni robocze, z zaciągnięciem dzisiejszego kalendarza i ważnych rzeczy z Gmaila. Ustawiam siódmą rano.
I tu dochodzimy do sedna: twoi agenci mogą tworzyć rutyny. A ponieważ wszystko dzieje się w chmurze, rutyna wykona się nawet wtedy, gdy mój komputer jest wyłączony i telefon też. Widać tu utworzoną rutynę „poranny plan dnia”, która pojawia się w sekcji agenta. Instrukcja brzmi mniej więcej: zbuduj poranny plan Nate’a i wyślij go na czacie; sprawdź dostępne narzędzia MCP — kalendarz, Gmail; zaciągnij dzisiejsze wydarzenia z kalendarza; wyciągnij z Gmaila rzeczy wymagające działania; napisz krótkie podsumowanie. Oczywiście tę instrukcję można dowolnie doszlifować.
Agent pyta, czy chcę próbkę. Mówię: odpal jedną teraz. To jest właśnie świetne — budowanie automatyzacji i kolejnych agentów staje się banalnie proste.
Ten agent nadal nazywa się „new bot”, więc go nazywam: „Kawa”, tytuł — „mój poranny planista”. A potem trzeba dać agentowi bardzo konkretny jednozdaniowy opis tego, co robi, żeby Klaus, dev albo inny agent wiedział, kiedy go użyć: „Ten agent przegląda mój Gmail i kalendarz, żeby pomóc mi zaplanować dzień w każdy dzień roboczy”. Można też pobawić się wyglądem — zmienić kształt i kolor, wygenerować grafikę z opisu albo wgrać własny obrazek.
I tu rzecz kluczowa: pamiętacie, jak pokazywałem, że Klaus ma własny komputer, otwarty teraz na Skoolu albo na YouTubie? Kawa ma swój własny ekran, dev również. Za każdym razem, gdy budujesz kolejnego agenta, dostaje on własny komputer i może robić na nim swoje rzeczy.
Jak wygląda wynik porannej rutyny
Oto próbka tego, co dostanę jutro rano. Pokazuje mój dzień, pokazuje spotkania, które mam. Pisze: „Oto rzeczy z maila warte działania” — mam coś, na co muszę odpisać, mam rozmowę w czwartek, którą trzeba potwierdzić, mam zaproszenie na czat. Sugeruje: „Wykorzystaj blok 7–9 na zaplanowanie dnia, domknij tę sprawę, przejrzyj te notatki i przygotuj się do rozmowy”. Dalej: „Twoje popołudnie jest mocno zapchane, więc wybierz jedną z tych rzeczy i skróć lunch albo przesuń blok na siłownię”. Powiedziało mi nawet, żebym chronił swój wieczór, bo jutro mam rezerwację na kolację.
To jest naprawdę mocne, bo przecież nic mu nie powiedziałem. Napisałem tylko: pomóż mi zaplanować dzień. A kiedy zacznę na tym iterować — „to mi się podobało, tego nie chcę” — będzie coraz lepszy i coraz mądrzejszy. I pomyślcie, jak szybko poszło zbudowanie całego tego skilla i całej rutyny.
Agent, który sam się poprawił
Wracam na chwilę do Klausa. Kazałem mu wykonać skill, w którym przechodził przez moją darmową społeczność na Skoolu i lajkował posty z mojego siedmiodniowego wyzwania. Zobaczcie, co zrobił po jednym przebiegu. Napisał: „Oto suchy przebieg. Oto trzy posty, które polajkowałem”. A potem dodał: „Zauważyłem coś — nie da się jednoznacznie stwierdzić, czy te posty są już polajkowane, czy nie”. I sam z siebie stwierdził: „W porządku, dodałem do skilla krok »otwórz post przed polajkowaniem«”.
Bez mojej prośby, po wykonaniu skilla, agent dał sam sobie informację zwrotną o tym, co zadziałało, a co nie, i sam się naprawił. Z czasem będzie mądrzejszy przy każdym uruchomieniu skilla — buduje coraz więcej kontekstu i pamięci w miarę tego, jak z nim rozmawiasz i jak więcej razem robicie.
Rutyny na triggerach zamiast na harmonogramie
Rutynę dla Kawy odpaliłem według harmonogramu — dni robocze, siódma rano. Ale można też uruchamiać rzeczy na realnych triggerach: wiadomość na Slacku, zdarzenie na GitHubie, wiadomość w Teams. To są aktualnie dostępne triggery. Dokładnie tak samo jak w n8n miałeś różne triggery Gmaila i tym podobne. Zakładam, że lista będzie się bardzo mocno poszerzać — pewnie dojdą setki triggerów — ale na razie startujemy z tymi sześcioma.
(Informacja dodatkowa: n8n to popularna platforma no-code do budowania automatyzacji przez łączenie węzłów; autor często zestawia z nią nowe narzędzia agentowe.)
Tworzę więc nowego agenta, nazwijmy go moim agentem medialnym. Podłączę go do Slacka, żeby powiadamiał mnie o tym, co dzieje się na kanałach związanych ze sponsoringami, nowymi filmami i nowymi okazjami — całą stroną medialną, którą ogarniam na Slacku z kilkoma zespołami. Piszę mu: będziesz pomagał mi zarządzać mediami, sponsoringami i tym podobnymi rzeczami, wszystko wewnątrz Slacka.
Zauważcie, że stawiam agentów do bardzo, bardzo konkretnych zadań. Nawet na stronie Grok Bota widać ten przekaz: agent powinien wykonywać jedną konkretną robotę. Sales outbound, talent scout, płatne media, zarządzanie wydatkami. Jeśli spróbujesz zrobić jednego megaagenta do wszystkiego, po prostu się pogubi, narosną te wszystkie rutyny i nie będzie tak dobry. Ale jeśli każdy agent robi jedną rzecz naprawdę dobrze, a masz dobre opisy i możliwość rozmowy między agentami, robota i tak zostanie wykonana. To dokładnie ta sama logika, co w Claude Code czy Codeksie: masz głównego orkiestratora, który deleguje pracę do kupy małych subagentów.
Podłączanie Slacka i test triggera
Wyskoczyła karta Slacka, autoryzuję się. Agent pyta, które kanały Slacka ma traktować jako bazę. Odpowiadam pytaniem: jakie kanały w ogóle widzisz i możesz czytać? Bo jeśli jesteś jak ja, siedzisz w wielu workspace’ach i kanałach naraz, więc warto sprawdzić, co realnie widzi.
I proszę — widzi tylko część rzeczy z jednego workspace’u, a ja mam drugi adres e-mail z kolejnymi kanałami. Mówię więc: chcę podłączyć jeszcze jeden. I po prostu pozwala dodać kolejny. Mam teraz połączenie domyślne i drugie, które nazywam „work”, z logowaniem na inne konto, żeby mieć dostęp do innych kanałów. Uwierzytelniłem drugie konto Slacka i teraz Grok Bot widzi zarówno kanały publiczne, jak i te prywatne oraz wiadomości bezpośrednie.
Teraz proszę: pomóż mi ustawić rutynę na triggerze ze Slacka. W domyślnym workspasie, kiedy przyjdzie wiadomość na kanale „YouTube testing Nate”, ma cię to uruchomić i wysłać mi powiadomienie o tym, co się stało. Zobaczmy, czy zrozumie i stworzy w swoich ustawieniach rutynę opartą na triggerze, a nie na czasie.
I gotowe — stworzył rutynę „alerty YouTube testing Nate”. Widać: „kiedy uruchamiać: przy nowych wiadomościach na kanale YouTube testing Nate”. Znalazł właściwy kanał, ustawił właściwy trigger i napisał instrukcję. Zanim to zadziała, jest jeden krok konfiguracyjny: żeby faktycznie się odpaliło, aplikacja musi być w tym kanale, więc trzeba wykonać /invite @cursor. Kopiuję komendę — nasłuch kanałów działa tylko tam, gdzie aplikacja jest obecna. Zapraszam @cursor, dodany.
Piszę więc na kanale: „Wpłynął nowy deal sponsorski na tysiąc milionów miliardów dolarów za film na YouTubie. Firma nazywa się Chipotle”. Wysłane. Sprawdzam Grok Bota — widać animację „bot pracuje”. Nadal nazywa się „new bot”, bo go nie nazwałem, i nie dotykałem niczego poza wysłaniem tej wiadomości na Slacku. I bum: „Nowe na YouTube testing Nate — napisałeś, że wpłynął deal sponsorski od Chipotle na taką a taką kwotę”.
Rutyna działa i powstała błyskawicznie. W n8n zajęłoby mi to może 15 minut. W Claude Code jakieś 7 minut. Tutaj — jakieś 2 minuty i jeden prompt. To jest szaleństwo.
I pamiętajcie o nazwaniu bota. Nazywam go „Kasa”, tytuł: „Slack media”, a opis: ten agent odpowiada za zarządzanie moją komunikacją na Slacku w sprawach mediów i sponsoringów. Jeśli chcecie w opisie odwołać się do skilli albo rutyn, których agent używa, żeby dać więcej kontekstu innym agentom — spokojnie można. Agent nawet to potwierdził: „»Kasa« pasuje, od teraz będę na to odpowiadał”.
Jak działają skille
A co ze skillami? Jeśli wpiszesz ukośnik, możesz uruchamiać skille jak komendy slash. Jedyny, jaki dotąd zbudowaliśmy, to ten od Skoola — wpisuję „skool” i pojawia się „posty 7-day challenge na Skoolu”. Mogę go od razu uruchomić.
Skille działają u wszystkich twoich agentów. Tak samo wtyczki. Natomiast sesje komputerowe są odrębne, tak samo jak opisy agentów.
Agent rozmawiający z agentem
A teraz zobaczcie to. Idę do Klausa — to mój asystent wykonawczy, którego traktuję jako router do pozostałych agentów. Piszę mu: „Zapomniałem, co się dzieje z jednym z naszych ostatnich filmów na YouTubie, możesz to znaleźć gdzieś na kanałach Slacka. Może po prostu odezwij się do Kasy i sprawdź, czy ma jakieś informacje o tym, co dzieje się z naszą rolką o Anthropicu”.
To, co powinno się stać, to mniej więcej: Klaus stwierdza, że jest tylko asystentem wykonawczym, ale widzi, że Kasa jest agentem od mediów na Slacku, więc wyśle mu wiadomość, dostanie odpowiedź i wróci z nią do mnie w tej głównej sesji.
I proszę. Napisał: „pinguję Kasę w sprawie rolki o Anthropicu”, potem: „wiadomość wysłana”. Jak w to kliknę, widzę całą rozmowę — tylko do odczytu, ale widać, co Klaus napisał do Kasy, i widać odpowiedź Kasy. Klaus pisał: „Podeślij najnowszy status ze Slacka albo cokolwiek masz. Jakieś blokery, następne kroki? Zwięźle, przekażę mu dalej”. Kasa odpisała, a kiedy wracam do głównej rozmowy z Klausem, odpowiedź już tam jest.
Co jeszcze fajne: jeśli wejdę w rozmowę z Kasą, zobaczę tam wpis: „a przy okazji, Klaus pytał mnie o to i to”. Nie da się więc trzymać niczego w tajemnicy — agenci na siebie donoszą, jeśli któryś zachowuje się dziwnie. I uważam, że to świetna funkcja, bo mocno zachęca do tego, żeby każdy agent był bardzo wyspecjalizowany — skoro tak łatwo mogą się ze sobą komunikować.
Ta sama praca na telefonie
Na tym etapie zbudowałem czterech agentów. A co, jeśli chcę wyłączyć komputer i pójść na spacer? Albo wyjeżdżam na wakacje? Na telefonie mam dokładnie to samo. Otwieram Klausa na telefonie, widzę identyczne wiadomości, piszę „hej” — i to przychodzi w czasie rzeczywistym po drugiej stronie. Wszystko jest w pełni zsynchronizowane, bo działa w chmurze. Nie musisz nawet myśleć o stawianiu własnego VPS-a ani o niczym lokalnym.
Konektory nadal działają. Pulpity agentów też. Pamiętacie, że Klaus był na YouTubie? Wchodzę w przeglądarkę na telefonie i widzę to samo, a co więcej — mogę tym sterować z telefonu. Wpisuję „Nate Herk”, szukam filmów na YouTubie i mogę to robić z komórki. Sterowanie komputerem w chmurze z telefonu, zarządzanym przez Klausa. To naprawdę mocne, że tak szybko można to sobie postawić.
Do czego autor będzie tego używał, a do czego nie
Porozmawiajmy o tym, co jeszcze tu mamy i jakie są realne ograniczenia. Pierwsze pytanie: ile faktycznie będę tego używał?
Jeśli siedzę przy biurku i robię pracę koncepcyjną, jeśli coś buduję — nie będę tego używał. Będę używał Codeksa i Claude Code, bo to nimi lubię prowadzić robotę, gdy siedzę przy biurku. Ale jeśli podróżuję, jestem na tylnym siedzeniu Ubera, na wakacjach albo siedzę w restauracji — będę używał tego, bo telefon synchronizuje się od razu i wszystko jest czyste i proste. Tak właśnie rozgraniczam dziś agenta Hermesa od Claude Code czy Codeksa: Hermesa lubię używać w drodze. I uważam, że to narzędzie w drodze sprawdza się zdecydowanie lepiej i wygodniej.
Rzecz oczywista: na zapleczu działa tu model Groka. To nie jest moja subskrypcja Codeksa ani API Anthropica — to nie te modele. Jeśli więc naprawdę mocno wolisz inne modele i zauważysz, że nie odpowiada ci sposób, w jaki modele Groka prowadzą interakcję, być może nie będziesz z tego korzystał tak często.
Ja podchodzę do tego tak: nie będę stąd budował szalonego oprogramowania ani skomplikowanych aplikacji. Raczej będę sprawdzał, jak stoją sprawy, komunikował się z zespołem, przeglądał rzeczy, ustawiał przypomnienia — ogólna praca umysłowa. Głębokie nurkowania, te rzeczy, przy których muszę wejść w stan przepływu, zostawiam na czas przy biurku.
Ustawienia, limity i test prototypu
Zanim przejdę do ustawień, wysyłam jeszcze wiadomość do Klausa: prosi go o postawienie strony z listą oczekujących i mówię, żeby pracował razem z naszym inżynierem AI. Wciąga więc deva do sprawy i biorą się do roboty. Miejmy nadzieję, że za chwilę zobaczymy coś na localhoście.
W międzyczasie ustawienia. Klikam swoją nazwę: widzę tygodniowe zużycie — wykorzystałem 2%, resetuje się za 7 dni. Można też dokupić. Mówiliśmy o wersji na iOS. W ustawieniach mamy motyw, strefę czasową, wykonywanie na lokalnym komputerze — uprawnienia można przestawić na „pytaj za każdym razem” albo „nigdy nie pozwalaj”. Można też ustawiać reguły: kiedy Grok Bot chce zrobić określone rzeczy, ma najpierw zapytać albo dostać automatyczną zgodę.
O, prototyp poszedł błyskawicznie. Otwieram — klikam localhost i mamy stronę: „Zdobądź certyfikat z automatyzacji bez przytłoczenia”. Ciekawe: dane ma dobre, ale nie użył poprawnie naszych wytycznych brandowych i logotypów. Zastanawiam się, w czym problem — może po prostu ich nie znalazł. Piszę więc: zauważyłem, że nie użyłeś naszych wytycznych brandowych, jeśli chodzi o kolorystykę i logo; chciałem wiedzieć, dlaczego.
Ciekawostka: stworzył tę stronę na moim localhoście, bo to jest w moim Google Chrome. Gdybym chciał, żeby zrobił to na swoim localhoście, na swoim komputerze — musiałby to zbudować inaczej. Jak wiecie, localhost działa tylko na jednym urządzeniu. I to jest w sumie fajne, że zbudował to lokalnie na moim faktycznym pulpicie, a nie na ich komputerze w chmurze. Mógłby zrobić i tak, ale trzeba by to doprecyzować.
Klaus odpowiedział: „Tak, to moja wina. Kiedy brifowałem deva, powiedziałem, żeby wybrał sensowny domyślny styl, jeśli brandingu nie ma pod ręką, a oni założyli, że nasza kolorystyka to granat i indygo. Nie wskazałem im materiałów brandowych. Chcesz, żebym zrobił to jeszcze raz?”. Mówię: tak — i za chwilę zobaczymy tę wersję.
Wtyczki, skille i finalny efekt
I to w zasadzie tyle. Chodzi o to, żeby wejść, podłączyć trochę kontekstu ze swojego biznesu, a potem po prostu budować kolejne skille i kolejnych subagentów, patrzeć, jak mogą ze sobą współpracować, i stawiać rutyny tak szybko, jak się da — bo są naprawdę szybkie i proste w konfiguracji.
Jeśli chcesz zobaczyć pozostałe wtyczki, klikasz „wtyczki” — możesz przewijać, wyszukiwać, a jeśli chcesz podpiąć własne, niestandardowe, też możesz. Widzisz tu również wszystkie swoje skille. To moje własne — na razie zrobiłem jeden. Tutaj aktualizujesz nazwę, opis i instrukcje, można też skill usunąć.
A teraz spójrzcie na to. Klaus znalazł wytyczne brandowe, napisał do deva i mamy tu nową wiadomość oraz cały wątek między Klausem a devem. Rozmawiali o prototypie, dev go dostarczył, po czym Klaus wrócił i powiedział: „Oto właściwe wytyczne brandowe, oto logo i dokument z wytycznymi”. A dev odpowiada: „Dostałem to od Klausa, muszę przestylować listę oczekujących” i tak dalej. Myślę, że łapiecie sens: rozmawiają ze sobą, mamy ustawione rutyny, możemy to bardzo łatwo rozbudowywać. I świetne jest to, że mogę kontynuować pracę na telefonie bez żadnego wysiłku.
Przestroga: nie daj się ponieść hype’owi
Jedna ważna rzecz przy narzędziach tego typu: nie daj się porwać ekscytacji. Tak, są fajne i przyjemne w zabawie, ale nie zaczynaj na siłę tworzyć agentów i rutyn, których w rzeczywistości nie potrzebujesz. Zastanów się naprawdę, co ogranicza twój biznes. Jakie punkty bólu odczuwasz na co dzień? I czy to narzędzie rozwiązuje któryś z nich?
Ja spróbuję przenieść tu wszystkich agentów Hermesa, których mam, i myślę, że będzie to działało spójniej, bo tutaj łatwiej im ze sobą rozmawiać niż w konfiguracji, którą mam w Hermesie. Ale jeśli faktycznie nie masz potrzeby, jeśli nie masz problemu, który to narzędzie rozwiąże, to może się okazać stratą czasu — zwłaszcza gdybyś spędził cały tydzień na zabawie. To jest fajne i przyjemne, ale jeśli mamy poważnie rozmawiać o tym, czy tego potrzebujesz, warto sobie ten element przemyśleć.
No dobrze, powinno być gotowe. Wchodzę na listę oczekujących i robię twarde odświeżenie. Bum. To wygląda dużo bardziej zgodnie z naszym brandem. Wciąż są rzeczy w designie, które mi się nie podobają, ale przecież powiedziałem tylko: „zbuduj mi bardzo prosty formularz listy oczekujących”. Nie wiem nawet, czy on gdziekolwiek prowadzi — musielibyśmy iterować dalej. Gdybyśmy chcieli, żeby dev podpiął to na przykład do ClickUpa, spokojnie moglibyśmy to zrobić. Ale przy pierwszym podejściu widać, że potrafił zajrzeć do mojego repozytorium, miał cały kontekst tego programu i zbudował to błyskawicznie.
Na tym kończymy. Mam nadzieję, że pokazałem wam, co jest możliwe z tym narzędziem. Kiedy będą wychodzić nowe aktualizacje, chętnie je omówię. Oby automatyzacje i rutyny stawały się coraz łatwiejsze do budowania, z coraz szerszą listą triggerów. Jestem bardzo ciekaw, jak to narzędzie się rozwinie.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Jeden agent — jedna robota
Na czym polega: Zamiast jednego megaagenta budujesz flotę wąsko wyspecjalizowanych botów: asystent wykonawczy, inżynier, poranny planista, agent od Slacka. Autor podkreśla, że megaagent po prostu się gubi i traci jakość.
Jak stosować: Przy każdym nowym zadaniu pytaj, czy to praca dla istniejącego agenta, czy dla nowego. Nazwij rolę tak, jak nazwałbyś stanowisko w firmie — „sales outbound”, „paid media”, „zarządzanie wydatkami”.
Na co uważać: Rozdrobnienie też ma koszt — jeśli dwaj agenci mają nakładające się opisy, delegowanie zacznie trafiać w losowego. Lepiej mieć czterech ostro rozgraniczonych niż dwunastu podobnych.
2.Opis agenta to mechanizm routingu, nie ozdobnik
Na czym polega: Agenci wybierają, komu oddelegować zadanie, czytając opisy pozostałych — dokładnie tak, jak wybierają skille. Zły opis = brak delegacji albo delegacja do niewłaściwego bota.
Jak stosować: Pisz opis jako jedno konkretne zdanie po czasowniku: „Ten agent przegląda mój Gmail i kalendarz, żeby zaplanować mi dzień w dni robocze”. Wymień w nim narzędzia i domenę, a jeśli trzeba — także skille i rutyny, którymi dysponuje.
Na co uważać: Opisy ogólne („pomaga w pracy”) są funkcjonalnie martwe. Po dodaniu nowego agenta przejrzyj opisy starych, żeby nie zaczęły ze sobą konkurować.
3.Rutyny czasowe stawiaj rozmową, nie klikaniem
Na czym polega: Wystarczyło powiedzieć „pomóż mi planować dzień co rano”, żeby agent sam sprawdził dostępne integracje, dopytał o źródła danych, poprosił o autoryzację Gmaila i kalendarza, ustawił rutynę na 7:00 i wygenerował próbkę.
Jak stosować: Zaczynaj od celu biznesowego, nie od konfiguracji. Zawsze odpalaj próbny przebieg od razu — to najtańszy moment na korektę instrukcji.
Na co uważać: Wygenerowana instrukcja rutyny to zwykły tekst, który warto przeczytać i poprawić. Autor wprost mówi, że można ją tweakować — nie zakładaj, że domyślna jest optymalna.
4.Triggery zdarzeniowe dają najwięcej za najmniej pracy
Na czym polega: Poza harmonogramem rutyny odpalają się na zdarzeniach: wiadomość na Slacku, zdarzenie na GitHubie, wiadomość w Teams. Postawienie alertu ze Slacka zajęło autorowi ok. 2 minut i jeden prompt — wobec ok. 7 minut w Claude Code i ok. 15 w n8n.
Jak stosować: Zacznij od kanałów, które i tak śledzisz nerwowo — sprzedaż, sponsoringi, incydenty. Poproś agenta wprost o rutynę „na triggerze”, wskazując workspace i kanał.
Na co uważać: Lista triggerów jest na razie krótka (sześć pozycji); autor zakłada rozbudowę, ale nie planuj wokół niedostępnych integracji. I pamiętaj o kroku konfiguracyjnym: /invite @cursor na kanale — bez tego nasłuch po prostu nie działa, choć rutyna wygląda na gotową.
5.Wtyczki są współdzielone, komputery i opisy — nie
Na czym polega: Jeśli podłączysz GitHuba przy jednym agencie, korzystają z niego wszyscy. Skille również działają globalnie. Odrębne pozostają sesje komputerowe i opisy.
Jak stosować: Podłączaj integracje raz, przy pierwszym agencie, który ich potrzebuje. Skille traktuj jak wspólną bibliotekę firmową, a nie jak własność jednego bota.
Na co uważać: To także model uprawnień — podłączona skrzynka jest dostępna dla każdego agenta w koncie. Jeśli któryś ma szerokie zadania w przeglądarce, zastanów się, co realnie widzi.
6.Wiele kont w jednej integracji
Na czym polega: Po podłączeniu Slacka agent widział tylko część kanałów z jednego workspace’u. Autor po prostu poprosił o dodanie drugiego połączenia i uwierzytelnił drugie konto, nazywając je „work”.
Jak stosować: Zaraz po autoryzacji zapytaj agenta wprost: „jakie kanały widzisz i możesz czytać?”. To jednozdaniowy audyt zasięgu, zanim zbudujesz na tym rutynę.
Na co uważać: Domyślne połączenie może cicho pomijać całe workspace’y. Rutyna postawiona na niepełnym zasięgu będzie wyglądać na działającą, a po prostu nigdy się nie odpali.
7.„Teach a task” zamienia klikanie w skill
Na czym polega: Na komputerze agenta nagrywasz siebie wykonującego czynność, a system automatycznie zamienia to w umiejętność uruchamianą później komendą po ukośniku.
Jak stosować: Wybieraj czynności powtarzalne i klikalne — te, których nie da się załatwić API. Zaloguj się wcześniej w sesji przeglądarki agenta; logowanie zostaje zapamiętane.
Na co uważać: Skill dziedziczy twoje uprawnienia w tych serwisach i działa na cudzych, żywych platformach. Nagrywaj czynności, które jesteś gotów firmować własnym kontem.
8.Agenci sami poprawiają swoje skille
Na czym polega: Po pierwszym przebiegu skilla lajkującego posty agent sam zauważył, że nie potrafi rozpoznać, czy post jest już polajkowany, i bez proszenia dopisał do instrukcji krok „otwórz post przed polajkowaniem”.
Jak stosować: Uruchamiaj nowe skille najpierw w trybie próbnym i czytaj raport z przebiegu — tam pojawia się autodiagnoza. Dokładaj własny feedback („to mi się podobało, tego nie chcę”), bo to napędza poprawę.
Na co uważać: Skill, który zmienia się sam, to skill, którego treści nie znasz na pamięć. Zaglądaj okresowo do zakładki skilli i czytaj aktualną instrukcję, zanim odpalisz ją na czymś ważnym.
9.Rozmowy między agentami są jawne i to jest zaleta
Na czym polega: Klaus, poproszony o status filmu, sam wysłał zapytanie do agenta Kasa, dostał odpowiedź i przekazał ją dalej. Cały wątek jest do podejrzenia (tylko do odczytu), a Kasa dodatkowo poinformowała autora, że Klaus o to pytał.
Jak stosować: Wyznacz jednego agenta na orkiestratora — punkt wejścia, do którego piszesz zawsze, i który rozdziela pracę. Kiedy wynik jest dziwny, otwieraj wątek między agentami: tam widać, gdzie brief się rozjechał (jak w sprawie brandingu — Klaus po prostu nie wskazał devowi materiałów).
Na co uważać: Nie ma tu izolacji informacji między agentami. Jeśli któryś ma dostęp do danych wrażliwych, załóż, że mogą trafić do innego przez zwykłą delegację.
10.Narzędzie na drogę, nie na głęboką pracę — i tylko wtedy, gdy masz realny problem
Na czym polega: Autor deklaruje, że przy biurku pozostaje przy Claude Code i Codeksie, a Grok Bota będzie używał w Uberze, na wakacjach, w restauracji. Na zapleczu działa model Groka, nie subskrypcja Codeksa ani API Anthropica. Kończy przestrogą przed budowaniem automatyzacji, których się nie potrzebuje.
Jak stosować: Wyznacz temu narzędziu konkretną niszę: sprawdzanie statusów, komunikacja z zespołem, przeglądanie, przypomnienia. Zanim postawisz agenta, wskaż konkretny punkt bólu, który znika.
Na co uważać: Model jest narzucony — jeśli twoje przepływy zależą od zachowania konkretnego modelu, przetestuj to najpierw. Wymagany jest plan Cursor Ultra, a zużycie jest limitowane tygodniowo (autor po całej sesji wykorzystał 2%). I najważniejsze: tydzień zabawy bez problemu do rozwiązania to tydzień stracony.