Testy agenta przeglądarkowego Asany obniżają koszty modeli 76-krotnie dzięki GPT-6.1 Sol

Asana twierdzi, że jej agent przeglądarkowy stał się 76 razy tańszy i pięć razy szybszy po tym, jak inżynierowie zmienili sposób przechowywania i buforowania historii przeglądania. W testach agenta przeglądarkowego Asany wykorzystano GPT-6 Astra w Codex do zbadania systemu, przeprowadzenia eksperymentów i analizy śladów działania. GPT-6.1 Sol zapewnił następnie najniższy szacowany koszt modelu w zoptymalizowanym przepływie pracy.

Główny wynik wygląda jak zwycięstwo modelu. Ważniejszy wniosek dotyczy architektury agentów. Asana zmieniła moment, w którym agent usuwał zrzuty ekranu, zwiększyła limit historii i buforowała rosnący zapis wcześniejszych kroków. Zmiany te ograniczyły powtarzalne przetwarzanie, zachowując jednocześnie informacje potrzebne agentowi do ukończenia zadania.

To rozróżnienie ma znaczenie dla każdej firmy oceniającej agentów przeglądarkowych. Zespół może przejść na tańszy model, a mimo to marnować tokeny przez słabe zarządzanie kontekstem. Może też wybrać bardziej zaawansowany model, zachować właściwą historię i obniżyć całkowite koszty operacyjne. Eksperyment Asany bezpośrednio zestawia te dwie strategie.

Badanie agenta przeglądarkowego Asany zmieniło więcej niż tylko model

Największe zyski Asany wynikały z przeprojektowania przepływu pracy wokół modelu, a nie wyłącznie z zastąpienia jednego modelu innym.

Firma opublikowała wyniki 8 października 2026 r., a 9 października pojawiło się studium przypadku OpenAI. Prace koncentrowały się na agencie przeglądarkowym w StackAI, platformie automatyzacji no-code, którą Asana przejęła wcześniej w 2026 r.

StackAI umożliwia klientom tworzenie agentów, które poruszają się po stronach internetowych, zbierają informacje i wypełniają formularze w aplikacjach biznesowych. Te przepływy pracy przypominają ludzkie przeglądanie sieci, ale działający pod spodem agent wielokrotnie wysyła do modelu instrukcje, narzędzia, tekst strony, zrzuty ekranu i wcześniejsze działania.

Ten powtarzalny kontekst tworzy kosztowny wzorzec. Każdy kolejny krok zawiera więcej historii niż poprzedni. Jeśli wcześniejsza zawartość stale się zmienia, dostawca nie może niezawodnie ponownie wykorzystać jej wersji z pamięci podręcznej.

Oryginalny agent Asany buforował stałe instrukcje i definicje narzędzi. Nie buforował jednak skutecznie rosnącej historii przeglądania. Agent usuwał też stare zrzuty ekranu i często przycinał tekst, zmieniając wcześniejsze fragmenty żądania.

Te edycje naruszały stabilny prefiks, czyli niezmieniony początek wspólny dla kolejnych żądań do modelu. Gdy ten prefiks się zmieniał, znaczną część historii przeglądania trzeba było przetwarzać ponownie.

Frank Hidalgo, dyrektor ds. technologii StackAI w Asanie, polecił GPT-6 Astra w Codex przeanalizować to zachowanie. Model zmapował bazę kodu, sprawdził sposób składania żądań i wskazał zmienne warte przetestowania.

Asana podaje, że badanie obejmowało 144 główne uruchomienia czterech modeli frontierowych. Testowano sześć zasad buforowania i obsługi zrzutów ekranu, dwa limity historii oraz trzy uruchomienia dla każdego warunku. Firma przeprowadziła później mniejsze badanie uzupełniające.

Każda konfiguracja otrzymała to samo zadanie. Agent przeglądarkowy miał zebrać sześć pól dla każdej z 32 książek z publicznego katalogu demonstracyjnego. Oznaczało to znalezienie 192 faktów przy jednoczesnym zachowaniu wystarczającego kontekstu, by zwrócić poprawną odpowiedź końcową.

