Agent programistyczny pracuje w jednej karcie, a czat do researchu w kolejnej. Każde z nich dużo potrafi, a kontekst między nimi przenosisz ty. Ten przewodnik pokazuje, jak asystent koordynujący dzieli pracę, przekazuje ją dalej i zostawia ci decyzję o tym, co wychodzi na zewnątrz.

Pięć okien czatu robi z ciebie przekaźnik

Tak wygląda tydzień właściciela małej firmy, który poważnie korzysta z AI. Cursor poprawia stronę, a w tym czasie Codex pisze skrypt do eksportu faktur. Każdą sesję zaczynasz od wklejenia tego samego tła.

Gdy jeden agent skończy, kopiujesz wynik do kolejnego okna. Agenci są szybcy; wolnym ogniwem jesteś ty, bo przenosisz tekst i pilnujesz, która wersja jest aktualna.

Dokumentacja Grok Bot opisuje inne podejście wprost. Boty mogą pracować równolegle, wysyłać sobie wiadomości, dzielić kontekst w czatach grupowych i przekazywać sobie zadania, więc nie musisz być przekaźnikiem między narzędziami (Grok Bot, przegląd).

Inżynierowie nazywają ten układ orchestrator-workers. Anthropic opisuje model centralny, który rozbija zadanie, deleguje części do modeli wykonawczych i łączy ich wyniki. Jako dobry przykład podaje programowanie, bo liczba plików do zmiany zależy od zadania i nie da się jej zaplanować z góry (Anthropic, Building effective agents).

Dlaczego jeden koordynator działa lepiej niż wiele okien

Pierwszy powód to kontekst. Wyspecjalizowany agent pracuje najlepiej z wąskim zadaniem i czystym miejscem pracy. Według dokumentacji Claude Code każdy subagent startuje ze świeżym, odizolowanym kontekstem i nie widzi historii głównej rozmowy; pracuje na podstawie wiadomości z delegacją i oddaje podsumowanie (Claude Code, subagenci).

Główna rozmowa zostaje dzięki temu czytelna, ale cały ciężar spada na przekazanie zadania. Plan trzyma koordynator i ten plan musi żyć w trwalszym miejscu niż czat. W systemie badawczym Anthropic główny agent zapisuje plan w pamięci, bo kontekst większy niż 200 000 tokenów zostaje obcięty (Anthropic, multi-agent research system).

Drugi powód to izolacja. Agenci chmurowi Cursor działają w odizolowanych maszynach wirtualnych, klonują repozytorium, pracują na osobnej gałęzi i wypychają zmiany do przekazania (Cursor Cloud Agents). Codex Cloud daje każdemu zadaniu osobne miejsce pracy, a zmiany przeglądasz przed commitem albo otwarciem pull requesta (Codex Cloud).

Koordynator korzysta z obu tych cech i raportuje ci w jednym miejscu. Inżynier z zespołu Grok Bot opisuje boty, które uruchamiają agentów chmurowych Cursor, czytają ich transkrypcje, sprawdzają dowody dołączone do pull requestów i wysyłają kolejne polecenia albo przerywają pracę (Grok Bot for Engineering).

Jak dzieli się praca

W praktyce podział wynika z rodzaju myślenia, którego wymaga dany krok:

  • Planowanie. Koordynator zamienia zlecenie na zadania, a każde ma jasny koniec i dowód, który ma wrócić.
  • Programowanie. Agent chmurowy, na przykład Cursor, Codex albo Claude Code, pracuje na własnej gałęzi.
  • Przegląd. Drugi agent czyta zmiany. Codex może przeglądać pull requesty automatycznie albo po wzmiance w komentarzu (przegląd kodu Codex w GitHub). Ty czytasz podsumowanie i dowód.
  • Research. Osobny agent zbiera źródła i oddaje krótkie wnioski z linkami, więc kontekst koordynatora zostaje czysty.

