Ocena i optymalizacja agentów: porównanie DSPy, TextGrad, Reflexion i OPRO

Zespoły rzadko przechodzą od razu do automatycznej oceny i optymalizacji agentów. Zwykła ścieżka jest stopniowa: najpierw przychodzi pomysłowy prompt oraz kilka jednorazowych eksperymentów, potem powtarzalne pomiary, następnie celowe dostosowywania, a na końcu wystarczająca pewność siebie, by wprowadzać zmiany pod kontrolą.

Zazwyczaj wszystko zaczyna się od agenta, który ma silny prompt systemowy, kilka narzędzi oraz imponującą demonstrację. To dobry początek, ale nie rozwiązuje wielu problemów. Gdy coraz więcej osób polega na tym agencie, pytania stają się bardziej praktyczne. Które procesy działają poprawnie, a które zawodzą przy większej skali? Co się dzieje z zachowaniem agenta po aktualizacji podstawowego modelu? Czy agent dobrze radzi sobie w przypadkach najważniejszych dla operacji, kontroli ryzyka czy klientów?

Inżynieria promptów to cenna pierwsza umiejętność, jednak prawdziwa dojrzałość pochodzi z włączenia agenta do zdyscyplinowanego cyklu doskonalenia. Agent, który można ocenić w sposób systematyczny, może być również doskonalony systematycznie, a ten, który można systematycznie ulepszać, daje możliwość znacznie pewniejszego zarządzania nim. Dlatego nagrodą jest coś więcej niż tylko lepsze prompty – to kontrolowany cykl uczenia się dla systemów modeli językowych: określenie, co oznacza „dobro”, pomiar zachowania według tych kryteriów, zastosowanie celowanej optymalizacji oraz przechowywanie wystarczającej ilości danych, by móc ufać wynikom.

Pięć podejść łączy ten sam cel: DSPy z jego optymalizatorami MIPRO i COPRO, TextGrad, Reflexion oraz OPRO. Ich mechanizmy, stopień dojrzałości i zastosowanie różnią się, ale każde odpowiada na jedno pytanie: jak agent może przejść od ręcznych modyfikacji promptów do powtarzalnego, opartego na metrykach doskonalenia?

Ocena znajduje się w centrum każdego cyklu

Najprostszym sposobem na postrzeganie tych metod jako jednej rodziny jest traktowanie ich jako różnych form poszukiwań optymalnego zachowania agenta. Wszystkie one zakładają te same cztery elementy.

• Cokolwiek, co można zmodyfikować: program agenta, instrukcja, proces pracy lub zasada podejmowania decyzji.
• Zbiór zadań, zestaw ocen, który reprezentuje to, co agent powinien robić.
• Kryterium oceny – czy to metryka, rubrykacja, nagroda, czy zasada sukcesu – które odróżnia lepsze od gorszych wyników.
• Optymalizator, jawny lub ukryty, który proponuje zmiany na podstawie wcześniejszych wyników.

Postrzegane w ten sposób, techniki te dotyczą raczej optymalizacji w zamkniętym obiegu niż samego dostarczania instrukcji. W firmie stworzenie lepszej instrukcji rzadko stanowi trudny element; znalezienie powtarzalnego sposobu na poprawę zachowania agenta w wielu zadaniach jest trudniejsze, ponieważ każdy postęp ma swoją cenę w innej dziedzinie:

• dokładność wobec opóźnienia

jakość w stosunku do wydatków

zakres ochrony przed nadnadawaniem

autonomia wobec kontroli

szeroka uniwersalność w porównaniu z dostosowaniem do konkretnych zadań

lokalnie udoskonalony krok w zamian za niezawodność całego systemu

Dlatego te biblioteki lepiej interpretować jako pozycje w przestrzeni projektowej służącej do udoskonalania agentów, a nie jako konkurencyjne sztuczki związane z promptami.

Dlaczego presja rośnie

Początkowe projekty agentów w przedsiębiorstwach zwykle opierają się na intuicji ekspertów. Doświadczony specjalista przepisuje prompty, dostosowuje opisy narzędzi, dodaje przykłady i ponownie przeprowadza testy, aż wynik będzie wydawał się akceptowalny. W przypadku jednego lub dwóch scenariuszy użytkowania to wystarcza.