Wśród modeli znalazły się GPT-6.1 Sol i trzy anonimowe alternatywy. Asana nazwała te systemy Modelami A, B i C. Model B zasilał pierwotną konfigurację produkcyjną, natomiast Model C reprezentował nowszy model tego samego dostawcy.

Asana nie ujawniła tych dostawców, co ogranicza bezpośrednie porównania konkurencyjne. Poinformowała jednak, że zoptymalizowany przepływ pracy GPT-6.1 Sol kosztował 76 razy mniej niż oryginalna konfiguracja Modelu B. Ukończył też zadanie około pięć razy szybciej.

Firma udostępniła od tego czasu zmiany dotyczące nawigacji przeglądarkowej w StackAI. Przekształca to ćwiczenie z porównania laboratoryjnego w zmianę produkcyjną, choć Asana nie opublikowała szerokich danych o wydajności na poziomie klientów.

Dlaczego buforowanie promptów stało się mechanizmem rozstrzygającym

Kluczową zmienną było to, czy agent mógł zachować większość zgromadzonej historii w niezmienionej formie między wywołaniami.

Buforowanie promptów przechowuje wielokrotnego użytku stan obliczeniowy powiązany z niezmienionym prefiksem promptu. Późniejsze żądania mogą ponownie wykorzystać ten stan zamiast przetwarzać ten sam materiał od początku.

Pamięć podręczna nie przechowuje gotowej odpowiedzi do odtworzenia. Model nadal przetwarza nowy materiał i generuje nową odpowiedź. Po prostu unika powtarzania pracy dla kwalifikującego się kontekstu, który pozostaje identyczny.

Przewodnik OpenAI dotyczący buforowania promptów zaleca umieszczanie stabilnych instrukcji i materiałów referencyjnych przed zmienną zawartością. Zaleca również aplikacjom dopisywanie historii rozmowy zamiast wielokrotnego przepisywania wcześniejszych tur.

Oryginalny projekt Asany naruszał tę drugą zasadę podczas pracy przeglądarkowej. Niemal na każdym kroku usuwał wcześniejszy zrzut ekranu, a czasem przycinał starszy tekst. Kolejne żądanie różniło się więc w środku historii.

Buforowanie wyłącznie stałego promptu systemowego nie mogło objąć największego źródła powtarzanego wejścia. Agent przeglądarkowy gromadził tekst strony, zrzuty ekranu, obserwacje i wyniki narzędzi w miarę wykonywania zadania.

Asana przetestowała inną zasadę, nazwaną przycinaniem wsadowym. Przycinanie oznacza usuwanie starszego kontekstu, zanim zgromadzona historia stanie się zbyt duża. W wybranej zasadzie agent zachowywał do 20 zrzutów ekranu, zanim ograniczał zestaw do najnowszego.

Takie podejście tworzyło dłuższe okresy historii dopisywanej wyłącznie na końcu. Agent mógł dodawać nowe obserwacje na końcu bez zmieniania wcześniejszej zawartości na każdym kroku. Większa część każdego żądania pozostawała zatem możliwa do ponownego wykorzystania.

Zoptymalizowany przepływ pracy zwiększył również limit historii tekstowej ze 120 000 do 480 000 znaków. Dało to agentowi więcej miejsca na zachowanie wcześniej zebranych faktów zamiast ich odrzucania.

Większy limit miał istotny wpływ na ukończenie zadań. Przy mniejszym ustawieniu historii GPT-6.1 Sol wygenerował odpowiedź tylko w trzech z 18 uruchomień. Przy większym ustawieniu odpowiedział we wszystkich 18 uruchomieniach, według Asany.

Asana twierdzi, że każde z tych uruchomień z większą historią zwróciło poprawną odpowiedź. Wynik ten podważa założenie, że agresywne zmniejszanie kontekstu zawsze poprawia wydajność agentów.

Usuwanie kontekstu zmniejsza bieżący rozmiar żądania. Może jednak zmusić agenta do ponownego odwiedzania stron, powtarzania wywołań narzędzi lub działania bez wcześniej zebranych dowodów. Może też zakłócić ponowne użycie pamięci podręcznej, gdy usunięcie zmienia prefiks żądania.

Najlepsza zasada zależy więc od całkowitej ekonomiki zadania. Zespoły muszą uwzględnić przetwarzanie wejścia, powtarzaną nawigację, wskaźniki ukończenia, jakość odpowiedzi i odzyskiwanie po nieudanych uruchomieniach.

