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). 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). 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.
// ten sam prompt, inny dom. wygrał dom.