Występują problemy, gdy kilka zespołów jednocześnie buduje agenty, gdy prompty różnią się pomiędzy środowiskami, gdy dane oceny są rozproszone, gdy zespoły mają różne koncepcje jakości, gdy aktualizacja modelu zmienia jego zachowanie w nieprzewidywalny sposób lub gdy ślady audytu i poziom pewności wypuszczenia zaczynają mieć znaczenie.

Wtedy potrzebna jest dyscyplina przypominająca MLOps, dostosowana do systemów opartych na modelach językowych. Zwykłe testowanie oprogramowania jest konieczne, ale niewystarczające, a klasyczna ocena modeli ML pomaga, choć nie obejmuje wszystkiego. Agenty dodają własne elementy: prompty, wywołania narzędzi, zachowanie przy wyszukiwaniu informacji, strukturę planowania, pamięć, próby ponowne oraz wrażliwość na konkretny model. Automatyczna ocena i optymalizacja dostarczają praktycznych narzędzi do kontrolowania tej zmienności.

Cztery główne techniki

DSPy z MIPRO i COPRO: optymalizacja programu

Wśród tych narzędzi DSPy najbardziej przyspiesza proces programowania zachowania modelu zamiast stosowania rozwiązań improwizowanych. Prompty przestają być jednorazowymi ciągami znaków, a łańcuchy przetwarzania są deklarowane w sposób uporządkowany, co daje możliwość skutecznej optymalizacji.

MIPRO i COPRO to zautomatyzowane optymalizatory w tym ekosystemie. MIPRO dostosowuje prompty, instrukcje oraz przykłady działania modelu na podstawie określonej metryki i nadaje się dla zespołów, których definicja zadań jest dość stabilna i które chcą, aby algorytm znalazł lepsze ustawienia promptów niż człowiek ręcznie. COPRO również doskonali prompty i programy w podobny sposób. Podstawowa idea jest ta sama: program staje się obiektem, który można skompilować, dostosować i ponownie ocenić, a nie tylko edytować ręcznie.

W praktyce oznacza to automatyczne kompilowanie promptów, możliwość wyboru przykładów typu few-shot, dostosowywanie instrukcji, ulepszenia kierowane metrykami oraz wyraźniejsze oddzielenie logiki zadania od ostatecznie zoptymalizowanego promptu. Korzyścią jest możliwość powtarzalności, solidniejsza baza do oceny offline, mniejsza zależność od indywidualnego projektowania promptów oraz optymalizacja przypominająca działania inżynierskie, a nie praktyki oparte na przesądach.

Dla firmy szukającej poważnego wewnętrznego procesu optymalizacji zamiast zbioru ręcznie tworzonych promptów, DSPy należy do najskuteczniejszych rozwiązań, szczególnie przy zadaniami pasujących do powtarzalnych modułów i stabilnych metryk. Ma jednak swoje ograniczenia – działa najlepiej, gdy zadanie jest na tyle ustrukturyzowane, by zbiór danych do oceny mógł kierować procesem poszukiwań, i nie jest tak „cudowne”, na jakie wygląda. Przy słabym, częściowym lub niezgodnym sygnale optymalizator po prostu lepiej radzi sobie z niewłaściwymi rozwiązaniami.

TextGrad: krytyka jako gradient

TextGrad obiera śmielejszą drogę. Zamiast gradientów liczbowych polega na pisemnej krytyce oraz sygnałach aktualizacji w celu udoskonalenia promptów i komponentów przypominających prompty. Rozumowanie jest eleganckie: jeśli model potrafi wskazać, co jest nie tak z wynikiem i jak to naprawić, te komentarze mogą służyć jako sygnał optymalizacyjny.

Umożliwia wielokrotne udoskonalanie tekstu promptu, aktualizacje w stylu optymalizatora oraz pracę nad promptami systemowymi, rubrykami, planami, a nawet instrukcjami oceny. Optymalizacja staje się procesem iteracyjnym zamiast pojedynczym poszukiwaniem. Pasuje do przypadków, gdy właściwa informacja zwrotna jest łatwiejsza do sformułowania słowami niż liczbami, i może poprawić zarówno rubrykę oceniającego, jak i prompt zadania.