Asana podała, że w zoptymalizowanej konfiguracji 89 procent wejścia GPT-6.1 Sol pochodziło z pamięci podręcznej. Wskaźnik ten wyjaśnia, dlaczego bardziej zaawansowany model mógł stać się najtańszą testowaną opcją dla całego zadania.

To centralny mechanizm stojący za wynikiem agenta przeglądarkowego Asany. Firma nie poprosiła po prostu modelu o używanie mniejszej liczby tokenów. Przeorganizowała przepływ pracy tak, aby powtarzane tokeny były tańsze w przetwarzaniu.

Większa ilość kontekstu pomogła agentowi niezawodnie kończyć zadania

Eksperyment sugeruje, że najtańsze żądanie nie zawsze jest częścią najtańszego ukończonego przepływu pracy.

Twórcy agentów często traktują kontekst jako zasób, który należy minimalizować. To podejście ma sens, ponieważ długie prompty zwiększają przetwarzanie wejścia i mogą zbliżać się do limitu kontekstu modelu.

Agenci przeglądarkowi komplikują te wyliczenia. Ich wcześniejsze obserwacje pełnią funkcję pamięci roboczej. Usunięcie adresu, atrybutu produktu, ostrzeżenia lub wyniku nawigacji może uniemożliwić agentowi udzielenie końcowej odpowiedzi.

Mniejszy limit historii przyniósł szczególnie słabe wyniki dla części modeli. Asana informuje, że Model C nie zwrócił odpowiedzi w żadnym z 18 uruchomień w tym warunku. GPT-6.1 Sol zwrócił tylko trzy odpowiedzi.

Te niepowodzenia nie były dowodem na brak ogólnych zdolności modeli do przeglądania sieci. Większy limit historii zmienił wynik. Oba modele odpowiedziały w każdym uruchomieniu po otrzymaniu wystarczającej przestrzeni na zachowanie niezbędnego zapisu.

Wynik ten wspiera szerszą zasadę inżynierską. Zasady dotyczące kontekstu muszą pasować do modelu i zadania. Jeden uniwersalny limit tokenów nie zapewni równoważnego zachowania w różnych systemach.

Modele mogą zużywać kontekst w różnym tempie, ponieważ generują odmienne opisy, wywołania narzędzi i ślady rozumowania. Jeden agent może osiągnąć próg przycinania po niewielkiej liczbie działań. Inny może działać znacznie dłużej.

Asana stwierdziła, że nowsze lub bardziej zaawansowane modele nie wykorzystywały automatycznie mniejszego limitu bardziej efektywnie. Model C zaczął przycinać historię znacznie wcześniej niż Model A podczas testowanego przepływu pracy.

Eksperyment wykazał również, że samo buforowanie było niewystarczające. Przy większym limicie historii buforowanie bez przycinania wsadowego kosztowało więcej niż brak buforowania w przypadku trzech z czterech modeli.

Wynik ten brzmi sprzecznie, dopóki nie uwzględni się struktury żądań. Pamięć podręczna ma ograniczoną wartość, gdy aplikacja stale przepisuje materiał, który chce ponownie wykorzystać. System płaci za przetwarzanie zmieniającej się historii, nie otrzymując wystarczającej liczby przyszłych trafień pamięci podręcznej.

Wybrana przez Asanę zasada połączyła trzy decyzje. Buforowała historię, dłużej zachowywała sekwencję dopisywaną wyłącznie na końcu i zapewniała większy limit, zanim przycinanie stało się konieczne.

Badanie uzupełniające postawiło kolejne pytanie. Asana przetestowała konfiguracje, które zachowywały każdy zrzut ekranu zamiast je przycinać. Niektóre z nich zapewniły niższe koszty pojedynczego wywołania niż wybrana zasada w tym konkretnym zadaniu.

Firma nie potraktowała tego jako dowodu, że przycinanie powinno zniknąć. Dłuższe przepływy pracy mogą przekroczyć limity kontekstu, a niektórzy dostawcy pobierają wyższe opłaty za operacje pamięci podręcznej. Agent, który zaczyna bez potrzeby przeglądać kolejne strony, również potrzebuje wyraźnych granic.

