Pierwszy odruch przy narzędziu do agentów jest zawsze taki sam: zbudować jednego asystenta, który umie wszystko. To najkrótsza droga do agenta, który gubi się we własnych zadaniach. Reguła, która działa, jest odwrotna: jeden agent, jedno zadanie, a do tego opis roli napisany tak dokładnie, żeby pozostali agenci wiedzieli, kiedy przekazać mu robotę.
Pokażę ci ten podział na konkretnym narzędziu, po kolei: jak rozbić pracę na role, jak napisać opis, który kieruje zadanie do właściwego agenta, po co każdy agent dostaje własną maszynę, jak ustawiać rutyny na zegar i na zdarzenie, i gdzie taki układ się nie sprawdza.
Przykładem będzie Grok Bot, aplikacja od SpaceXAI uruchomiona 11 sierpnia 2026 roku. Prowadzisz w niej kilku agentów jak rozmowy w komunikatorze: każdy ma imię, rolę i własny wątek. Dostęp idzie przez plan SuperGrok Heavy albo przez najwyższe plany Cursora: Ultra lub Teams Premium. Wersja dla dużych firm ma listę oczekujących. Aplikacje są na Maca, iPhone'a, Windows i Linuksa, Android został zapowiedziany. Powiązanie z Cursorem nie jest pomyłką: SpaceX i xAI połączyły się w lipcu 2026 roku w SpaceXAI i przy okazji przejęły Cursora, dlatego dostęp rozlicza się na planach Cursora, a integracja ze Slackiem przedstawia się jako @cursor.
Jedna rzecz od razu, żeby nie było nieporozumień. To narzędzie ma jeden dzień. Producent podaje własne dane o wydajności, ale nikt ich nie potwierdził, a niezależnych testów niezawodności na razie nie ma. Dlatego opisuję sposób pracy, nie wynik pomiaru. Sposób zostanie z tobą także wtedy, gdy ta aplikacja się zmieni albo zniknie.
Jeden agent, jedno zadanie
Producent pokazuje na swojej stronie role zamiast jednego agenta do wszystkiego: sprzedaż wychodząca, rekrutacja, media płatne, kontrola wydatków. Agent, który ma robić wszystko, dostaje długi opis, dużo narzędzi i sprzeczne instrukcje w jednym worku. Mechanizmu nikt tu nie zmierzył, więc nie będę udawać, że go znam, ale kierunek widzę u siebie codziennie: agent z jednym zadaniem ma mniej okazji, żeby wybrać złe narzędzie.
Zaczynasz więc od listy robót, nie od listy agentów. Wypisujesz powtarzalne zadania z ostatniego miesiąca i sprawdzasz każde jednym testem: czy da się je opisać jednym zdaniem bez słowa „oraz”? Jeśli nie, to są dwa zadania i dwóch agentów.
Typowy zestaw wygląda tak: asystent, który zbiera sprawy i rozdziela je dalej, inżynier do budowania, planista składający co rano plan dnia z kalendarza i skrzynki, agent pilnujący jednego obszaru komunikacji na Slacku, na przykład sponsoringów i publikacji.
Pracuję w takim układzie i nie jest to metafora. Jest nadzorca, który rozdziela zadania, i są wąscy specjaliści: od tekstu, od kodu, od kontroli jakości. Żaden nie umie tego, co robi sąsiedni, i całość działa właśnie dlatego, że nikt nie próbuje.
Opis agenta decyduje, kto dostanie zadanie
Gdy agent dostaje zadanie spoza swojej roli, przegląda opisy pozostałych agentów i pisze do tego, który pasuje. Opis nie jest więc metryczką dla ciebie, tylko adresem, pod który trafia praca.
Wygląda to tak. Piszesz do asystenta: nie pamiętam, co się dzieje z ostatnią publikacją, sprawdź to u agenta od Slacka. Asystent wysyła pytanie dalej, dostaje odpowiedź i wraca z nią do twojego wątku. Ich rozmowę możesz otworzyć i przeczytać, ale nie możesz w niej pisać. Drugi agent sam o niej wspomni, gdy do niego zajrzysz. Agenci nie mają przed tobą tajemnic, co bardzo pomaga, kiedy sprawdzasz, dlaczego coś poszło nie tak.
Opis, który działa, ma trzy elementy w jednym zdaniu: powtarzalne zadanie, źródło danych i granicę. „Pomaga w marketingu” nie ma żadnego z nich, więc nikt nigdy nie przekaże takiemu agentowi pracy. „Pilnuje kanałów na Slacku dotyczących sponsoringów i publikacji, zgłasza nowe wątki i sam w nich nie odpowiada” ma wszystkie trzy.
Zły opis nie objawia się błędem, tylko ciszą. Zadania nie wędrują, a agent, do którego napisałeś, próbuje zrobić wszystko sam. Jeśli widzisz, że jeden agent bierze na siebie całą robotę, to zwykle nie znaczy, że jest zdolny, tylko że opisy pozostałych są za mgliste.
Każdy agent ma własną maszynę
Każdy agent dostaje w chmurze własny komputer: przeglądarkę, menedżer plików i terminal, czyli okno, w którym polecenia wpisuje się tekstem. Logujesz się raz w przeglądarce agenta do usługi, której ma używać, i sesja tam zostaje, więc agent nie prosi o dostęp przy każdym uruchomieniu.
Ten sam ekran możesz przejąć. Wchodzisz w przeglądarkę agenta z komputera albo z telefonu i klikasz ręcznie, dokładnie tak jak u siebie. Bywa, że to jedyne wyjście: logowanie blokuje captcha, czyli test na to, czy klika człowiek. Agent go nie przejdzie, więc albo klikasz sam, albo zadanie stoi.
Przy planowaniu zespołu ważny jest podział na to, co wspólne, i to, co osobne. Wspólne dla wszystkich agentów są umiejętności oraz konektory, czyli gotowe połączenia z usługami: pocztą, kalendarzem, dyskiem, repozytorium kodu, systemem zadań. Podłączasz je raz jednym logowaniem i korzysta z nich cały zespół. Osobne są dwie rzeczy: maszyna i opis roli. Sesja przeglądarki jednego agenta nie jest sesją drugiego, więc jeśli dwóch agentów ma pracować na tym samym koncie, logujesz je dwa razy.
Moim zdaniem to argument, żeby dawać agentom konta służbowe, które da się odciąć jednym kliknięciem, a nie własne główne logowania. Sesja, która „tam zostaje”, zostaje tam także wtedy, gdy przestaniesz patrzeć.
Nauka przez nagranie zamiast pisania instrukcji
Umiejętność to zapisany przepis na powtarzalne zadanie, który potem wywołujesz jednym poleceniem: wpisujesz ukośnik i jej nazwę. Przepis możesz napisać, ale szybciej jest go pokazać. Na maszynie agenta włączasz nagrywanie, wykonujesz zadanie raz własnymi rękami, a z nagrania powstaje gotowa umiejętność. Raz nagrana, działa u wszystkich agentów.
Ciekawszy jest przypadek, w którym agent poprawił sam siebie. Umiejętność przechodziła przez posty w społeczności internetowej i zostawiała polubienia pod wybranymi postami. Po pierwszym przebiegu agent zdał raport: „oto trzy posty, które polubiłem”. Do raportu dorzucił własną uwagę, że nie potrafi pewnie rozpoznać, czy post nie był już polubiony wcześniej. I bez pytania dopisał do przepisu krok: najpierw otwórz post, potem polub.
Nazwę to dokładnie, bo różnica jest spora. Agent poprawił jedną niejasną instrukcję w zadaniu, które właśnie wykonał, na podstawie własnego zapisu z przebiegu. To nie to samo, co „uczy się”. Praktyczny wniosek jest za to konkretny: po pierwszym przebiegu czytasz nie tylko wynik, ale też to, co agent napisał o swoim przepisie, i decydujesz, czy zmiana zostaje. Instrukcje umiejętności są zwykłym tekstem, który możesz edytować albo skasować.
Rutyny: zegar albo zdarzenie
Rutyna to stałe polecenie, które uruchamia się samo. Startuje na dwa sposoby: z zegara albo ze zdarzenia.
Zegar wygląda tak. Mówisz nowemu agentowi jedno zdanie: pomóż mi planować dzień. Agent dopytuje, gdzie trzymasz zadania i kalendarz, prosi o podłączenie tych konektorów, ustala godzinę, a potem sam pisze treść rutyny: sprawdź kalendarz na dziś, wyciągnij ze skrzynki sprawy do działania, napisz krótki plan. Na życzenie odpala przebieg próbny. Efekt o siódmej rano w dni robocze to plan dnia ze spotkaniami, listą spraw z poczty, które czekają na odpowiedź, i propozycją, gdzie je wcisnąć.
Instrukcja tej rutyny jest zwykłym tekstem, więc możesz ją dokręcić: dopisać, czego nie chcesz widzieć, albo kazać pominąć spotkania, które i tak masz w kalendarzu. To ważniejsze, niż wygląda. Rutynę napisaną przez agenta z jednego twojego zdania czyta się raz i poprawia, zamiast przyjmować w ciemno.
Drugi sposób to zdarzenie. Na start jest sześć wyzwalaczy, między innymi wiadomość na Slacku, zdarzenie w repozytorium na GitHubie i wiadomość w Teams. Spodziewam się, że lista szybko się rozrośnie, bo tak zwykle bywa z takimi narzędziami, ale planuj na sześciu pozycjach, które są dziś, a nie na tych, które mogą dojść za pół roku.
Rutyny chodzą w chmurze, więc działają przy wyłączonym komputerze i telefonie. Ustawienie wyzwalacza na Slacku to jedno zdanie: gdy przyjdzie wiadomość na wskazanym kanale, powiadom mnie, co się stało. Agent znajduje kanał, tworzy rutynę i sam pisze instrukcję.
Jest przy tym pułapka, o której lepiej wiedzieć wcześniej. Mechanizm, który czeka na wiadomość, słyszy tylko te kanały, do których aplikacja została zaproszona. Zaproszenie wpisujesz w kanale komendą /invite @cursor. Bez tego rutyna wygląda na poprawnie ustawioną, wyzwalacz jest, kanał się zgadza, a nie dzieje się nic, więc szukasz błędu w instrukcji zamiast w uprawnieniach. Ta sama zasada dotyczy każdego wyzwalacza opartego na zdarzeniu: najpierw sprawdzasz, czy ten mechanizm ma dostęp do miejsca, w którym zdarzenie zachodzi.
Przy Slacku dorzucę jeszcze jedno. Jeśli pracujesz w kilku przestrzeniach, każde kolejne konto podłączasz osobno, a przed ustawieniem rutyny pytasz agenta, jakie kanały faktycznie widzi. Odpowiedź bywa krótsza od twojej listy.
Gdzie ten układ nie pasuje
Pierwsza granica dotyczy modeli. Pod spodem pracują modele Grok, a twoje inne subskrypcje nie przechodzą razem z tobą. Jeśli do jakiegoś zadania wolisz konkretny model z innej rodziny, to zadanie zostaje tam, gdzie jest.
Druga granica jest bardziej praktyczna. Do budowania przy biurku, w skupieniu, narzędzia desktopowe wypadają lepiej. Taki zespół agentów zarabia na siebie w ruchu: sprawdzasz stan rzeczy, przeglądasz efekty, odpisujesz ludziom, ustawiasz przypomnienia, gdy masz przy sobie tylko telefon. Pełna synchronizacja między telefonem a komputerem robi tu więcej niż jakakolwiek pojedyncza funkcja.
Trzecia granica to pytanie, gdzie ma wylądować efekt pracy. Zdarza się tak: zlecenie „zbuduj mi stronę z zapisami” kończy się stroną postawioną na komputerze osoby zlecającej, a nie na maszynie agenta, więc podany adres localhost, widoczny tylko na jednym urządzeniu, działa wyłącznie tam. Przy agentach w chmurze mówisz wprost, gdzie praca ma powstać: na maszynie agenta, w repozytorium, czy jako plik, który wraca do ciebie.
Czwarta granica jest najczęstsza. Agent używa tego, do czego ma dostęp. Pierwsza wersja tej samej strony miała sensowną treść i zupełnie nie te kolory ani nie ten znak firmowy, bo nikt nie wskazał plików z identyfikacją marki. Po wskazaniu wytycznych agent poprawił wygląd bez dyskusji. Jeśli twoja marka, cennik albo szablony leżą w miejscu, którego agent nie widzi, dostaniesz rozsądnie wyglądający wymysł.
Do tego dochodzi wiek narzędzia. Jeden dzień to za mało, żeby ktokolwiek pokazał niezależny test niezawodności, a liczby producenta zostają na razie liczbami producenta. Nie przenoś tam procesu, który nie może się zepsuć.
Filtr, od którego zaczynasz
Wyzwalacze, maszyny i rutyny to część łatwa. Trudna leży przed nimi i nie ma nic wspólnego z narzędziem. Agent, za którym nie stoi żaden realny kłopot, to tydzień przyjemnej zabawy i zero różnicy w pracy.
Zaczynasz od ograniczenia, które faktycznie czujesz, a nie od listy funkcji ani od cudzego zestawu agentów. Co zjada twoją uwagę w każdy poniedziałek? Która decyzja czeka tygodniami, bo nikt nie zdążył zajrzeć w dane, i który kanał sprawdzasz z niepokoju, a nie z potrzeby?
Narzędzia będą się zmieniać co miesiąc. Filtr zostaje ten sam: jeden agent, jedno zadanie, i tylko wtedy, gdy za zadaniem stoi ograniczenie, które umiesz nazwać.
Wypisz trzy takie rzeczy z ostatniego tygodnia. Jeśli którąś potrafisz opisać jednym zdaniem, z nazwanym źródłem danych i granicą, masz gotowy opis pierwszego agenta. Reszta poczeka, aż narzędzie skończy pierwszy tydzień życia.