Przewodnik inżynierski Grok Bot dodaje, że boty działają najlepiej, gdy skupiają się na jednej dziedzinie (Grok Bot for Engineering).

Wdrożenie w pięciu krokach

Krok 1: Zapisz stałe zasady w pliku

Zasady wpisane w czat znikają razem z czatem, więc trzymaj je w repozytorium. Codex czyta pliki AGENTS.md, zanim zacznie jakąkolwiek pracę, i łączy wytyczne globalne z zasadami projektu (Codex, AGENTS.md). Zapisz, której gałęzi używać i których folderów nie ruszać.

Krok 2: Każde zadanie dostaje cel, format i granice

Anthropic ustalił, że każdy subagent potrzebuje celu, formatu wyniku, wskazówek co do narzędzi i źródeł oraz jasnych granic zadania. Bez szczegółowych opisów agenci dublowali pracę albo zostawiali luki (Anthropic, multi-agent research system). Dopisz dowód, którego oczekujesz, na przykład zrzut zmienionej strony albo wynik testów.

Krok 3: Przekazuj pracę przez gałęzie i pliki

Gałąź to przekazanie, które przetrwa zamknięcie laptopa. Agent chmurowy GitHub Copilot może wypychać zmiany tylko do jednej gałęzi, nowej gałęzi copilot/ albo gałęzi istniejącego pull requesta, i podlega ochronie gałęzi (GitHub, ryzyka i zabezpieczenia agenta Copilot).

Gdy dwóch agentów może ruszyć te same pliki, rozdziel ich. Dokumentacja Claude Code zaleca worktrees, czyli osobną kopię roboczą dla każdej sesji, a przy zespołach agentów każe podzielić pracę tak, żeby każdy miał własne pliki (Claude Code, agenci równolegle). Prowadź jedną listę zadań aktualizowaną przez koordynatora: zadanie, agent, gałąź, status.

Krok 4: Przy każdym nieodwracalnym kroku stoi człowiek

Dokumentacja Grok Bot wymienia wysyłanie wiadomości, publikowanie, zakupy, usuwanie danych, zmianę uprawnień i zmiany produkcyjne jako miejsca na wyraźne granice. Zaznacza też, że zgoda dotyczy proponowanej akcji i nie cofa pracy, która już się wykonała (Grok Bot, zgody, bezpieczeństwo i prywatność).

GitHub wbudował tę samą zasadę w swojego agenta. Szkice pull requestów musi przejrzeć i scalić człowiek, agent nie może ich zatwierdzić ani scalić, a workflowy domyślnie czekają, aż ktoś z prawem zapisu zatwierdzi uruchomienie (GitHub, ryzyka i zabezpieczenia). U nas obowiązuje jedna prosta zasada: agent może przygotować wszystko na gałęzi albo jako szkic, a wdrożenie, wydatek i publikacja czekają na moją zgodę.

Krok 5: Prowadź dziennik, który ktoś przeczyta później

Agenci chmurowi Cursor dołączają do pull requesta zrzuty ekranu, nagrania i logi (Cursor Cloud Agents). GitHub łączy każdy commit agenta z logiem jego sesji (GitHub, ryzyka i zabezpieczenia). Lista zasad najmniejszych uprawnień Grok Bot kończy się zaleceniem, żeby przy ważnych decyzjach zachować linki do źródeł i dziennik działań (Grok Bot, zgody, bezpieczeństwo i prywatność).

Dziennik odpowiada też na pytanie o właściciela, gdy ktoś odchodzi z firmy. To samo dotyczy agentów działających w Microsoft 365: każdy agent potrzebuje osoby, która za niego odpowiada.

Gdzie to się psuje