Asana zaleca limity liczby kroków, tokenów i całkowitego kosztu uruchomienia. Ograniczenia te zapobiegają nieograniczonemu rozrastaniu się historii przez niepoprawnie działającego lub zdezorientowanego agenta. Inną opcję oferuje kompakcja, która zastępuje starszą historię krótszym podsumowaniem.

Kompakcja wprowadza własny kompromis. Zmniejsza rozmiar kontekstu, ale zmienia wcześniejszy prompt, potencjalnie zakłócając ponowne użycie pamięci podręcznej. Podsumowanie może również pominąć szczegół, który później okaże się ważny.

Z tego powodu zespoły potrzebują zapisów poza aktywnym promptem. Asana rejestrowała żądania, ślady działania i wyniki w Command, swojej platformie do dostarczania oprogramowania. Inżynierowie i dodatkowi agenci mogli następnie przeanalizować cały eksperyment.

Trwały zapis wspiera również bazę wiedzy z możliwością wyszukiwania. Aktywny agent otrzymuje wyłącznie kontekst potrzebny na bieżącym kroku, podczas gdy recenzenci zachowują dostęp do pełnej ścieżki dowodowej.

To rozdzielenie pomaga zespołom odróżniać pamięć modelu od pamięci organizacyjnej. Kontekst roboczy agenta powinien pozostać ograniczony. Zapis eksperymentu powinien zachować wystarczającą szczegółowość, aby odtwarzać decyzje i badać niepowodzenia.

GPT-6 Astra przekształcił pracę ewaluacyjną w zadanie dla agenta

Asana użyła jednego modelu do ulepszenia systemu, a drugiego do obsługi zoptymalizowanego przepływu pracy produkcyjnej.

GPT-6 Astra działał w Codex jako agent badawczy i inżynierski. GPT-6.1 Sol był jednym z modeli czasu działania agenta przeglądarkowego. Traktowanie ich jako odrębnych ról zapobiega mylącej interpretacji wyników.

Hidalgo wyznaczył kierunek badań i wybrał proponowane zmiany warte przetestowania. GPT-6 Astra przeanalizował kod, zinstrumentował żądania, przeprowadził wstępne próby i zidentyfikował istotne zmienne.

Istniejący kod nie został zaprojektowany z myślą o kontrolowanych porównaniach. Asana twierdzi, że agent Codex zrefaktoryzował system, dzięki czemu wspólny frontend i backend mogły równolegle obsługiwać kilka eksperymentalnych przepływów pracy.

GPT-6 Astra następnie rozpoczął badanie, przeanalizował rejestry użycia i porównał wyniki. Oddzielne sesje modeli przeglądały poszczególne elementy pracy, podczas gdy ludzie oceniali wnioski i zatwierdzali zmiany produkcyjne.

Asana szacuje, że projekt wymagałby jednego lub dwóch miesięcy pracy ręcznej. Dzięki przepływowi pracy z Codexem badanie zajęło około tygodnia.

To twierdzenie pochodzi od firmy, a nie z niezależnej oceny. Opisuje też pojedynczy projekt inżynieryjny prowadzony przez dyrektora technicznego dobrze znającego system. Inne zespoły nie powinny zakładać takiego samego skrócenia harmonogramu.

Mimo to ten przepływ pracy ilustruje istotną zmianę w użyciu agentów programistycznych. Agent nie tylko wdrożył funkcję na podstawie gotowej specyfikacji. Pomógł zaprojektować i przeprowadzić badanie empiryczne.

Badanie wygenerowało ślady wykonania, wyniki eksperymentów, zgłoszenia i pull requesty. Te artefakty przeszły przez Command, zanim zmiany trafiły do produkcyjnego StackAI.

Ten proces ma większe znaczenie niż twierdzenie, że agent AI wykonał większość mechanicznej pracy. Bez stabilnych zapisów recenzenci nie mogą wiarygodnie ustalić, która konfiguracja została uruchomiona, dlaczego zawiodła ani czy zgłoszona poprawa utrzymała się po zmianach w kodzie.

Badanie Asany wskazuje, że ludzie ustalili cel i standardy oceny. Przeanalizowali też wyniki. Agent programistyczny zwiększył zakres eksperymentów, które zespół mógł przeprowadzić między tymi decyzjami.