Najlepiej postrzegać go jako obiecujący narzędzie wstępne, a nie gotowe rozwiązanie dla całej organizacji. Jest przydatny tam, gdzie zespoły chcą udoskonalać instrukcje, plany oraz kryteria oceny za pomocą informacji zwrotnych opartych na języku, ale nie stanowi oczywistego standardu dla całej struktury organizacyjnej. Jego główna zaleta jest jednocześnie jego największym zagrożeniem: sygnałem do aktualizacji jest sam język, wytwarzany przez model. Bez zdyscyplinowanego mechanizmu oceny może to sprawić, że optymalizacja stanie się mniej stabilna, trudniejsza do zinterpretowania i bardziej skomplikowana pod względem audytu.

Refleksja: uczenie się na podstawie nieudanych prób

Refleksja różni się od dwóch poprzednich rozwiązań. Jej celem nie jest kompilacja instrukcji offline. Chodzi tu o samodoskonalenie w trakcie działania, napędzane refleksją nad niepowodzeniami. Po nieudanej próbie agent pisze krytykę, a ta zapamiętana refleksja kieruje późniejsze próby. Rezultatem jest prosty cykl uczenia się, który nie wymaga dopracowywania modelu.

Zawiera możliwość ponownej próby z samokrytyką, pamięć o wcześniejszych błędach, korektę trajektorii agenta oraz adaptację w trakcie poszczególnych prób. Wiele problemów związanych z agentami wcale nie jest problemami szybkiego reagowania; to problemy związane z wykonywaniem zadań, takie jak błędne kroki rozumowania, niewłaściwe użycie narzędzi lub pominięcie sprawdzeń, a refleksja pomaga przezwyciężyć te trudności. Ponadto przybliża proces uczenia się do rzeczywistych warunków operacyjnych bardziej niż same testy offline.

Dla agentów, które działają jako procesy pracy zamiast generatorów jednorazowych odpowiedzi, refleksja ma ogromne znaczenie, szczególnie tam, gdzie ponowna próba jest możliwa finansowo, a identyfikacja powtarzających się wzorców błędów dodaje wartości. Zazwyczaj przybiera postać wzorca zaimplementowanego w kodzie, a nie jednej kanonicznej biblioteki, dlatego firma powinna traktować ją jako wzorzec projektowy do standaryzacji w swojej warstwie orkiestracji, a nie jako decyzję dostawcy. Zagrożeniem jest nadmiar informacji – nieograniczona samokrytyka powoduje opóźnienia, wzrost kosztów i brak spójności. Refleksja powinna być kierowana zasadami, uruchamiana selektywnie i oceniana tak jak każde inne zachowanie.

OPRO: model jako optymalizator

OPRO, skrót od Optimization by PROmpting, sprawia, że modelem optymalizującym staje się model językowy. Proponuje lepsze warianty promptów na podstawie historii wcześniejszych wyników, dzięki czemu jeden model przeszukuje zbiór instrukcji przeznaczonych dla innego modelu lub programu.

Obejmuje szybkie wyszukiwanie, generowanie kandydatów i ich ranking oraz iteracyjne ulepszanie. Jego logika opiera się na fakcie, że modele językowe dobrze radzą sobie z proponowaniem alternatywnych sformułowań, dzięki czemu szybko powstaje zróżnicowany przestrzeń wyszukiwania, a podejście to dostosowuje się do wielu rodzajów zadań.

OPRO jest strategicznie interesujące, choć często należy do zestawu narzędzi eksperymentalnych, a nie do standardowej platformy. Zazwyczaj pojawia się w kodzie o charakterze badawczym lub w spersonalizowanych pętlach, a nie w standaryzowanej bibliotece produkcyjnej. Najlepszym zastosowaniem może być jego użycie jako skontrolowanego komponentu wyszukiwania w ramach większej usługi optymalizacyjnej, a nie jako samodzielnej funkcji oferowanej bezpośrednio programistom.

Dwa sposoby sortowania opcji

Techniki te można uporządkować według dwóch osi: miejsca, w którym odbywa się optymalizacja, oraz tego, co jest poddawane optymalizacji.

Ze względu na lokalizację:

• Optymalizacja offline obejmuje DSPy z użyciem MIPRO i COPRO, TextGrad oraz OPRO.
• Adaptacja w czasie wykonywania lub na poziomie poszczególnych epizodów to obszar zastosowania Reflexion.
• Możliwy jest również tryb hybrydowy, ponieważ sygnały z procesów Reflexion mogą być zbierane offline i wprowadzane do pętli w stylu DSPy-, TextGrad- lub OPRO.