Utrata kontekstu. Wykonawca wie tylko to, co dostał w przekazaniu. Istnieje też odwrotne ryzyko: w OpenAI Agents SDK agent przejmujący zadanie domyślnie widzi całą wcześniejszą rozmowę, jeśli jej nie przefiltrujesz, a zagnieżdżona historia nie usuwa danych wrażliwych (OpenAI Agents SDK, handoffs). Zdecyduj, co niesie każde przekazanie. Przy ważnych decyzjach dokumentacja Grok Bot radzi sprawdzić aktualne źródło zamiast polegać na pamięci (Grok Bot, przegląd).

Dublowanie pracy. Wczesne wersje agentów Anthropic uruchamiały 50 subagentów do prostych zapytań i rozpraszały się nawzajem nadmiarem aktualizacji (Anthropic, multi-agent research system).

Koszt. W danych Anthropic agenci zużywali około cztery razy więcej tokenów niż zwykły czat, a systemy wieloagentowe około piętnaście razy więcej. Anthropic zaznacza też, że większość zadań programistycznych ma mniej naprawdę równoległych części niż research (Anthropic, multi-agent research system). Ustaw limit zużycia, zanim dodasz agentów; podejście z artykułu o limitach kredytów Copilot sprawdza się i tutaj.

Nadmiar automatyzacji. Anthropic radzi szukać najprostszego rozwiązania i dodawać agentów dopiero wtedy, gdy wyraźnie pomagają, bo autonomia oznacza wyższy koszt i narastające błędy (Anthropic, Building effective agents). Automatyczny przegląd też ma granice. Grok Bot opisuje swój Auto Review jako mechanizm oparty na modelu, który uzupełnia zasadę najmniejszych uprawnień i wyraźne granice zgód, ale ich nie zastępuje (Grok Bot, zgody, bezpieczeństwo i prywatność).

Czego nie robić

  • Nie dawaj żadnemu agentowi prawa do wypychania zmian na główną gałąź ani na produkcję.
  • Nie wklejaj haseł ani kodów jednorazowych do czatu. Wpisuj je sam w narzędziu, które o nie prosi.
  • Nie traktuj osobnych botów jak osobnych stref bezpieczeństwa. Boty Grok Bot dzielą jeden komputer w chmurze razem z plikami i logowaniami, a dokumentacja wprost odradza traktowanie ich jako granicy bezpieczeństwa (Grok Bot, zgody, bezpieczeństwo i prywatność).
  • Nie uruchamiaj czterech agentów do zmiany, którą jeden skończy w dziesięć minut.
  • Nie scalaj tylko dlatego, że automatyczny przegląd nic nie znalazł. Przeczytaj podsumowanie i obejrzyj dowód.

Kiedy poradzisz sobie sam

Możesz zacząć samodzielnie, jeśli już używasz jednego agenta programistycznego i trzymasz kod w repozytorium z gałęziami. Zacznij od małej skali:

  • Wybierz jedno powtarzalne zadanie z jasnym końcem.
  • Zapisz stałe zasady w AGENTS.md albo w odpowiedniku dla twojego narzędzia.
  • Niech koordynator uruchomi jednego specjalistę na jednej gałęzi i zażąda dowodu.
  • Zabezpiecz główną gałąź, a scalanie, wdrożenia, wydatki i publikacje zostaw do swojej zgody.
  • Prowadź listę zadań i dziennik działań, a po pierwszych dwóch tygodniach przejrzyj jedno i drugie.
  • Drugiego specjalistę dodaj dopiero wtedy, gdy pierwszy czeka na pracę, której sam nie zrobi.

Poproś o pomoc, gdy agenci mają dostać dostęp do danych klientów, płatności albo serwerów produkcyjnych, albo gdy nikt w firmie nie umie przeczytać zmian w kodzie. Dobry koordynator działa jak kierownik budowy: wie, która ekipa stawia którą ścianę, a rysunki leżą w biurze budowy, gdzie każdy może je sprawdzić. Jeśli chcesz, żeby ktoś to ustawił i utrzymywał razem z resztą twoich systemów, mieści się to w stałym wsparciu technicznym.