Hidalgo opisał rutynę polegającą na wyznaczaniu celu przed pójściem spać i przeglądaniu wyników następnego ranka. Ten asynchroniczny wzorzec zamienia czas działania agenta w zasób inżynieryjny.

Przenosi jednak również wąskie gardło. Gdy eksperymenty stają się łatwe do wygenerowania, ludzie muszą poświęcać więcej czasu na wybieranie trafnych pytań, sprawdzanie pomiarów i odrzucanie mylących wniosków.

Ryzykiem jest zautomatyzowany szum eksperymentalny. Agent może wygenerować wiele uruchomień, nie dostarczając przy tym mocnych dowodów. Powtarzane testy nadal są podatne na konstrukcję benchmarku, ukrytą zmienność zadań i błędy punktacji.

Asana ograniczyła część tego ryzyka, używając stałego zadania i niezależnie przygotowanej odpowiedzi referencyjnej. Rejestrowała również własne liczniki użycia dostawcy, zamiast szacować zużycie tokenów na podstawie długości tekstu.

Firma przeprowadziła jedynie trzy powtórzenia dla większości konfiguracji. Asana wyraźnie zaznacza, że badanie ujawnia ogólne wzorce, a nie wiarygodne różnice rzędu kilku punktów procentowych.

To zastrzeżenie jest ważne. Porównania 76x i 5x są wystarczająco duże, by zasługiwać na uwagę, lecz łączą zmiany architektury i modelu. Nie wyodrębniają uniwersalnej przewagi GPT-6.1 Sol.

Wewnętrzne wyniki Asany pokazują, że Model B również znacząco się poprawił po otrzymaniu zoptymalizowanego przepływu pracy. Architektura odpowiadała za znaczną część wzrostu, zanim GPT-6.1 Sol dodatkowo obniżył koszty.

Czego nie dowodzi twierdzenie o 76x

Opublikowane wyniki są przekonującym dowodem inżynieryjnym, ale nie stanowią neutralnego benchmarku rynku agentów przeglądarkowych.

W badaniu wykorzystano jedno ustrukturyzowane zadanie na publicznym katalogu książek. Każde uruchomienie realizowało ten sam cel i zbierało ten sam zestaw pól. Rzeczywiste przeglądanie w przedsiębiorstwach często obejmuje uwierzytelnianie, zmieniające się układy stron, niejednoznaczne instrukcje i odzyskiwanie działania po niespodziewanych oknach dialogowych.

Przepływ pracy, który wyróżnia się w powtarzalnym wydobywaniu danych, może zachowywać się inaczej w zakupach, wsparciu, zgodności regulacyjnej lub operacjach wewnętrznych. Takie zadania mogą wymagać oceny sytuacji w kilku systemach, a nie powtarzanego zbierania danych z podobnych stron.

Test agenta przeglądarkowego Asany porównywał także GPT-6.1 Sol z trzema zanonimizowanymi modelami. Czytelnicy nie mogą sprawdzić ustawień specyficznych dla dostawców ani ustalić, jak każda alternatywa działałaby po niezależnej optymalizacji.

Asana twierdzi, że podczas badania Modele B, C i GPT-6.1 Sol miały porównywalne standardowe ceny. Model A był pozycjonowany jako tańsza alternatywa. Artykuł publiczny nie ujawnia ich nazw.

Ta anonimowość uniemożliwia przekształcenie wyniku w przejrzysty ranking modeli. Chroni też badanie przed przekształceniem się w porównania dostawców, których nie wspiera wystarczająca liczba prób.

Największy nagłówek porównuje zoptymalizowany przepływ GPT-6.1 Sol z pierwotną konfiguracją produkcyjną na Modelu B. Jednocześnie zmieniły się dwie zmienne: model i architektura agenta.

Węższe porównanie wykazało czterokrotną redukcję kosztów, gdy nową politykę zastosowano w ramach GPT-6.1 Sol. Pozostała różnica wynikała z porównania tego zoptymalizowanego systemu ze starszą bazą produkcyjną.

Nie osłabia to wyniku. Zmienia wniosek. Badanie wspiera łączenie zdolnych modeli z architekturą świadomą kontekstu, a nie traktowanie zmiany modelu jako całego rozwiązania.