Ze względu na cel:

• Tekst promptu oraz instrukcje są obsługiwane przez MIPRO, COPRO, TextGrad i OPRO.
• Przykłady typu few-shot są dostosowywane za pomocą MIPRO i COPRO.
• Struktura programu oraz komponenty pipeline należą do szerszego ekosystemu DSPy.
• Trajektorie wykonywania oraz naprawa błędów to domena Reflexion.

Wzorzec obu tabel polega na tym, że te metody uzupełniają się nawzajem, pod warunkiem że znajdują się w odpowiedniej architekturze sterowania.

Kontynuuj pomiarowanie i doskonalenie jako odrębne warstwy

Najdroższy błąd architektoniczny polega na wprowadzaniu optymalizacji zanim powstanie niezawodna praktyka oceny. Przy słabej ocenie optymalizacja staje się niebezpieczna, ponieważ narzędzie optymalizacyjne poprawia wszystko, co mu zostanie podane, włączając elementy niespowiązane z rzeczywistą wartością biznesową. Dobry projekt dzieli się na dwie warstwy.

Struktura oceny definiuje i przeprowadza pomiary. Powinna zawierać zestawy danych referencyjnych oraz reprezentatywne zadania, metryki i kryteria specyficzne dla poszczególnych zadań, zapisane ślady trajektorii agentów, wskaźniki kosztu, opóźnienia i niezawodności, analizę na poziomie poszczególnych grup lub trybów awarii, a także mechanizmy weryfikacji z wykrywaniem regresji.

Materiał optymalizacyjny bierze pod uwagę wyniki oceny i proponuje oraz weryfikuje ulepszenia. Jego zakres obejmuje: dostosowywanie promptów, wybieranie przykładów, ustalanie zasad refleksji w czasie wykonywania, generowanie i wyszukiwanie kandydatów, jednoczesne śledzenie eksperymentów oraz reguły promocji decydujące o tym, kiedy obiecujący kandydat staje się zatwierdzoną domyślną opcją.

Rozróżnienie to jest ważne, ponieważ ocena stanowi funkcję zarządzania, natomiast optymalizacja jest mechanizmem zmian. Firma potrzebuje obu tych elementów, a ich pomieszanie jest błędem.

Ograniczona lista kandydatów

W przypadku praktycznego zestawu narzędzi korporacyjnych, w odróżnieniu od podejścia akademickiego, lista kandydatów powinna być ściśle określona. Nie każda obiecująca idea badawcza zasługuje na to, by stać się kluczowym elementem platformy pierwszej klasy.

DSPy jako główne narzędzie optymalizacji. Zapewnia najsolidniejszą strukturę do traktowania programów modeli jako artefaktów, które można optymalizować. MIPRO i COPRO bezpośrednio odpowiadają praktycznej regulacji promptów i przykładów, a całe to podejście lepiej pasuje do powtarzalnych procesów wewnętrznych niż do ad hoc promptowania. Jego rolą jest bycie domyślnym silnikiem do zadań stabilnych, podstawą do kompilacji promptów offline oraz głównym narzędziem abstrakcji dla zespołów, które chcą osiągać powtarzalne rezultaty oparte na metrykach.

Refleksja jako standardowy wzorzec działania w czasie rzeczywistym. Nie musi być samodzielną zależnością. Rozwiązuje inne problemy niż DSPy, a mianowicie przywracanie stanu po awarii podczas wykonywania, oraz pomaga agentom korzystającym z narzędzi i wieloetapowym procesom pracy. Może być włączona do warstw orkiestracji takich jak LangGraph lub zwykłe silniki Pythona. Jej rola to: selektywna polityka ponawiania prób z refleksją dla agentów procesowych, źródło strukturyzowanych danych o błędach do późniejszej optymalizacji offline oraz standardowy sposób przeprowadzania ograniczonej samokorekcji.

TextGrad jako zaawansowana, eksperymentalna opcja. Oferuje nowatorski prymityw udoskonalania, który nadaje się do promptów, rubryk lub planów, które korzystają z iteracji opartej na krytyce. Najlepiej jest go dodawać po stworzeniu stabilnego narzędzia do oceny. Jego rola to specjalistyczne narzędzie dla zespołów optymalizacyjnych, stosowane tam, gdzie pisemna informacja zwrotna jest bardziej wartościowa niż prosty wynik.

