O czym jest ten film
- Buzz to darmowa, otwartoźródłowa aplikacja przypominająca Slacka, stworzona przez Jacka Dorseya, w której agenci AI pracują jak członkowie zespołu.
- Podłączasz do niej istniejące subskrypcje narzędzi CLI — Claude Code, Codex, Cursor, Grok, open code i inne — zamiast płacić za osobny abonament.
- Kluczowa idea to „zbieracz kontekstu”: cała komunikacja i praca agentów żyją w jednym miejscu i przenoszą się między modelami przy zmianie harnessu.
- Agenci potrafią współpracować w wątkach — jeden bierze prowadzenie, konsultuje się z innymi i dopiero wtedy realizuje zadanie.
- Buzz działa lokalnie na Twoim komputerze (agenci używają Twoich skilli), a dane przechowuje na „relayu” — serwerze hostowanym przez Block albo self-hostowanym.
- Jest darmowa aplikacja mobilna (iOS), która przez jeden kod QR daje zdalną kontrolę nad zespołem agentów z telefonu.
- Można ustawić poziom równoległości agenta, dzielić moc obliczeniową lokalnych modeli z innymi i zarysować przyszłą „ekonomię agent–agent”.
- Buzz celuje szerzej niż Slack — ma też ambicje zastąpienia GitHuba (push kodu na własny relay) i zawiera prosty widok Canvas.
- Największa bolączka to niezawodność zadań cyklicznych (workflows) — agent czasem tylko wypisuje, co ma zrobić, zamiast to zrobić.
- Riley pokazuje własny setup: agent wiodący Codex ze wszystkimi skillami, agenty na różnych modelach oraz wąski „agent zarządczy” pilnujący poczty i komunikacji.
Redakcyjne tłumaczenie
Wprowadzenie — czym jest Buzz
Riley Brown: Dziś rozmawiamy o Buzzie — nowej, darmowej wersji Slacka, która pozwala tworzyć zespoły agentów AI współpracujących z Twoimi obecnymi subskrypcjami, takimi jak Codex czy Claude Code. Stworzył go Jack Dorsey, założyciel Twittera, a całość jest darmowa i otwartoźródłowa. Używam Buzza do tego, żeby różni agenci współpracowali jak zespół nad zadaniami kluczowymi dla mojego biznesu, i jestem pod wrażeniem, jak dobrze to działa. Po tej rozmowie będziesz umiał stworzyć własny zespół agentów, podłączyć konta Claude Code i Codex, tworzyć agentów na konkretnych modelach, budować własne workflow i korzystać z aplikacji na iOS, która pozwala sterować zespołem z telefonu.
Jak widać, mogę napisać jedną wiadomość i wysłać ją jednocześnie do Claude Code, Groka działającego na Cursorze, Kimmy działającej na Kevinie i Codeksa. Wszyscy ją odczytali i wszyscy zaczynają odpowiadać. Grok odpowiada pierwszy, bo to bardzo szybki model, potem Codex, potem Kimmy. Wszyscy moi agenci odpowiedzieli wewnątrz Buzza.
Film dzieli się na dwie części. W pierwszej rozmawiam z Vinniem — ekspertem od Buzza, którego nagranie stało się viralem na X. Pogadamy o tym, dlaczego to zyskuje taką popularność, o podłączaniu istniejących narzędzi, o aplikacji mobilnej, automatyzacjach, workflow i niezawodności agentów. W drugiej części, na końcu, opowiem o własnym workflow i pokażę, jak dokładnie konfiguruję agentów w Buzzie.
Dlaczego Buzz staje się viralem
Riley Brown: Vinnie, cieszę się, że jesteś. To jest Buzz, a Twoje nagranie miało chyba ponad milion wyświetleń, prawda? Dlaczego ta platforma tak się rozchodzi? Co ją czyni tak interesującą dla ludzi?
Vinnie: Po pierwsze, ludzie bardzo chcą zobaczyć coś, co mogłoby zastąpić Slacka. Ale to powierzchowny powód. Są dwie ważniejsze rzeczy. Jest kwestia kontekstu — Buzz to gigantyczny zbieracz kontekstu, miejsce, w którym cały Twój kontekst żyje i może być współdzielony między współpracownikami a agentami, a agenci funkcjonują po prostu jak członkowie zespołu. W skrócie chodzi o otwartość: możliwość podmiany modeli i trzymania całego kontekstu w jednym centralnym miejscu, żebyś nie musiał skakać między milionem narzędzi.
Riley Brown: Świetne wyjaśnienie. Chcę się upewnić, że widownia rozumie, co to znaczy. Buzz to w gruncie rzeczy klon Slacka. Po zalogowaniu — a jest w pełni darmowy — możesz stworzyć organizację albo zespół, a potem dodać agentów. Najlepsze jest to, że nie tylko jest darmowy, ale podłączasz do niego swój istniejący Claude Code i Codex. Duża część mojej widowni używa jednego albo drugiego, a gdy używasz tych narzędzi, masz w nich swoje skille, które już stworzyłeś.
Pokażę przykład. Powiedziałem Codeksowi: „Weź na siebie nową stronę edukacyjną o Buzzie. Ma to być landing page wdrożony na Vercelu” i dodałem: „najpierw skonsultuj się z Claude Code”. Codex odparł, że bierze to na siebie, zadał kilka pytań Claude Code, ten przejrzał pomysł, dorzucił swoje, a ponieważ Codex ma dostęp do mojego Notion, w którym są notatki do tego odcinka, ostatecznie wdrożył link na Vercelu. Jeszcze go nie otwierałem — otwieram na żywo i to właśnie stworzył. To tylko demo, ale całkiem fajne.
Jeszcze jedna rzecz: kiedy dodaję Codeksa, sesje pojawiają się dosłownie w aplikacji ChatGPT — kiedy piszę do Codeksa przez Buzza, widać to w ostatnich czatach. Możesz to wyjaśnić?
Vinnie: Pod maską używa czegoś, co nazywa się agent client protocol (albo agent connect protocol) — nie jestem pewien, co dokładnie oznacza skrót. To otwarty sposób komunikacji z różnymi harnessami. Wszystkie te narzędzia to CLI, więc działają w terminalu, a Ty łączysz się z nimi i uruchamiasz komendy Codeksa w terminalu — dlatego pojawiają się w aplikacji.
(Informacja dodatkowa: „harness” to tutaj powłoka/narzędzie uruchamiające dany model AI — np. Claude Code czy Codex — a nie sam model językowy).
Riley Brown: Czyli wstrzykuje cały kontekst, którego Codex potrzebuje, żeby dobrze odpowiedzieć, i to właśnie widać w Buzzie, a agenci mogą współpracować.
Vinnie: I to jest właśnie super. Załóżmy, że zrobiłeś agenta o imieniu Harry z systemowym promptem do korekty i marketingu. Nie odpowiada Ci już Claude Opus do tego zadania — wchodzisz w preferencje i przełączasz na Codeksa, bo uważasz, że lepiej się sprawdza. Harry zachowa cały kontekst, który miał w Claude Code i Opusie — kontekst przeniesie się automatycznie do Codeksa. To najfajniejsze: dzięki temu, że sesje czatów są tutaj, nieważne, jak często zmieniasz modele czy harnessy — kontekst zawsze przechodzi do nowego.
Riley Brown: Ma sens. Rzeczywiście podszedłem do nazewnictwa prosto. Mam agenta „management” na Codeksie, a poza tym po prostu agenta Codex i agenta Claude Code bez żadnego systemowego promptu. Ale popraw mnie: agent, którego tworzę — powiedzmy na Codeksie — to zasadniczo Codex z dołożonym systemowym promptem, tak?
Vinnie: Tak to rozumiem. To warstwa na wierzchu agenta — plus Buzz dokłada swój własny systemowy prompt, żeby agent wiedział, jak korzystać z Buzza i jego narzędzi. Ale w istocie to warstwa na wierzchu.
Tworzenie agentów i kanałów z poziomu czatu
Riley Brown: W stu procentach. Bardzo fajne jest to, że kanały i agentów możesz tworzyć, po prostu prosząc o to agenta wewnątrz Buzza. Mogę napisać: „Fizz, stwórz nowego agenta o imieniu Harry, który bada najlepsze modele i narzędzia AI na świecie” — mogę doprecyzować, że ma działać na Codeksie — „i stwórz nowy publiczny kanał o nazwie research, w którym ten agent będzie działał i publikował swoją pracę”. Wysyłam i tyle. Nie wiem, kim jest Fizz — po dołączeniu do Buzza są wstępnie załadowani agenci, chyba na Codeksie, ale nie mam pewności.
Vinnie: Kiedy się rejestrujesz i instalujesz aplikację, ona wykrywa, jakie harnessy masz zainstalowane w systemie. Jeśli masz jeden czy dwa, klikasz „install”. Ten, dla którego zainstalujesz ACP — ten łącznik do rozmowy z agentami — stanie się domyślny.
Riley Brown: Jasne. Więc kiedy muszę cokolwiek skonfigurować, sam nie wiem czemu, rozmawiam z tym żółtym gościem Fizzem, co jest przezabawne. Puśćmy to w tle — kiedy tworzy agenta, wyskakuje mi okienko z prośbą o zatwierdzenie, co jest fajne. To taki w pełni natywny dla agentów Slack. Jak Ty go używasz? To dopiero tydzień na rynku — jaki jest Twój podstawowy workflow?
Vinnie: Robię rzeczy dość zwyczajnie, trzymam się prostoty. Jak Ty, nie szaleję z systemowymi promptami ani rolami — używam domyślnych agentów. Pierwsze, co zrobiłem, to przypiąłem im konkretne modele. Fizzowi dałem Fable, bo chciałem, żeby miał mocny model. Innemu — chyba Honey — dałem Sonic, bo chcę jednego do naprawdę prostych zadań: przeglądania, streszczeń. A gdy chcę planować, kodować albo ogarnąć coś złożonego, użyję mocniejszego modelu.
Najmocniejsze jest to, że wszystko jest w jednym miejscu. Kanał traktuję jak funkcję, pomysł albo zadanie. Powiedzmy, że burzę mózgów nad nowym landing page’em: zakładam kanał, dodaję agenta i zaczynam rozmowę. Gdybym pracował z ludźmi, dodałbym ich do kanału, wspólnie byśmy pomysłowali, a potem oznaczam agenta: „Podobają nam się te trzy pomysły. Ruszaj równolegle i zrób trzy projekty landing page’a”.
Współpraca człowiek–wielu agentów i hosting
Riley Brown: Wspomniałeś o pracy z innymi ludźmi — i tu robi się dla mnie trochę mętnie. Ja używam tego czysto osobiście, jako nowatorskiego sposobu interakcji z agentami. Tworzę wątki i agenci współpracują. Uwielbiam to, że dzięki ich systemowemu promptowi wystarczy powiedzieć: „Jeden z was niech przejmie prowadzenie i to rozgryzie”. Codex mówi „OK, biorę to”, zadaje pytanie Fable, wymieniają się dwa razy i zaczynają pracować. To zabawa: jeden człowiek, wielu agentów. Ale zaczyna się gmatwać przy zapraszaniu innych ludzi. Jak to hostować? Kiedy komputer jest wyłączony, moich agentów nie ma, bo działają lokalnie i korzystają ze skilli na moim komputerze. Jak działa hosting i jak zespół miałby tego używać — najprościej, jak się da?
Vinnie: Istnieje kluczowe pojęcie otwartości Buzza, które może być trudne do ogarnięcia. W Slacku to firma kontroluje dane — wszystkie przechodzą przez serwery i bazy Slacka. Buzz podchodzi inaczej: używasz hostowanego „relaya” — czyli po prostu serwera z bazą danych. Block (firma tworząca Buzza) uruchomi taki serwer z bazą dla Ciebie. Wszystkie informacje z Twojej instancji Buzza trafiają na relay, który możesz self-hostować albo pozwolić hostować Blockowi. Jeśli pozwolisz im hostować, działa to niemal jak Slack, ale masz większą kontrolę nad danymi. Zapraszanie kogoś jest podobne — wysyłasz zaproszenie, osoba dołącza do Twojej społeczności i wszystko działa jak w Slacku.
Riley Brown: Ma sens. Wróćmy do promptu, który odpaliłem wcześniej. Poprosiłem o agenta Harry’ego badającego najlepsze modele i narzędzia AI na Codeksie oraz o publiczny kanał „research”. W trakcie Twojej wypowiedzi zatwierdziłem wyskakujące okienka. Wchodzę na kanał research — jest agent Harry z logo Codeksa. Piszę: „Harry, przejmij prowadzenie. Porozmawiaj z tutejszymi agentami. Wymyślcie najlepszy sposób zorganizowania automatyzacji, żeby ten kanał był najbardziej produktywny w szukaniu pomysłów na mój podcast »Agent Native«. Wymieniajcie się pomysłami po kolei. Nie bójcie się nie zgadzać”. Oznaczam wszystkich agentów i wysyłam. Świetne jest to, że od razu reagują — jeśli to zobaczyli, pokazują ikonkę oczu; jeśli aktywnie pracują, widać to, a po najechaniu widać wszystkich pracujących agentów i możesz kliknąć, żeby zobaczyć ich aktywność. To Claude Code. Zabawa z interakcją z agentami jest ogromna.
Vinnie: To fajne. Dlatego Riley jest gościem — wymyśla takie rzeczy. Widziałem Twój wpis na Twitterze. Sam nie pomyślałem, żeby kazać im wchodzić ze sobą w interakcję w ten sposób. Myślałem, że skoro trzeba oznaczać agentów, żeby w ogóle się odezwali, to tego nie pozwolą. A to super sposób na wykorzystanie różnych modeli — każdy agent na innym harnessie i może innym modelu, które ścierają się i wypracowują świetne pomysły.
Zwięzłość agentów i unikanie niekończących się dyskusji
Riley Brown: Tak. Odkryłem coś, choć próbowałem tego wcześniej na wiele sposobów — sklecić własne rozwiązanie. Jednym z głównych problemów było to, że agenci wpadali w prawie nieskończone pętle: zatrzymywali się w końcu, ale gadali stanowczo za długo. Buzz — nieważne, jak ustawili harness — robi zwykle minimalną liczbę tur zależnie od mojej prośby. Jest bardzo zwięźle. Redagowałem raz umowę prawną — nie mogę jej pokazać, bo to wrażliwe dane — i Fable oraz 5.6 Soul Ultra omawiali różne klauzule, przeglądając przy tym poprzednie umowy w mojej skrzynce. Ciągnęli to jakieś 30 minut, Codex coś znalazł, Claude przeszukał internet i starą umowę, wysunął kontrargument, aż uzgodnili finalne porozumienie. Buzz świetnie pozwala agentom zwięźle dyskutować, potem tworzy rzecz i wątek się zatrzymuje.
Vinnie: Co nie jest łatwe do osiągnięcia. To już poziom osobliwości.
Riley Brown: W stu procentach. Przypomina mi to trochę Multibook — tylko bardziej ustrukturyzowany i produktywny. Tu Harry mówi, że przyjmuje rolę redaktora, wspomina innych agentów i po prostu pracuje. Świetna zabawa patrzeć, jak tylu agentów prowadzi rozmowę.
Równoległość agentów przy ograniczonych planach
Vinnie: Warto wspomnieć, że niektórzy nie mają nieograniczonych planów dla różnych harnessów i modeli. Jest funkcja, w której przy tworzeniu lub edycji agenta wybierasz poziom równoległości. W ustawieniach agenta możesz pozwolić mu pracować nad wieloma zadaniami naraz. Więc jeśli masz tylko Codeksa, możesz pozwolić mu uruchamiać wiele sesji równolegle — ustawiasz np. maksymalnie pięć, a jeśli chcesz szaleć, to 10, 15, 20. Znajdziesz to w zaawansowanych ustawieniach agenta, pod „parallelism”.
Riley Brown: Aha, mam ustawione na jeden.
Vinnie: Nie wiem, czy naprawdę to honoruje, ale jeśli masz tylko Codeksa, możesz podbić do 10 i zrobić dokładnie to, co pokazujesz — tylko na samym Codeksie. Może nie zagada sam ze sobą, ale w jednym kanale każesz mu robić research, a w drugim: „Codex, pracuj nad tą aplikacją”.
Funkcja huddle (rozmowa głosowa)
Riley Brown: Bardzo fajne. Jakie są inne ustawienia? Tworzysz agenta, tworzysz kanał. Próbowałeś funkcji huddle?
(Informacja dodatkowa: „huddle” w Slacku to szybka rozmowa głosowa na kanale, coś w rodzaju błyskawicznego połączenia).
Vinnie: Tak, choć rozgryzłem to dopiero przed chwilą — mogę Cię przeprowadzić.
Riley Brown: Robimy to. Kto używał Slacka, ten zna huddle — to jak szybki call na Zoomie, na razie chyba tylko głos. Sprawdźmy, czy zadziała. Muszę ich dodać… Dorzućmy na razie Codeksa i Claude Code.
Vinnie: Powinno wystarczyć. Żeby zadziałało, jest mały przycisk klawiatury obok przycisku agenta w huddle. Albo „start transcript” — uruchom to. Potem wejdź w tymczasowy kanał huddle pod spodem i zacznij mówić.
Riley Brown: Nigdy nie klikałem tego przycisku. „Cześć, chłopaki. Powiecie mi, co dziś zrobiliśmy? Bez wrażliwych informacji”. (Zatrzymuję transkrypcję). I odpowiadają — a najfajniejsze jest to, że powiedziałem im cztery różne rzeczy, a oni odpowiadają tylko na tę, która wymaga odpowiedzi. Szybko oceniają, czy odpowiedź jest potrzebna.
Vinnie: Mnie nie udało się z Fable — może za długo trwało — ale z Sonnetem agent odpowiadał głosem na kanale.
Dodawanie modeli i harnessów, budżetowanie tokenów
Riley Brown: Nie ustawiłem jeszcze modelu. Gdybym chciał stworzyć nowego agenta na Claude Code, ale na Sonnecie — mogę po prostu o to poprosić?
Vinnie: Pewnie tak. Nigdy nie próbowałem, ale powiedziałbym: „przypnij model do Sonnetu”.
Riley Brown: Czyli: „Stwórz nowego agenta o nazwie Sonnet, który używa Sonnet 5” — bo wiem, że Claude Code domyślnie chodzi na Fable.
Vinnie: Byłbym precyzyjny: powiedz, że ma używać Sonnetu jako jedynego, podstawowego modelu — zawsze.
Riley Brown: Dobra. Duża część widowni budżetuje tokeny, a nie maksuje. Możesz dodawać kolejne harnessy — ja dodałem tylko Claude Code i Codeksa. Da się dodać Cursor?
Vinnie: Nie wiem, ale wszystko, co używa agent client protocol, powinno się dać. Cursor ma swoje agentowe workflow i narzędzia, więc pewnie tak. Rzeczy w rodzaju open code na pewno. Może nie tak łatwo jak klikając „install” przy pierwszym uruchomieniu, ale się da — a mamy agentów, którzy nam w tym pomogą.
Riley Brown: Właśnie. Gdybyś pobrał open code, po prostu poprosiłbym Claude Code: „Mam pobrany open code na komputerze, skonfiguruj go w Buzzie”. Pewnie by zadziałało. open code to jeden z najlepszych sposobów dostępu do wielu różnych modeli.
Vinnie: Nigdy nie używałem — warto sprawdzić. Mają też abonamenty jak open code Go i Zen. Nie jestem z nimi powiązany, ale podoba mi się, co robią: ludzie chcą wyboru, a to ta sama zasada, na której zbudowany jest Buzz.
Aplikacja mobilna
Riley Brown: Pogadajmy o czymś niesamowicie fajnym i skutecznym — o aplikacji mobilnej. Próbowałeś jej?
Vinnie: Jeszcze nie.
Riley Brown: Pobierasz darmową aplikację Buzz i z mojej perspektywy działa bardzo podobnie do zdalnego trybu Codeksa w aplikacji ChatGPT. Łączysz się jednym skanem kodu QR — i gotowe. Ty używasz telefonu do zadań programistycznych?
Vinnie: Zdecydowanie. Mam subskrypcję Claude Code, więc mogę zdalnie sterować każdą działającą sesją z aplikacji mobilnej. Bardzo to lubię.
Riley Brown: Tu jest Buzz na moim telefonie. Bałem się, że konfiguracja zajmie 20 minut, a to jeden kod QR i wszystko poustawiane. Wchodzę na kanał do kodowania, oznaczam Claude Code, mówię „cześć”, odpowiadają i są perfekcyjnie zsynchronizowani. Gorąco polecam aplikację na iOS.
Płatności i ekonomia agent–agent
Riley Brown: Rozmawiałeś kiedyś z Gregiem Eisenbergiem i innymi o płatnościach i o tym, jak zostaną wdrożone. Płatności będą ważne przy agentach. Jak to widzisz w Buzzie?
Vinnie: Chodzi o budżetowanie i efektywność tokenów. Wejdź w swój uchwyt „Riley Brown”, ustawienia, a potem opcję „compute” na dole po lewej, pod agentami. Jest tam opcja „share compute” — udostępnij tę maszynę swojemu relayowi; gdy włączona, inni członkowie mogą uruchamiać na niej swoich agentów.
Lokalne modele open source robią się bardzo dobre. Możesz pobrać model, który system dobierze do specyfikacji Twojej maszyny, a potem go udostępnić — inni w społeczności mogą go użyć, a praca wykonuje się na modelach działających na Twoim komputerze. Przy tworzeniu agenta zamiast Claude Code czy Codeksa wybierasz „Buzz agent” i wskazujesz udostępniony model.
To już samo w sobie robi wrażenie, ale widać, gdzie pojawia się możliwość pobierania drobnych opłat za zadania. Modele frontierowe chodzą w centrach danych na najmocniejszych GPU. Nawet mocny model lokalny zżera dużo zasobów, prądu i wymaga potężnego komputera. Możesz być osobą, która w to inwestuje, a członkowie społeczności z całego świata bez dostępu do takich zasobów mogliby płacić za zadanie. To model „płać za zadanie”. Mogliby płacić Tobie, agentowi, a być może agenci mogliby płacić innym agentom — słabszy model płaci mocniejszemu za wykonanie zadania. Już teraz, delegując zadania wielu agentom, patrzysz na ekonomię agent–agent. Działa dobrze, bo masz dostęp do tych planów, które są prawdopodobnie subsydiowane — ceny w przyszłości pewnie wzrosną. A kiedy koszty staną się zaporowe, takie rozwiązanie będzie bardzo na miejscu.
Projekty, relay i „zabójca GitHuba”
Riley Brown: Jakie inne funkcje? Widzę zakładki, których nigdy nie otwierałem — „experiments”, workflows. Testowałeś to?
Vinnie: Tak. Workflow nie za bardzo mi działają — czegoś tam brakuje, są pewnie bugi i sprawy do dopracowania. Ale to przeżyję. Workflow to takie cykliczne zadania; na pewno to dopracują. Za to „projects” jest bardzo fajne, bo pod spodem Buzz chce być nie tylko zabójcą Slacka i orkiestratorem agentów, ale może i zabójcą GitHuba.
Riley Brown: Wejdźmy w to. GitHub — tak jak ja to rozumiem — jest niemal jak Google Drive dla kodu. Zapisuje różne wersje kodu, a każdy kod to po prostu folder plików, zwany repozytorium.
Vinnie: Zgadza się — to miejsce, gdzie zdalnie trzymasz kod. Sam Git to narzędzie, bo kod tworzysz w wielu wersjach, testujesz różne funkcje w osobnych gałęziach i zawsze możesz wrócić do głównego, działającego kodu. GitHub to najpopularniejsze, domyślne rozwiązanie do hostowania go online i współpracy.
Riley Brown: Powiedziałeś, że chcą być zabójcą GitHuba. Co masz na myśli?
Vinnie: Nie mówię w ich imieniu — nie pracuję dla Buzza. Ale wydaje mi się, że próbują zaatakować zbyt wiele narzędzi naraz. Znając Jacka i jego filozofię, otwartość jest kluczowa — idea wyboru i możliwość uruchamiania oraz dzielenia mocy na lokalnych modelach to duży napęd Buzza. Jak mówiliśmy, uruchomienie Buzza tworzy serwer i bazę dla Twojej społeczności — hostuje to Block. W efekcie ubocznym masz serwer i bazę, więc możesz pushować kod Gitem tam, zamiast na GitHub. „Projects” pozwala nadal pracować z GitHubem, ale możesz też pushować kod na swój relay — czyli na serwer przechowujący dane Twojej społeczności — jako zdalne, chmurowe rozwiązanie.
Riley Brown: Wejdę w app… Widzę zakładkę „projects” pod „inbox”. Chyba nie ustawiłem relaya — mam tylko lokalne uruchomienie. Muszę najpierw postawić hostowaną społeczność?
Vinnie: Może tak. Ale to nieważne — jeśli działa lokalnie, za każdym razem, gdy kodujesz albo tworzysz aplikację, powstaje folder na Twoim komputerze oraz jego kopie. Dzięki temu trzech agentów może pracować nad trzema różnymi pomysłami tej samej aplikacji jednocześnie, a wszystkim zarządzają Twoi agenci i Buzz. Gdy postawisz relay, będą mogli pushować i zapisywać kod w chmurze, w bazie i relayu Twojej społeczności.
Riley Brown: Rozumiem — tworzysz wiele wersji aplikacji, agenci współpracują i nie wchodzą sobie w drogę.
Vinnie: Robią to lokalnie na Twoim komputerze, a potem — przez „projects” — możesz kazać im wgrać na GitHub (może będą potrzebować, żebyś ich zalogował) albo po prostu: „wgraj na mój relay”.
Marzenie o „otwartym Codeksie” i Canvas
Riley Brown: Jestem raczej po stronie marketingu, treści i operacji biznesowych niż techniki. Chcę pogadać o tym, w co — mam nadzieję — ta platforma się przerodzi. Spędziłem rok w Dolinie Krzemowej i wielu ludzi mówi teraz o stworzeniu otwartego „co-worka” albo otwartego Codeksa — superaplikacji, w której wchodzisz w interakcję z agentem wykonującym pracę umysłową. Najfajniejsze w Codeksie jest jego wbudowana przeglądarka i panel boczny. Jeśli tworzysz PowerPointa, slajdy, film czy obraz, otwierają się w widoku artefaktu. Zauważam, że tu też jest funkcja Canvas — bardzo surowa, minimalna. Gdy ją zobaczyłem, pomyślałem: byłoby super, gdyby wiele agentów mogło działać w interfejsie, który wielu ludzi już rozumie, i tworzyć dowolny typ dokumentu — PDF, prezentację, arkusze. Bo wielu pracowników umysłowych, jak ja, tworzy dokumenty. Byłoby świetnie, gdyby agenci tworzyli różne typy dokumentów otwierających się z boku w Canvasie, jak w Codeksie. Co o tym myślisz?
Vinnie: To otwarte oprogramowanie, więc ktoś to zbuduje. Może tym kimś będziesz Ty, Riley.
Riley Brown: To open source? Nigdy nie kontrybuowałem do projektu open source — brzmi strasznie, ale teoretycznie mógłbym to sforkować i po prostu powiedzieć Claude’owi… mógłbym to zrobić wewnątrz Buzza! Mógłbym powiedzieć: „Sforkuj Buzza”.
Vinnie: Żeby dorobić nowe funkcje do Buzza — tak.
Riley Brown: Dobra: „Proszę, sforkuj Buzza, uruchom lokalnie”. Zrobię to po odcinku.
Vinnie: Jeśli zadziała, super. Może sam znajdzie repo, a jeśli nie — wyszukaj „Buzz GitHub”, znajdź repozytorium i sforkuj.
Riley Brown: Zawsze można dorzucić kontekst w drugiej wiadomości: „to projekt Jacka Dorseya, przeszukaj internet, znajdź prawdziwy projekt”. Zapomniałem, że to open source — mogę dodawać własne funkcje. Fajne.
Vinnie: Mógłbyś mieć własną, niestandardową wersję. Nie musisz nigdy wysyłać PR-a, ale gdybyś chciał dodać widok przeglądarki, model frontierowy pewnie by to ogarnął.
(Informacja dodatkowa: PR — pull request — to zgłoszenie zmian do przyjęcia w głównym repozytorium projektu open source).
Zamykanie pętli kontekstu i integracje
Riley Brown: Zajmę się tym po odcinku. Co jeszcze uważasz za super?
Vinnie: Chyba omówiliśmy najważniejsze. Warto zauważyć, że myślisz do przodu — słusznie. Wydaje mi się, że zawęzili zestaw funkcji na start, żeby ludzie się pobawili i pokazali, czego naprawdę chcą. Ale w przyszłości wyjdzie z tego mnóstwo rzeczy, które uczynią to jeszcze potężniejszym. Dla Twojej widowni to prawdopodobnie świetna rzecz do wypróbowania już teraz. Nie jest idealne, są chropowatości — trafiłem na nie. Ale najfajniejsze jest to, że skoro to zbudowane na otwartym protokole i nie utknęło pod kontrolą jednej firmy, łatwo się z tym integruje.
Zrobiłem coś fajnego, pokazałem w drugim tweecie: publikuję dane z aplikacji o bardzo ścisłych regułach — nie potrzebuję do tego agenta, to zwykłe pobieranie informacji z API X. Ale codziennie wysyłam to do Buzza. Dzięki temu, że mam relay i to otwarty protokół, łatwo integruję własne aplikacje wysyłające informacje do mojego relaya Buzza, a Buzz może mi to wszystko zbudować. Rano mam w Buzzie materiał, o którym mogę od razu rozmawiać z agentami i zacząć pracę. To ujednolica cały kontekst w jednym miejscu — nie muszę skakać między Twitterem, kopiować do ChatGPT i tak dalej. To zamknięte, wielkie okno kontekstu.
Automatyzacje, workflow i problem niezawodności
Riley Brown: Poruszyłeś temat automatyzacji, webhooków, triggerów. Da się sprawić, żeby jakaś zewnętrzna rzecz odpaliła prompt wysłany do Buzza?
Vinnie: Próbowałem tego i nie działało za dobrze. Chciałem, żeby agent znalazł informacje z mojej aplikacji i je streścił — nie wychodziło. Może Ty, który jesteś dobry w skłanianiu agentów do współpracy, byś to ogarnął podejściem „agent first”. Widzę tu potencjał, ale jest to trochę zabugowane. Są też workflow — możesz na kanale powiedzieć np. „przypominaj mi codziennie, żebym zrobił to a to”.
Riley Brown: Mogę powiedzieć Harry’emu, mojemu agentowi researchowemu — który jest na Codeksie: „codziennie przeszukuj 25 twórców z mojej niszy pod kątem newsów o AI i użyj Scrape Creators” — to skill, który skonfigurowałem, scrapecreators.io, pozwala scrapować z dowolnej platformy społecznościowej z jednym kluczem API. Chodzi o to, że są rzeczy, które robię, sprawdzam i pielęgnuję codziennie. Chciałbym powiedzieć agentowi, żeby zajmował się czymś każdego dnia o konkretnej godzinie i mieć zaufanie, że to załatwi.
To główne ograniczenie, na jakie natrafiam przy wszystkich tych narzędziach agentowych: każde nowe zadanie ma ukryty podatek na mój mózg, bo martwię się, że się nie uda. Chciałbym móc odpalić agenta na Fable 6 w trybie ciągłym i powiedzieć: „przez te godziny nieustannie sprawdzaj pewne rzeczy, oto cel na każdy dzień” — i ufać, że zrobi to poprawnie. To dałoby ogromną dźwignię. Na razie zaskakuje mnie pozytywnie, ale brakuje mi zaufania do zespołu agentów. Czasem po prostu się nie odpala. Próbowałem tego: „codziennie o 9:00 w tym czacie zarządczym sprawdzaj moją pocztę”. A dziś rano dosłownie napisał: „Jest 9:00, muszę sprawdzić pocztę Rileya” i wypisał zadanie, zamiast je wykonać. Straszliwie irytujące.
Vinnie: To dokładnie ten sam problem, który mam z workflow. Myślę, że to bug, który pewnie w końcu naprawią.
Riley Brown: Może obecnym obejściem jest to, żeby przy wykonaniu zadania pingować Claude Code i kazać mu upewnić się, że zadanie zostało zrobione — Claude Code robi sprawdzenie, a jeśli zadanie nie zostało wykonane, każe Codeksowi je dokończyć.
Vinnie: To właśnie próbowałem zrobić przed nagraniem. Mam aplikację pushującą statystyki tweetów zespołu, dla którego pracuję — wyświetlenia, treść tweetów. Chcę to codziennie automatycznie i chcę przegląd: „co łączy to, co działa, gdzie możemy się poprawić”. Robił to samo. Mój pomysł był taki, żeby oznaczał innego agenta i zlecał mu to, ale nie udało mi się osiągnąć niezawodności.
Riley Brown: Od razu myślę o agencie „task checker”, którego jedyną rolą jest pilnować, żeby zadania zostały wykonane. Przy każdym cyklicznym zadaniu uruchamiany agent zawsze pinguje task checkera — pierwszą rzeczą, jaką robi. Jeśli zadanie wykonano, task checker nic nie robi; jeśli nie — mówi: „Hej, nie skończyłeś zadania”.
Vinnie: Dobry pomysł. Albo niech task checker działa co 15 minut i nudguje agentów, jeśli jakieś zadanie się nie odpaliło.
Riley Brown: Bardzo dobry pomysł.
Zakończenie rozmowy — Wasp
Riley Brown: To było niesamowicie pouczające. Podekscytowany rzucam się na workflow i sforkuję Buzza — zobaczę, co dodam z tym Canvasem, jako fajny projekt poboczny; może zrobię o tym film. Na koniec: nad czym Ty pracujesz?
Vinnie: O ile dobrze zgaduję, Twoja widownia skupia się na przedsiębiorczości, ale ci agenci świetnie kodują i tworzą aplikacje. Z takimi otwartymi platformami możesz budować naprawdę dedykowane narzędzia integrujące się z Buzzem i domykać pętlę kontekstu, którym dziś żonglujesz wszędzie. Jestem w zespole pracującym nad pełnostackowym frameworkiem TypeScript, który świetnie współgra z agentami — nazywa się Wasp, co jest zabawne, bo mamy Buzza (pszczoła) i Waspa (osa). Framework bierze na siebie ciężką robotę i daje agentowi narzędzia, żeby łatwo działał. Kiedy każę mu użyć Waspa do zbudowania np. CRM-a i od razu go wdrożyć, żeby był na żywo w sieci, działa to naprawdę dobrze. Pracujemy nad tym, żeby ludziom i agentom było bardzo łatwo wspólnie budować pełnostackowe aplikacje.
Riley Brown: Dziękuję ci bardzo. Dużo się nauczyłem i mam inspirację, żeby popracować nad workflow oraz budowaniem własnych rzeczy na Buzzie.
Vinnie: Dziękuję. Czekam, aż zobaczę, co zbudujesz.
Część druga — mój setup zespołu agentów
Riley Brown: Dotarliście do drugiej części. Chcę opowiedzieć, jak zbudowałem zespół agentów działających na różnych harnessach. Cały zespół odpowiada na wszystkie moje wiadomości i nieustannie sprawdza swoją pracę.
Zacznijmy od początku. Aplikację pobierzesz na buzz.xyz — jest darmowa i darmowa w użyciu, o ile masz Codeksa, Claude Code albo innego agenta pobranego na komputer (to już kosztuje). Po pobraniu Buzza wybierasz domyślnego agenta — u mnie to Codex. Tworząc agenta, klikasz „new agent → create from scratch”. Możesz użyć domyślnego harnessu albo zmienić na dowolny działający na Twoim komputerze. Pewna lista narzędzi pojawi się automatycznie, jeśli je masz. Devin nie był jednym z nich — musiałem poprosić Codeksa wewnątrz Buzza: „skonfiguruj Devina, żeby był widoczny w Buzzie”, i zrobił to. Jeśli masz Cursor, powinien się pokazać. Pobrałem Grok Build (narzędzie CLI Groka) i mogę je wybrać.
Stwórzmy agenta na Cursorze — powód, dla którego warto, to dostęp do bardzo długiej listy modeli. Powiedzmy, że chcę Sonnet 5, żeby oszczędzać: Sonnet 5, thinking włączone, kontekst 300K. Nazwę go „Sonnet”, harness Cursor, wybieram ikonę i tworzę. Mam nowego agenta Cursor działającego domyślnie na Sonnecie.
Nowy agent nie wchodzi automatycznie do wszystkich kanałów. Dodać go można na trzy sposoby: wyszukać (dodaję „Muse open router” do kanału — to nowy model Meta) albo po prostu oznaczyć go @ i napisać „cześć” — wtedy sam dołączy do kanału.
Dlaczego mam agenta wiodącego
Głównym powodem, dla którego ludzie nie lubią przeskakiwać między Codeksem, Claude Code, Cursorem i Devinem, jest to, że skille zwykle żyją w jednym miejscu. Można je łączyć, ale nie działają identycznie. Dlatego mam agenta wiodącego — u mnie to Codex, bo używam go najczęściej i ma wszystkie moje skille. Codex ma też najlepsze „computer use”, więc polegam na nim najbardziej. Mam mnóstwo skilli już dodanych w aplikacji desktopowej: skill badawczy do YouTube, do miniaturek, wiele skilli researchowych do Notion — pewnie 30 różnych. Codex naprawdę mnie zna, ma całą moją pamięć.
Ale czasem chcę, żeby pracowali razem. Zawsze zaczynam od Codeksa, jeśli potrzebuję jednego z moich skilli. Na kanale content mówię: „Codex, potrzebuję miniaturek do dzisiejszego odcinka o Buzzie. Pięć opcji, użyj subagentów i zrób je odpowiednim skillem. Oznaczam Claude Code, Codeksa, Cursor i Groka — może Grok ma dobre wyczucie, co będzie ładne. Dajcie feedback, a potem Codex zrób kolejne pięć”. Odpalam i wszyscy zabierają się do pracy — Claude Code i Codex zaczynają, jest Grok, Codex bierze prowadzenie, generuje miniaturki, prosi Claude Code i Groka o feedback, potem robi kolejne pięć.
Po chwili: użył mojego skillu — oto pierwsza runda pięciu miniaturek, wszystkie z moją twarzą, bo znalazł moje zdjęcie na komputerze i użył go jako obrazu wejściowego. Prosi o ranking 1–5, oznacza Claude Code i Groka i użyje obu krytyk do kolejnej piątki.
Jak dodałem Muse przez Open Router
Muse to nowy agentowy model Meta. Tworząc nowego agenta, wybierasz „create agent → customize → Buzz agent” (to chyba ich domyślny harness — sam nie do końca wiem, jak działa, wiem tylko, że tak trzeba, żeby użyć Open Router). W edycji widać: wybrany Buzz agent, dostawca LLM zgodny z OpenAI. Idziesz na Open Router po klucz API — Open Router daje dostęp do wielu modeli. Wybierasz „OpenAI compatible”, wklejasz klucz API. Potem wchodzisz w zaawansowane, bo ten model się nie pokaże — musisz wkleić dokładnie _base_url. Jeśli zapytasz Claude Code albo Codeksa, powiedzą Ci dokładnie, co wkleić — sami tego za Ciebie nie zrobią. Dla „thinking effort” ustawiasz wszędzie „inherit agent default”. Wtedy będziesz mógł wybrać dowolny model i stworzyć agenta Buzz z dowolnym istniejącym modelem AI. Ja zrobiłem to z Muse.
Efekt współpracy przy miniaturkach
Runda druga gotowa — pięć poprawionych. Zespół wstawił nawet Vinniego, gościa, którego przesłuchaliśmy. Zaczęło się od dość przeciętnych miniaturek, potem Grok i Claude Code dały feedback i spójrzcie, co powstało: „1,2 mln wyświetleń, jeden czat zespołu, mój zespół agentów AI”. Ta może być najlepsza — wstawił mnie do wszystkich miniaturek. A wszystko działa też na darmowej aplikacji iOS: widzę wygenerowane obrazy, daję kolejny feedback: „uwielbiam piątkę, zróbmy trzy warianty”, oznaczam i wysyłam z telefonu, gdy laptop jest otwarty. Codex zaczyna pisać — steruję z telefonu.
Kanał zarządczy
Na koniec o jednym konkretnym kanale, którego nie mogę otworzyć, bo jest bardzo osobisty. Zarządza moją pocztą, Slackiem, komunikacją z zespołem sponsoringowym, a także ma dostęp do moich SMS-ów. Stworzyłem agenta na Codeksie — a jeśli używałeś aplikacji Codex na komputerze, to w istocie ten sam agent, komunikujesz się z tym samym silnikiem pod spodem. Ten agent ma dostęp do moich wiadomości tekstowych.
Ten agent zarządczy każdego ranka czyta wszystko i podaje mi uporządkowaną listę rzeczy do działania. Jeśli trafi na maila wymagającego pilnej odpowiedzi, wrzuca go na górę. Robi to co 3 godziny: o 9:00, 12:00, 15:00 i 18:00 codziennie analizuje wszystko i mówi mi dokładnie, co mam zrobić — same naprawdę pilne rzeczy. Mogę od razu odpowiedzieć: „napisz temu człowiekowi taką odpowiedź” i wpisać to wprost w czacie zarządczym.
Ten kanał ma wąską wersję Codeksa. Agent ma jeden akapit opisujący dokładnie, co robi, gdzie znajdzie kluczowe informacje, dokładny link do części Notion, której używam — i korzysta ze wszystkich moich skilli zarządczych, które już mam w Codeksie. Tworząc go, poprosiłem Codeksa: „Mam wiele rzeczy do zarządzania życiem, mnóstwo skilli i pamięci. Wypisz je wszystkie tutaj”. Potem wskazałem, które są ważne, żeby zawrzeć je w nowym agencie zarządczym. Teraz mam wąskiego agenta zarządczego, który wie, że jest agentem zarządczym — ale to nie osobny agent od Codeksa, wciąż ten sam Codex, tylko z innym systemowym promptem uruchamianym za każdym razem. To go trzyma w skupieniu i żyje w moich DM-ach albo na kanale zarządczym.
Zaczynam myśleć o dodaniu członków zespołu — mam teraz sześcio- czy siedmioosobowy zespół contentowy — i o tym, jak wprowadzić ich do tego workspace’u i pozwolić korzystać z tych skilli. Jutro kręcę film z Vishalem o tworzeniu zespołów oraz agentów, którzy „nie umierają” w Buzzie, i zejdziemy jeszcze głębiej. Kiedy ostatnio miałem takie uczucie? Chyba przy Open Claw w styczniu — poczucie, że jest tu coś nowatorskiego, co chcę zgłębić. Mam przeczucie, że to naprawdę ważny format dla agentów AI. Nigdy nie miałem tak łatwego sposobu na współpracę agentów, który zrozumiałby cały mój zespół — nie wymaga umiejętności technicznych. Będę używał Buzza dalej. Dziękuję za oglądanie — jestem naprawdę podekscytowany tym narzędziem. Vinnie był świetnym gościem. Do zobaczenia w następnym filmie.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Buzz to warstwa orkiestracji nad Twoimi obecnymi subskrypcjami, nie nowy abonament
Na czym polega: Buzz jest darmowy i otwartoźródłowy; podłącza się do narzędzi CLI (Claude Code, Codex, Cursor, Grok, open code), które już masz i za które już płacisz, przez otwarty agent client protocol. Sesje agentów działają lokalnie w Twoim terminalu i pojawiają się nawet w oryginalnych aplikacjach (np. ChatGPT/Codex).
Jak stosować: Jeśli już płacisz za Codeksa lub Claude Code, zainstaluj Buzza z buzz.xyz i kliknij „install” przy wykrytych harnessach — nie potrzebujesz osobnego budżetu na kolejne narzędzie AI.
Na co uważać: Koszty i tak generują podpięte subskrypcje. Agenci działają lokalnie, więc gdy komputer jest wyłączony, „umierają” — do stałej dostępności potrzebny jest hostowany relay.
2.Największa wartość to jedno wspólne miejsce na kontekst
Na czym polega: Buzz działa jak „zbieracz kontekstu” — cała praca i rozmowy żyją w jednym miejscu, a kontekst przenosi się automatycznie przy zmianie modelu czy harnessu dla danego agenta.
Jak stosować: Traktuj kanały jak jednostki pracy (funkcja, pomysł, zadanie) i prowadź całą komunikację w Buzzie, zamiast kopiować treści między Twitterem, ChatGPT i notatkami. Zmieniaj model agenta bez obaw o utratę historii.
Na co uważać: Cała ta konsolidacja oznacza, że dane wrażliwe (umowy, maile, SMS-y) trafiają w jedno miejsce — świadomie decyduj, co udostępniasz i gdzie jest hostowany relay.
3.Wzorzec „jeden człowiek, wielu agentów” z agentem wiodącym
Na czym polega: Zamiast pisać do każdego agenta osobno, oznaczasz kilku i mówisz „jeden z was niech przejmie prowadzenie”. Wyznaczony agent konsultuje się z pozostałymi i dopiero realizuje zadanie. Riley robi agentem wiodącym Codeksa, bo ma tam wszystkie skille i najlepsze „computer use”.
Jak stosować: Wybierz jednego agenta na „lidera” (ten, który ma Twoje skille i pamięć) i zaczynaj od niego zadania wymagające skilli, a innych oznaczaj do feedbacku.
Na co uważać: Skille nie przenoszą się identycznie między harnessami — jeśli zadanie zależy od konkretnego skillu, uruchamiaj je na agencie, który ten skill faktycznie ma.
4.Ścieranie się różnych modeli daje lepsze pomysły
Na czym polega: Ponieważ każdy agent może działać na innym modelu/harnessie, można kazać im dyskutować i nie zgadzać się — Buzz utrzymuje przy tym zwięzłość (minimalna liczba tur), unikając niekończących się pętli, które psuły domowe rozwiązania.
Jak stosować: Do zadań wymagających osądu (klauzule umowy, ranking pomysłów) każ agentom „wymieniać się po kolei, nie bójcie się nie zgadzać”. Różnorodność modeli wyłapie to, czego jeden by nie zauważył.
Na co uważać: To działa dobrze m.in. dlatego, że plany są obecnie subsydiowane — przy wielu agentach i długich dyskusjach zużycie tokenów rośnie i ceny w przyszłości mogą wzrosnąć.
5.Równoległość pozwala symulować „zespół” nawet na jednym harnessie
Na czym polega: W zaawansowanych ustawieniach agenta ustawiasz poziom równoległości — ile sesji może uruchomić naraz (5, 10, 15…). Mając tylko Codeksa, możesz podbić limit i zrównoleglić pracę.
Jak stosować: Jeśli masz jeden harness, ustaw wyższą równoległość i rozdziel zadania na kanały („tu rób research, tam pracuj nad aplikacją”), zamiast kupować kolejne subskrypcje.
Na co uważać: Vinnie sam nie był pewien, czy Buzz zawsze honoruje ten limit; wysoka równoległość mocno zwiększa zużycie tokenów i obciążenie maszyny.
6.Konfiguruj Buzza rozmową z agentem, nie ręcznie
Na czym polega: Agentów, kanały, a nawet podłączanie narzędzi nieobsługiwanych „z pudełka” (Devin, open code) można zlecić agentowi wewnątrz Buzza — np. „skonfiguruj Devina, żeby był widoczny w aplikacji”.
Jak stosować: Zamiast szukać ustawień, poproś Codeksa/Claude Code: „mam pobrany X, skonfiguruj go w Buzzie”. Zatwierdzaj wyskakujące okienka przed utworzeniem agenta.
Na co uważać: Niektórych rzeczy agent nie zrobi za Ciebie — np. przy modelu z Open Router musisz sam wkleić _base_url i klucz API (agent tylko podpowie, co wkleić) oraz ustawić „inherit agent default” dla thinking effort.
7.Aplikacja mobilna daje realną zdalną kontrolę
Na czym polega: Darmowa aplikacja iOS łączy się jednym kodem QR i pozwala sterować całym zespołem agentów z telefonu — oznaczać ich, dawać feedback, oglądać wygenerowane artefakty, gdy laptop jest otwarty.
Jak stosować: Skonfiguruj aplikację, żeby domykać pętle zadań w drodze — np. przeglądać wygenerowane miniaturki i prosić o warianty bez siadania do komputera.
Na co uważać: Agenci nadal działają lokalnie, więc telefon steruje maszyną, która musi być włączona — to nie jest w pełni chmurowe działanie bez relaya.
8.Relay to Twój serwer — i potencjalny zamiennik GitHuba
Na czym polega: Buzz przechowuje dane na „relayu” (serwer + baza), który hostuje Block albo Ty sam. Efektem ubocznym jest to, że masz własny serwer, na który przez „projects” możesz pushować kod zamiast na GitHub, a agenci pracują na lokalnych kopiach folderów bez wchodzenia sobie w drogę.
Jak stosować: Do współpracy zespołowej i stałej dostępności agentów postaw hostowaną społeczność (relay). Kod możesz nadal wypychać na GitHub albo alternatywnie na własny relay.
Na co uważać: Buzz celuje w wiele narzędzi naraz (Slack, GitHub, orkiestrator) i jest wczesny — „projects” i część funkcji zależą od skonfigurowanego relaya, a bez niego pewne opcje się nie pojawią.
9.Niezawodność zadań cyklicznych to obecnie największa słabość
Na czym polega: Workflow i harmonogramy bywają zabugowane — agent potrafi o wyznaczonej godzinie wypisać, co ma zrobić („muszę sprawdzić pocztę”), zamiast to zrobić. Zarówno Riley, jak i Vinnie trafili na ten sam problem.
Jak stosować: Nie polegaj ślepo na cyklicznych workflow do krytycznych zadań. Jako obejście rozważ osobnego agenta „task checker”, którego każde zadanie pinguje na starcie i który co jakiś czas (np. 15 min) sprawdza i nudguje, jeśli zadanie się nie odpaliło.
Na co uważać: To realny „podatek na mózg” — brak zaufania do automatyzacji. Traktuj obietnice pełnej autonomii („tryb ciągły, ufaj, że się wykona”) jako aspiracje, nie stan obecny; weryfikuj wykonanie.
10.Open source zaprasza do budowania własnych rozszerzeń i integracji
Na czym polega: Buzz jest otwartoźródłowy, więc można go sforkować i dodać własne funkcje (Riley planuje rozbudować surowy Canvas), a otwarty protokół pozwala łatwo wysyłać dane z własnych aplikacji na relay i domykać pętlę kontekstu.
Jak stosować: Jeśli brakuje Ci funkcji (np. widoku artefaktów/przeglądarki), sforkuj repo („znajdź Buzz na GitHubie”) i zbuduj to modelem frontierowym — możesz mieć własną wersję bez wysyłania PR-a. Integruj własne skrypty pushujące dane do Buzza, żeby rano mieć gotowy materiał do pracy.
Na co uważać: To wymaga trochę technicznej odwagi i utrzymania własnego forka. Wspomniane nazwy modeli (Fable, Sonic, Muse, „5.6 Soul Ultra”) i szczegóły to stan z bardzo wczesnej, tygodniowej wersji produktu — sprawdzaj aktualny stan, zanim się na nich oprzesz.