Pięciokrotna poprawa czasu działania wiąże się z podobnymi zastrzeżeniami. Niektóre pierwotne uruchomienia Modelu B osiągnęły limit kroków przed ukończeniem zadania. Ich zmierzony czas trwania stanowi więc dolną granicę czasu potrzebnego na pełne zadanie.

Jakość ukończenia również wymaga stałej obserwacji. Asana podaje, że wszystkie uruchomienia w najlepszych warunkach znalazły wymagane fakty i udzieliły poprawnych odpowiedzi. Publicznie dostępny materiał nie obejmuje jednak obciążeń klientów ani długoterminowych wskaźników błędów.

Niezależna replikacja pozostaje ograniczona, ponieważ pełne badanie zależy od implementacji i śladów Asany. Firma udostępniła metody oraz pełniejszą wersję badania, lecz zespoły zewnętrzne nadal potrzebują własnych zestawów zadań.

Przejęcie StackAI przez firmę również tworzy komercyjny interes w wyniku. Asana sfinalizowała przejęcie StackAI w maju 2026 roku, aby rozszerzyć przepływy pracy agentów działających w wielu systemach.

OpenAI ma podobny interes w pokazywaniu, jak GPT-6 Astra i GPT-6.1 Sol wspierają agentów korporacyjnych. Oba źródła pierwotne dostarczają wartościowych szczegółów technicznych, ale żadne nie stanowi niezależnego audytu branżowego.

Warunki operacyjne również mogą zmienić rezultat. Dostępność cache ma ograniczony czas życia. Równocześni klienci mogą mieć różne historie, a spersonalizowany kontekst może zmniejszać ilość współdzielonych materiałów.

Wymogi prywatności mogą ograniczać, które treści trafiają do kontekstu modelu. Zespoły bezpieczeństwa potrzebują też mechanizmów kontroli dla zrzutów ekranu, poświadczeń, danych klientów i poufnych informacji zebranych podczas przeglądania.

Buforowanie nie usuwa tych obowiązków. Zmienia zachowanie obliczeń i rozliczeń, a nie potrzebę zarządzania danymi. Zespoły nadal potrzebują polityk retencji, kontroli dostępu, śladów audytowych i obsługi awarii.

Właściwy wniosek ma zatem charakter warunkowy. Asana znalazła wartościową optymalizację dla określonego agenta przeglądarkowego i wdrożyła ją na produkcji. Inne zespoły powinny traktować ten mechanizm jako hipotezę możliwą do przetestowania.

Kolejny test to wydajność w rzeczywistych przepływach pracy klientów

Kolejne trzy sygnały pokażą, czy wynik Asany stanie się modelem działania możliwym do ponownego wykorzystania, czy pozostanie mocnym wewnętrznym studium przypadku.

Pierwszym sygnałem będzie szerszy zakres oceny. Asana twierdzi, że rozwija narzędzia pozwalające klientom i zespołom wewnętrznym porównywać koszt, czas działania i jakość odpowiedzi podczas konfigurowania agentów.

Te oceny muszą obejmować zadania wykraczające poza ustrukturyzowane wydobywanie danych z katalogów. Przydatne zestawy testowe powinny uwzględniać zmieniające się strony internetowe, aplikacje wymagające uwierzytelnienia, częściowe awarie, długie ścieżki nawigacji oraz instrukcje z niejednoznacznymi punktami zakończenia.

Jeśli ta sama polityka historii poprawi te przepływy pracy, argument za optymalizacją opartą na architekturze stanie się silniejszy. Jeśli zyski się skurczą, wybrana przez Asanę konfiguracja może być ściśle powiązana z powtarzalnym wydobywaniem danych.

Drugim sygnałem będą dowody z wdrożenia produkcyjnego. Asana już wdrożyła zmiany w nawigacji przeglądarkowej do StackAI, ale nie opublikowała zbiorczych wyników klientów.

Wskaźnik ukończenia powinien mieć większe znaczenie niż koszt pojedynczego wywołania. Tańsze żądanie ma niewielką wartość, jeśli klienci muszą ponownie uruchamiać zadania lub ręcznie naprawiać niekompletne wyniki.