OPRO, niższy priorytet jako standard platformy. Często jest lepszy jako tryb optymalizacji wewnętrznej niż jako wybór biblioteki centralnej. Wiele z jego koncepcji można odtworzyć za pomocą dostosowanych pętli wyszukiwania w ramach silniejszej struktury oceny, a dla przeciętnych programistów stanowi mniej naturalny standard domyślny. Jeśli zostanie użyty, powinien służyć jako strategia wyszukiwania w ramach centralnej usługi optymalizacji lub jako narzędzie do eksperymentowania dla zespołów platformowych.

Nad czym budować

Rozwijający nie powinni musieć na każdym projekcie kompilować te techniki z surowych bibliotek. Większość zespołów nie ma potrzeby korzystania z pięciu paradygmatów optymalizacji na warstwie aplikacji. Potrzebują prostszego, wewnętrznego frameworku, który określa, jak mierzy się jakość agenta, ją poprawia i promuje. Rozsądnym rozwiązaniem jest lekka, ale sprecyzowana platforma wewnętrzna zbudowana na wybranej grupie bibliotek. Powinna ona ukrywać niepotrzebną złożoność, jednocześnie standaryzując istotne mechanizmy kontroli.

1. SDK do oceny. Jedyny wspólny sposób na definiowanie zadań agenta, zestawów danych i metryk. Standaryzuje on schemat przypadków testowych, oczekiwane wyniki lub kryteria oceny, format logowania śledzenia, rejestrowanie kosztów i opóźnień, wersjonowanie zestawów danych oraz bazy odniesienia dla testów regresji. Celem jest to, aby zespół mógł opisać swego agenta, zestaw do oceny oraz mierniki sukcesu bez konieczności pisania specjalistycznego narzędzia.

Usługa optymalizacji. To kontrolowana usługa, która wykonywać zadania optymalizacyjne, dzięki czemu zespoły nie muszą samodzielnie konfigurować swoich pętli. Umożliwia dostosowywanie promptów i przykładów na podstawie DSPy, opcjonalne udoskonalanie za pomocą TextGrad, opcjonalne wyszukiwanie inspirowane OPRO, porównywanie eksperymentów z raportowaniem w stylu tabeli liderów oraz procesy zatwierdzania kandydatów. Programista może poprosić o dostosowanie agenta do określonej wersji zestawu danych, w ramach ustalonych ograniczeń czasu reakcji i kosztów, i otrzymać kandydatów, które można porównywać bezpośrednio.

Szyna polityk refleksji w czasie wykonywania. Zachowanie przypominające refleksję staje się elementem konfiguracji zamiast kodu dostosowanego indywidualnie w każdym agencie. Polityki określają, kiedy dozwolone są ponowne próby, kiedy aktywuje się refleksja, ile prób jest dozwolonych, jakie informacje o wcześniejszych błędach są przechowywane oraz kiedy należy przekazać sprawę osobie lub użyć alternatywnego procesu pracy. Dzięki temu zespoły mogą samodzielnie korygować błędy przy użyciu szablonów i unikają tworzenia niespójnej logiki ponownych prób.

Rejestr promptów i polityk. Prompty, rubryki oraz elementy optymalizacji są traktowane jako zarządzane zasoby: przechowywane w wersjach, z określoną ścieżką od promptu przez eksperyment aż do wersji produkcyjnej, z adnotacjami dotyczącymi kompatybilności modeli, obsługą cofania zmian oraz zapisami zatwierdzeń dla wariantów produkcyjnych. Prompty funkcjonują więc jak konfiguracja nadająca się do wdrożenia, a nie jako tekst kopiowany między notatkami a repozytoriami.

Łączenie z planem kontroli przedsiębiorstwa. Ta platforma łączy się z bramkami CI/CD, narzędziami do obserwowalności, katalogami modeli, zarządzaniem sekretami i środowiskami, mechanizmami kontroli nad zarządzaniem danymi oraz procesami zatwierdzania w przypadkach wysokiego ryzyka. To połączenie odróżnia bibliotekę technik od realnej zdolności przedsiębiorstwa.

