--- title: "To nigdy nie było multi-agent. To jest multi-context." url: "https://simonebova.com/pl/writing/non-e-mai-stato-multi-agent" lang: "pl" updated: "2026-11-09" author: Simone Bova alternates: it: "https://simonebova.com/md/it/writing/non-e-mai-stato-multi-agent" en: "https://simonebova.com/md/en/writing/non-e-mai-stato-multi-agent" pl: "https://simonebova.com/md/pl/writing/non-e-mai-stato-multi-agent" --- # To nigdy nie było multi-agent. To jest multi-context. 2026-11-09 · Metoda Ten sam prompt prowadzi do innej decyzji, gdy zmienia się miejsce, w którym pracuje agent. Jak zaprojektowałem rynki w motive, przenosząc pytanie z repo do mojego second brain. Jeśli chcesz innych wyników od agenta, zmień kontekst, w którym pracuje, zanim zmienisz agenta. System prompt, toole i instrukcje ustala się na początku sesji i ważą niewiele. Repo, dokumenty, notatki i decyzje, które agent czyta w trakcie pracy, ważą dużo więcej i decydują, co zauważa, a co pomija. Zobaczyłem to 8 listopada na prawdziwym feature'ze i od tamtej pory projektuję konteksty zamiast zespołów agentów. Przez multi-context rozumiem system, w którym ci sami agenci pracują w kilku oddzielnych środowiskach, każde z własnym materiałem i własnym rodzajem pytań, a między nimi przepływa informacja, nigdy cała rozmowa. Klasyczny system multi-agent robi odwrotnie: wielu agentów z różnymi rolami w tym samym środowisku. ## Co naprawdę decyduje o zachowaniu agenta Kiedy uruchamiasz sesję, agent dostaje system prompt, listę tooli i instrukcje projektu. To ta część, którą wszyscy dopieszczają, i jest cienka. Potem agent czyta: pliki, testy, dokumenty, wcześniejsze decyzje, historię repo. Ta część jest gruba i rośnie z każdym krokiem. W moich sesjach, które trwają tygodniami, w pewnym momencie prawie wszystko, co model ma przed sobą, pochodzi ze środowiska. Jest też bias na starcie. Coding agenty powstały, żeby pisać kod, a repo z kodem pcha każde pytanie w stronę implementacji. Pytasz, co feature ma robić, a dostajesz dane, ekrany i komponenty. To idealne, kiedy pytanie brzmi: jak zbudować. Kiedy pytanie brzmi: co zbudować i dla kogo, repo jest złym miejscem. ## Przypadek: jedna marka, wiele rynków motive obserwuje, co odpowiadają asystenci AI, kiedy ktoś pyta o dany rynek. Do 8 listopada marka żyła na jednym rynku, w jednym języku. Prawdziwy świat wygląda inaczej. Marka z włoską domeną sprzedaje wszędzie i publikuje stronę w 27 językach. Marka globalna ma rynek „international”, który może być po angielsku albo po hiszpańsku, jeśli chcesz dotrzeć do hiszpańskojęzycznych na całym świecie. Agencja dzieli pracę według rynku i linii produktowej i przynosi klientowi scorecard dla każdego rynku. Coding agent miał już prompt i pierwszą odpowiedź. Ja wiedziałem już, gdzie leży materiał, żeby dobrze zdecydować: jak agencje pracują na rynkach, języki, klienci, błędy, które widziałem. Nic z tego nie żyje w repo, a kiedy pracuję nad produktem, nie przypomnę sobie tego wszystkiego z pamięci. To żyje w moim second brain. Nie stworzyłem agenta do brainstormingu. Nie myślę już agentami, myślę kontekstami. Otworzyłem sesję w second brain i przyniosłem ten sam prompt, odpowiedź coding agenta i moje wątpliwości. Żadnego nowego system promptu, żadnych nowych tooli. Zmieniło się tylko miejsce, w którym toczyła się praca. Odpowiedź przyszła z perspektywą poważnej agencji. Kilka rzeczy, których repo nie mogło wiedzieć: - Język liczy się bardziej niż kraj. Asystent zapytany po angielsku o rynek, który mówi innym językiem, może pominąć wyszukiwanie w sieci i odpowiedzieć ze starej pamięci. - Każdy rynek ma własny mix asystentów, każdy z własną wagą. W Chinach ChatGPT nie jest dostępny, liczą się Doubao, Qwen, DeepSeek i inni. - Pytanie trzeba dopasować do każdego rynku. Przetłumaczone słowo w słowo mierzy coś innego, a porównanie rynków ma sens tylko na pytaniach o wspólnym rdzeniu. - Marka to nazwa, którą wypowiada kupujący. Aperol to marka, Campari Group to firma. - Wersje językowe strony pokazują, gdzie istnieją treści. Gdzie klient sprzedaje, decyduje klient. - Płaci się za obserwowane pytania. Cena za rynek ukarałaby dokładnie tę markę, która sprzedaje w 27 językach. Skomentowałem, second brain poprawił, a decyzja trafiła do krótkiego ADR w repo motive. Coding agent dostał ją, gdy decyzja była już podjęta. W brainstormingu nigdy nie uczestniczył. Decyzja trafiła do repo w porze lunchu. Przed kolacją motive śledził marki na kilku rynkach na produkcji: rynki podpowiadane na podstawie strony, pytania dopasowane do rynku, waga dla każdego asystenta i scorecard dla każdego rynku. Pięć slice'ów, każdy ze swoją specyfikacją, a wieczorem audyty były zamknięte. ## Dlaczego ten sam agent odpowiada inaczej Model nie stał się lepszy w marketingu między jedną sesją a drugą. Przeczytał inne rzeczy. W repo miał przed sobą to, jak produkt jest zbudowany. W second brain miał to, dla kogo jest i jak pracują jego kupujący. Pytania, które agent sobie zadaje, zależą od tego, co go otacza. Konstruktywizm mówi to od ponad czterdziestu lat. W „Die erfundene Wirklichkeit”, zbiorze zredagowanym przez Paula Watzlawicka w 1981 roku, Heinz von Foerster pisze, że środowisko, tak jak je postrzegamy, jest naszym wynalazkiem, a Ernst von Glasersfeld, że wiedza ma działać w doświadczeniu tego, kto jej używa, bardziej niż odpowiadać zewnętrznej rzeczywistości. Agent w repo i agent w second brain zbudowali dwie rzeczywistości tego samego feature'a, każdą spójną z tym, co mieli przed sobą. Kontekst decyduje, którą dostaniesz. Widziałem to już przy archiwizacji: ten sam model pisał głębokie notatki w moim vaulcie i płytkie w innej pamięci podłączonej z zewnątrz, bo instrukcje i źródła były inne ([historia](https://simonebova.com/pl/writing/context-is-gold)). Tam zmieniała się jakość pracy. Tu zmieniła się decyzja produktowa. ## Zespół agentów to często jeden model w pięciu kapeluszach Najczęstszy wzorzec to zespół: PM agent, architect agent, QA agent, każdy z własnym system promptem. Jeśli wszyscy działają na tym samym modelu, w tym samym repo, czytając te same pliki, różnica między nimi to kilka pierwszych linijek. Reszta kontekstu jest identyczna, tak samo jak martwe pola. Dlatego dzielę pracę według kontekstu. Pytanie o to, co zbudować, idzie tam, gdzie żyją użytkownicy, klienci i wcześniejsze decyzje. Pytanie o to, jak zbudować, idzie do repo. Review idzie do modelu z innej rodziny, który patrzy innymi oczami ([dlaczego](https://simonebova.com/pl/writing/nessuno-legge-ogni-riga)). Każdy kontekst ma swoją robotę, a role wynikają z niej. ## Między kontekstami zachodzi wymiana informacji Rozmowa zostaje tam, gdzie jest. Przepływa informacja. Gregory Bateson definiował ją jako różnicę, która robi różnicę („Steps to an Ecology of Mind”, 1972). Z całego brainstormingu do coding agenta trafia tylko to, co zmienia to, co zrobi: decyzja, powody, co zostaje poza zakresem, kryteria ukończenia. Odrzucone pomysły i moje niedokończone wątpliwości zostają tam, gdzie się narodziły, bo dla tego, kto buduje, są szumem. Według Luhmanna informację wybiera odbiorca: ta sama decyzja informuje coding agenta w jeden sposób, a review w inny. Dlatego piszę tę wymianę z myślą o tym, kto ją przeczyta, w jego kontekście, i testuję ją stamtąd. Nośnik ma małe znaczenie. Tym razem był to ADR, innym razem jest to spec. Wymiana idzie w obie strony, jak w każdym systemie cybernetycznym od Norberta Wienera: bez feedbacku nie ma sterowania. To, czego coding agent dowiaduje się w trakcie budowania, wraca do second brain, kiedy zmienia coś, co ma przetrwać: decyzję albo lekcję. Stan pracy zostaje w repo, bo tam jest jego miejsce. ## Najmocniejszy zarzut: czyli system prompt się nie liczy Liczy się dla tego, co musi obowiązywać zawsze: uprawnienia, bezpieczeństwo, toole, do których agent ma dostęp. A model liczy się wtedy, gdy chcesz naprawdę innego punktu widzenia, jak w review. Pytanie brzmi, gdzie wkładasz pracę. Dopieszczanie person agentów, które żyją w tym samym miejscu, zmienia ton odpowiedzi. Zmiana miejsca zmienia pytania, które sobie zadają. ## Od poniedziałku - Zanim stworzysz nowego agenta, zapytaj, czy potrzebujesz nowego kontekstu. - Oddziel pytania o to, co zbudować, od pytań o to, jak to zbudować, i daj każdym ich własne miejsce. - Trzymaj to, co wiesz o użytkownikach, klientach i rynku, tam, gdzie agent może przeczytać to w całości. - Zanieś ten sam prompt do dwóch kontekstów i porównaj odpowiedzi, zanim zdecydujesz. - Między kontekstami przekazuj informację: decyzję, powody, co zostaje poza zakresem, kiedy jest gotowe. Rozmowa zostaje tam, gdzie się narodziła. - Trzymaj coding agenta z dala od brainstormingu. - Do review użyj modelu z innej rodziny, w kontekście innym niż kontekst autora. ## Do przeczytania - Gregory Bateson, „Steps to an Ecology of Mind”, Chandler, 1972. Informacja jako różnica, która robi różnicę. - Norbert Wiener, „Cybernetics: Or Control and Communication in the Animal and the Machine”, Technology Press / Wiley, 1948. Feedback. - Paul Watzlawick (red.), „Die erfundene Wirklichkeit”, Piper, 1981 (wyd. ang. „The Invented Reality”, Norton, 1984). Z esejami Heinza von Foerstera, Ernsta von Glasersfelda i Francisco Vareli. - Ciąg dalszy tego eseju, o tym, czego Niklas Luhmann uczy tych, którzy budują z wieloma agentami: [Codebase to społeczeństwo](https://simonebova.com/pl/writing/la-codebase-e-una-societa). *// ten sam prompt, inny dom. wygrał dom.* [simone@yempik.ai](mailto:simone@yempik.ai) · [Book a call](https://calendar.app.google/LKDrQPKGV2EAFCMN9)