Zespoły powinny też obserwować udział wejść obsługiwanych z cache, medianę czasu trwania zadania, awarie wynikające z limitów kroków i wskaźniki interwencji człowieka. Te miary pokazują, czy zoptymalizowany projekt wytrzymuje zmienny ruch produkcyjny.

Trzecim sygnałem będzie reakcja konkurencyjnych dostawców modeli i platform agentowych. Buforowanie promptów stało się funkcją produktu, lecz to architektura aplikacji decyduje, czy deweloperzy mogą z niej skorzystać.

Dostawcy mogą konkurować dłuższą retencją cache, lepszą diagnostyką, niższymi stawkami za dane wejściowe z cache i bardziej przejrzystymi danymi o użyciu. Frameworki agentowe mogą udostępniać polityki historii bez zmuszania każdego klienta do budowania własnej instrumentacji.

OpenAI pozycjonuje GPT-6.1 Sol jako model do zaawansowanej pracy agentowej przy niższych kosztach operacyjnych niż GPT-6 Astra. Badanie Asany dostarcza konkretny przykład zastosowania tego pozycjonowania.

Najsilniejsza presja konkurencyjna spada jednak na zespoły tworzące oprogramowanie agentowe. Klienci będą coraz częściej oczekiwać, że platformy automatycznie zoptymalizują całkowity koszt zadania, zamiast udostępniać wyłącznie selektor modelu.

Dojrzała platforma powinna rekomendować limity kontekstu na podstawie obserwowanego zachowania. Powinna identyfikować zmiany przerywające cache, porównywać polityki i ostrzegać, gdy przycinanie skłania agenta do ponownego odwiedzania wcześniejszych stron.

Powinna też zachowywać wystarczającą ilość zewnętrznych dowodów, aby ludzie mogli audytować wynik. Agent przeglądarkowy potrzebuje ograniczonej pamięci roboczej, podczas gdy organizacja potrzebuje kompletnego zapisu operacyjnego.

Asana planuje włączyć podobne testy do swojego systemu oceny. Używa też GPT-6 Astra w Codexie do nawigowania po funkcjach produktu, wypróbowywania różnych danych wejściowych i zgłaszania błędów do weryfikacji przez ludzi.

To rozszerzenie wykracza poza historię jednego agenta przeglądarkowego. Asana testuje, czy agenci inżynieryjni mogą stale oceniać innych agentów i funkcje produktu.

Możliwość jest oczywista. Zautomatyzowane eksperymenty mogą ocenić więcej konfiguracji, niż niewielki zespół inżynieryjny byłby w stanie przetestować ręcznie. Mogą też skrócić drogę od analizy śladów wykonania do przejrzanych zmian w kodzie.

Ograniczenie jest równie oczywiste. Uwaga człowieka staje się zasobem deficytowym, gdy agenci mogą stale generować eksperymenty, ustalenia i poprawki. Zespoły muszą zdecydować, którym wynikom można zaufać i które zasługują na ekspozycję produkcyjną.

Dla deweloperów natychmiastowym działaniem jest mierzenie kompletnych zadań, a nie pojedynczych wywołań. Rejestrujcie współczynniki trafień cache, jakość ukończenia, czas działania, ponowne próby i pracę ludzką potrzebną do naprawy w realistycznych warunkach.

Dla nabywców korporacyjnych: pytajcie dostawców, jak ich agenci zarządzają rosnącymi historiami. Sama nazwa modelu nie ujawnia, czy otaczający go system zachowuje użyteczny kontekst, czy wielokrotnie płaci za jego przetworzenie.

Dla pracowników wiedzy zmiana zapowiada szybszą i bardziej zaawansowaną automatyzację przeglądarki. Jej wartość będzie zależeć od tego, czy agenci potrafią zachowywać niezbędne fakty bez ujawniania wrażliwych danych lub błądzenia przez niepotrzebne kroki.

Wynik agenta przeglądarkowego Asany przekonująco pokazuje, że projektowanie kontekstu należy dziś umieszczać obok wyboru modelu w każdej ocenie agentów. Kolejne pytanie brzmi, czy ta lekcja sprawdzi się w chaotycznych przepływach pracy, które klienci faktycznie chcą zautomatyzować.