Dla większości programistów powinno to sprowadzać się do czterech kroków: zdefiniowanie umowy agenta, dostarczenie przypadków oceny, wybór trybu optymalizacji oraz przejrzenie wybranego kandydata wraz z raportem jego wdrożenia. W rzeczywistości może być używana każda z tych czterech technik, ale to, co widzą programiści, powinno pozostać proste. Problem skalowania rzadko wynika z braku algorytmów – chodzi raczej o rozprzestrzenianie się specjalistycznych, niespójnych pętli doskonalenia pomiędzy zespołami.

Stopniowe wdrażanie

Etap pierwszy: dyscyplina oceny. Przed jakąkolwiek szeroko zakrojoną optymalizacją należy ustalić wspólne schematy oceny, starannie dobrane zbiory danych referencyjnych, mechanizmy rejestrowania i odtwarzania działań oraz bazowe wartości dotyczące kosztów, opóźnień i jakości zadań.

Etap drugi: optymalizacja offline z użyciem DSPy. Należy uczynić z połączenia DSPy, MIPRO i COPRO główną metodę dla stabilnych klas zadań, obejmującą kompilację poleceń, wybór przykładów, dostosowywanie instrukcji oraz powtarzalne porównywanie eksperymentów.

Etap trzeci: refleksja podczas wykonywania z ograniczeniami czasowymi. Należy zastosować polityki w stylu Reflexion dla agentów, których błędy można często naprawić poprzez ponowną próbę z analizą błędu, selektywne próby, strukturyzowaną pamięć refleksji oraz diagnostykę na poziomie ścieżki wykonywania zadań.

Etap czwarty: zaawansowane tryby, z umiarem. Dodawaj funkcje takie jak TextGrad oraz wyszukiwanie podobne do OPRO tylko wtedy, gdy istnieje wyraźna potrzeba i ocena jest na tyle dojrzała, by je kontrolować. Zazwyczaj powinno to pozostać funkcją zespołu platformy, zanim trafi do ogółu programistów.

Gdzie pojawiają się problemy

• Nadmierna dostosowalność do metryk. Ograniczony lub przestarzały punkt odniesienia uczy optymalizatora właśnie tego punktu, a nie rzeczywistego zadania.
• Kruchość kryteriów oceny. Jeśli ocena opiera się na słabych lub niespójnych modelach oceniających, optymalizacja podąża za osobliwościami tych oceniających.
• Miejskie zwycięstwa, globalne straty. Dostosowywanie jednego z podzadań może potajemnie zwiększyć koszty lub spowolnić inne kroki, albo zmienić zachowanie reszty procesu pracy.
• Zbyt głośna refleksja. Refleksja bez określonych ograniczeń polityki generuje więcej tokenów i opóźnień przy niewielkiej rzeczywistej korzyści.

Fragmentacja organizacyjna. Gdy każdy zespoł wybiera własne biblioteki optymalizacji oraz konwencje oceny, firma traci możliwość porównywania i kontrolę.

Wszystko to prowadzi do tego samego wniosku: efektywność optymalizacji zależy wyłącznie od metod oceny i mechanizmów zarządzania nią.

Kształt rozwiązania

To, co łączy DSPy, MIPRO, COPRO, TextGrad, Reflexion i OPRO, to nie fakt, że każdy z nich poprawia prompty. Każdy z nich stara się przekształcić proces doskonalenia agentów w system sprzężenia zwrotnego. Strategicznym krokiem nie jest prezentowanie każdej idei każdemu programiście, lecz tworzenie kontrolowanego, wewnętrznego frameworku, w którym ocena jest standaryzowana, optymalizacja selektywna, refleksja w czasie wykonywania działań odbywa się zgodnie z ustalonymi zasadami, a warianty promptów są zarządzane jak zasoby produkcyjne.

Aby uzyskać bardziej precyzyjne rekomendacje, najlepszym podejściem jest powierzenie DSPy w połączeniu z MIPRO i COPRO zadania optymalizacji offline, przyjęcie Reflexion jako standardowego wzorca działania w czasie rzeczywistym dla ograniczonej samokorekcji, przeznaczenie TextGrad dla zespołów specjalistycznych oraz traktowanie OPRO głównie jako techniki wewnętrznego wyszukiwania, a nie jako zależności przeznaczonej dla programistów. Zwycięzców wśród agentów korporacyjnych będzie decydować jakość pętli zwrotnej wokół nich, przy czym szybkość i pomysłowość mają znacznie mniejsze znaczenie.