Benchmark DuoCook: wiodący model AI realizuje zaledwie 26,2% zamówień

Benchmark DuoCook stawia AI na czele wirtualnej kuchni, gdzie jego najsilniejszy testowany model zrealizował średnio 26,2% zamówień. Wynik ten podważa praktyczne założenie stojące za autonomicznymi asystentami: zrozumienie zadania powinno przekładać się na organizację pracy potrzebnej do jego ukończenia.

Preprint z 22 października opisuje środowisko inspirowane Overcooked, a nie bezpośredni test komercyjnej gry. Dwoma kucharzami steruje model wizualno-językowy, czyli system AI przetwarzający obrazy i tekst. Główny konflikt dotyczy wyboru wiarygodnych pojedynczych działań oraz ukończenia wzajemnie zależnego obciążenia pracą.

Wcześniejsze systemy, w tym MindAgent i Collab-Overcooked, już uczyniły wirtualne kuchnie poligonem testowym dla koordynacji agentów AI. DuoCook dodaje kolejny powód, by dokładnie analizować wykonanie. Dla deweloperów i kupujących użyteczne pytanie dotyczy tego, na ile niezawodnie asystent przekuwa swoje decyzje w ukończoną pracę.

Co faktycznie mierzy benchmark DuoCook

Wynik dotyczy skoordynowanego wykonywania zadań w określonym interfejsie, więc jego znaczenie zależy od sposobu działania testu.

Badacze ocenili cztery modele na 20 mapach w pięciu kategoriach. GPT-6-Astra osiągnął najlepszy zgłoszony wynik ukończenia; pozostałe modele uzyskały średnio od 8,8% do 11,2%. Benchmark DuoCook zapewnia ustrukturyzowane informacje i pomoc w nawigacji, a symulacja zostaje wstrzymana podczas wnioskowania modelu.

Te szczegóły pomagają zdefiniować to twierdzenie. Benchmark gotowania AI może testować różne kombinacje percepcji, ruchu, harmonogramowania i współpracy. Zmiana tej kombinacji zmienia to, co niski wynik mówi czytelnikom. System mający trudności z rozpoznaniem składnika stwarza inny problem inżynieryjny niż system, który wielokrotnie przydziela pracę w niewłaściwej kolejności.

Rozważmy hipotetyczną kuchnię, w której jeden kucharz przygotowuje warzywa, a drugi obsługuje garnek. Każde przydzielenie zadania brzmi rozsądnie w izolacji. Warzywa mogą jednak należeć do zamówienia, którego nie da się ukończyć przed terminem. Tymczasem garnek może zajmować sprzęt potrzebny do przygotowania łatwiejszego dania.

Istotna decyzja dotyczy relacji między tymi działaniami. Użyteczny kontroler musi uwzględniać, co dane działanie umożliwia, co opóźnia oraz czy jego wynik pozostaje użyteczny. Rozpoznanie właściwego składnika dostarcza jedynie części potrzebnej informacji.

Dlatego wskaźnik ukończenia zasługuje na uwagę wykraczającą poza jego rozrywkową wartość. Zrealizowane zamówienia stanowią wynik, który czytelnicy mogą zrozumieć bez interpretowania rozbudowanego wyjaśnienia. Kuchnia albo otrzymuje wymaganą sekwencję pracy, albo jej nie otrzymuje.

Mimo to czytelnicy powinni powstrzymać się przed traktowaniem 26,2% jako uniwersalnego wskaźnika sukcesu AI. Zgłoszona liczba podsumowuje wyniki w ocenianym zestawie. Nie opisuje każdej możliwej kuchni, każdej architektury agentów ani każdej wersji testowanych modeli.

Nie określa też, jak człowiek poradziłby sobie w tym samym interfejsie. Znajomo wyglądająca gra może skłaniać do intuicyjnego porównania, którego projekt eksperymentu niekoniecznie wspiera. Doświadczenie człowieka z komercyjną wersją gry nie zapewnia automatycznie porównywalnej wartości bazowej.

Użyteczna interpretacja jest węższa i bardziej konkretna. W konfiguracji badaczy pozostaje znaczna luka między wydawaniem decyzji a ukończeniem przydzielonego obciążenia pracą. Luka ta daje kolejnym eksperymentom coś konkretnego do zbadania.

Zmienia też to, co powinna wykazać imponująca demonstracja. Przekonujące wyjaśnienie kolejnego ruchu nie jest wystarczającym dowodem niezawodnego wykonania. Ocena musi śledzić cały łańcuch aż do końcowego rezultatu, w tym konsekwencje wcześniejszych wyborów.

Dla czytelników obserwujących autonomiczne oprogramowanie to rozróżnienie stanowi punkt wyjścia historii. Kuchnia nadaje widzialną formę szerszemu problemowi oceny: ustaleniu, czy lokalnie sensowne zachowanie przynosi rezultat, o który prosił użytkownik.

Dlaczego niedokończone zamówienia wywierają presję na twórców agentów

Praktyczna presja spoczywa na zespołach obiecujących, że asystent potrafi zarządzać zależnościami bez stałej interwencji człowieka.

Asystent może udzielać użytecznych sugestii, pozostawiając koordynację użytkownikowi. Gdy przyjmuje odpowiedzialność za wykonanie, standard się zmienia. Musi zachować cel użytkownika przez decyzje pośrednie, przerwania i konkurujące wymagania.

Wyobraźmy sobie asystenta przygotowującego aktualizację projektu. Musi zebrać materiały źródłowe, zidentyfikować zmiany, rozstrzygnąć sprzeczne stwierdzenia i przygotować dokument. Każdy etap może wyglądać na udany, podczas gdy całe zadanie pozostaje nieukończone.

Zebrany dokument może być nieaktualny. Trafne podsumowanie może pominąć decyzję zmieniającą rekomendację. Dopracowany szkic może dotrzeć po spotkaniu, na którym był potrzebny. To przykłady hipotetyczne, ale wyjaśniają różnicę między jakością komponentów a jakością przepływu pracy.

Porównanie z kuchnią staje się użyteczne na tym poziomie. Jego znaczenie wynika z zależności, a nie z twierdzenia, że gotowanie i praca biurowa mają identyczny poziom trudności. Oba mogą wymagać od kontrolera zdecydowania, co musi wydarzyć się, zanim kolejne działanie stanie się opłacalne.

Dla deweloperów sugeruje to bardziej wymagający test akceptacyjny. Zadanie powinno pozostawać oceniane po tym, jak model wygeneruje wiarygodną instrukcję. Test powinien trwać, aż środowisko potwierdzi istnienie oczekiwanego rezultatu.

Takie podejście zmienia również sposób, w jaki zespoły diagnozują błędy. Nieukończone zadanie może wynikać z błędnej obserwacji, nieprawidłowego polecenia, złego priorytetu lub niewykorzystanej okazji do odzyskania kontroli. Traktowanie wszystkich tych przypadków jako ogólnej porażki rozumowania utrudnia poprawę.

Zespoły produktowe stoją przed powiązanym wyborem projektowym dotyczącym odpowiedzialności. Muszą określić, kiedy asystent działa niezależnie, kiedy weryfikuje postęp, a kiedy prosi o pomoc. Decyzje te kształtują to, czy błąd pozostaje ograniczony, czy wpływa na późniejszą pracę.

Widoczny punkt kontrolny może ułatwić nadzorowanie przepływu pracy. Na przykład asystent mógłby potwierdzić istnienie wymaganych danych wejściowych przed rozpoczęciem zależnego działania. Ta propozycja jest odpowiedzią inżynieryjną na problem koordynacji, a nie wynikiem ustalonym przez to badanie.

Kupujący powinni podobnie pytać, co demonstracja pozostawia człowiekowi do zarządzania. Ktoś może po cichu naprawiać brakujące dane wejściowe, resetować nieudane kroki lub wybierać kolejny cel. Takie interwencje mogą być cenne, ale powinny należeć do opisu wyników.

Presja jest więc natychmiastowa dla projektowania ewaluacji, nawet jeśli szersze konsekwencje komercyjne pozostają niepewne. Zespoły mogą definiować kryteria ukończenia i rejestrować wymagania dotyczące interwencji przed formułowaniem twierdzeń o ogólnej autonomii.

Pracownicy wiedzy mają prostsze pytanie: co dzieje się, gdy pierwotny plan przestaje odpowiadać rzeczywistości? Sposób, w jaki asystent radzi sobie w tym momencie, może mieć większe znaczenie niż pewność jego początkowej odpowiedzi.

Koordynacja agentów AI staje się wymogiem produktowym, gdy użytkownicy delegują rezultaty. Istotne dowody muszą pokazywać, jak system zarządza niedokończoną pracą, a nie tylko jak przekonująco opisuje pracę, która jest przed nim.

Przekonujące kolejne działanie nie gwarantuje ukończenia zadania

Kluczowe odwrócenie polega na tym, że działanie może być poprawne samo w sobie, a mimo to podważać ogólny cel.

Wcześniejsze badania dostarczają użytecznego kontekstu dla tego rozróżnienia. Framework MindAgent badał modele językowe jako koordynatory w CuisineWorld, wirtualnym środowisku gotowania. Jego autorzy zgłosili zdolności harmonogramowania oraz poprawę dzięki demonstracjom, podpowiedziom i informacji zwrotnej.

Praca ta oferuje konstruktywną perspektywę na ewaluacje kuchenne. Słaby wynik nie wymaga wniosku, że koordynacja jest niedostępna dla modeli językowych. Może natomiast motywować eksperymenty z instrukcjami, informacją zwrotną i strukturą sterowania, które je otaczają.

Jednak możliwość poprawy nie rozstrzyga, czy konkretny system jest niezawodny. Proponowana metoda wymaga oceny na podstawie ukończonych zadań w jasno określonych warunkach. Lepsze wyjaśnienia i lepsze rezultaty pozostają odrębnymi twierdzeniami.

Badanie Collab-Overcooked analizuje inną część tego problemu. Jego autorzy zgłosili trafną interpretację celów przy jednoczesnych niedociągnięciach w aktywnej współpracy i ciągłej adaptacji. Benchmark wykorzystuje ewaluację zorientowaną na proces, aby badać zachowanie wykraczające poza końcowy rezultat.

Wyniki te pomagają ustalić główne porównanie: rozpoznanie tego, co powinno się wydarzyć, versus utrzymanie zachowania, które to umożliwia. DuoCook należy do tej dyskusji, choć jego scentralizowany kontroler różni się od systemów obejmujących niezależnie sterowanych współpracowników.

Hipotetyczny przykład czyni to rozróżnienie konkretnym. Załóżmy, że kontroler prawidłowo rozpoznaje, iż zupa potrzebuje kolejnego składnika. Wysłanie kucharza po niego wydaje się pomocne. Podróż może jednak opóźnić inne zamówienie, którego pozostałe przygotowanie jest już ukończone.

Kontroler staje wtedy przed decyzją harmonogramową, czyli wyborem dotyczącym czasu i przydziału pracy. Najlepsza odpowiedź zależy od otaczającego obciążenia pracą. Sama wiedza o przepisie nie może tego rozstrzygnąć.

Ten sam problem pojawia się, gdy działanie zmienia opcje innego pracownika. Zarezerwowanie sprzętu może uprościć jedno zadanie, jednocześnie uniemożliwiając postęp gdzie indziej. Przydzielenie obu pracowników do tego samego celu może przyspieszyć przygotowanie, pozostawiając dostawę bez obsługi.

Przykłady te pokazują, dlaczego ocena izolowanych działań może pominąć główną trudność. Wartość decyzji zależy częściowo od przyszłych działań, które umożliwia. Relacja ta staje się trudniejsza do oceny, gdy środowisko zmienia się podczas wykonywania zadania.

Istnieje też problem odzyskiwania kontroli. Gdy wcześniejsze założenie zawiedzie, kontynuowanie pierwotnego planu może marnować dodatkowy wysiłek. Zdolny kontroler potrzebuje sposobu, by rozpoznać, że zamierzona sekwencja nie służy już celowi.

Dla zespołów inżynieryjnych sugeruje to porównywanie alternatywnych podejść przy tym samym obciążeniu pracą. Model ogólny można połączyć z jawnym śledzeniem zadań, rezerwacjami zasobów lub oddzielnym komponentem harmonogramowania. Są to propozycje do przetestowania, a nie poprawki ustalone przez artykuł.

Porównanie powinno zachować rezultat widoczny dla użytkownika. Jeśli dodatkowy komponent poprawia ukończenie zadań, wymagając przy tym mniej interwencji, ma to znaczenie. Jeśli produkuje jedynie bardziej szczegółowe pośrednie rozumowanie, jego praktyczna wartość pozostaje nierozstrzygnięta.

W tym miejscu badanie stawia użyteczne wyzwanie twórcom agentów. Celem jest połączenie osądu z wykonaniem w całym zadaniu, w tym w punktach, w których rozsądne wybory wchodzą ze sobą w konflikt.

Dodatkowa pamięć wprowadza kolejny problem decyzyjny

Pamięć musi poprawiać decyzje kontrolera; samo zachowywanie większej ilości informacji nie dowodzi jeszcze takiej korzyści.

Eksperyment DuoCook porównuje również wspólny notatnik z warunkiem zachowującym historię ostatnich działań. Zgłoszone efekty dla wyników różnią się między modelami: Claude i Qwen poprawiają się średnio, podczas gdy GPT i Gemini odnotowują spadek. Średni koszt wywołań modelu rośnie dla każdego modelu.

To komplikuje znany odruch projektowy. Gdy asystent traci wątek pracy, dodanie pamięci wydaje się bezpośrednią odpowiedzią. System pamięci wprowadza jednak decyzje dotyczące tego, co zapisywać, co odzyskiwać i kiedy to aktualizować.

Rozważmy hipotetyczną notatkę informującą, że stanowisko robocze jest zajęte. Obserwacja mogła być trafna w chwili zapisu. Jeśli sytuacja się zmieni, ta sama notatka może stać się przeszkodą, o ile kontroler jej nie sprawdzi ani nie zaktualizuje.

Problem dotyczy relacji między obserwacją a bieżącym środowiskiem. Zapamiętane stwierdzenie potrzebuje wystarczającego kontekstu, aby asystent mógł ocenić, czy nadal ma zastosowanie. W przeciwnym razie trwałość danych może utrwalać błąd lub przedłużać życie nieaktualnych informacji.

Dlatego deweloperzy powinni odróżniać przechowywanie danych od zweryfikowanego stanu. Przechowywanie utrzymuje informacje. Zweryfikowany stan przedstawia to, co system sprawdził w odniesieniu do bieżącego zadania. Projekt może zawierać obszerne zapisy, a mimo to nie mieć wiarygodnego obrazu aktualnych postępów.

To rozróżnienie ma znaczenie także w zwykłych procesach pracy z wiedzą. Notatka ze spotkania może trafnie zapisać decyzję, podczas gdy późniejsza wiadomość ją zmienia. Asystent przygotowujący rekomendację musi rozpoznać tę zależność, zamiast traktować oba stwierdzenia jako równie aktualne.

Przeszukiwalna baza wiedzy może pomóc ludziom odnaleźć materiały źródłowe do weryfikacji. Jednak odzyskiwanie istotnych dokumentów i autonomiczne koordynowanie aktywnego procesu pracy wymagają różnych dowodów. Eksperyment kuchenny nie ocenia remio ani nie pozwala wyciągać wniosków o jego funkcjach.

Dla projektantów agentów badanie sugeruje ukierunkowane porównanie. Należy przetestować ten sam proces pracy z proponowaną funkcją pamięci i bez niej. Pozostałe warunki powinny być możliwie spójne, a następnie warto zbadać ukończone rezultaty oraz dodatkową pracę, jakiej wymaga każde rozwiązanie.

Ocena powinna także analizować przypadki, w których pamięć zmienia wynik. Średnia zbiorcza może ujawnić różnicę, nie wyjaśniając jej. Przeczytanie sekwencji obserwacji i działań może pomóc określić, czy zapamiętane stwierdzenie wsparło użyteczną decyzję.

Alternatywne wyjaśnienia również wymagają uwagi. Dodatkowy kontekst może zmienić sposób, w jaki model interpretuje instrukcje lub nadaje priorytety informacjom. Sama różnica wydajności nie wskazuje, który mechanizm ją wywołał.

Właściwy wniosek jest warunkowy: pamięć to komponent, którego wartość zależy od implementacji i sposobu użycia. Notatnik może pomóc kontrolerowi zachować ciągłość, lecz jego użyteczność musi wytrzymać porównanie z prostszą alternatywą.

Dla kupujących oznacza to konieczność pytania, co faktycznie poprawia reklamowana funkcja pamięci. Zapamiętywanie preferencji, odzyskiwanie starego dokumentu i śledzenie zmieniającego się zadania to odrębne możliwości. Każda z nich zasługuje na ocenę dopasowaną do swojego celu.

Dlaczego rankingi pozostają wstępne

Wyniki uzasadniają dalsze badania, lecz projekt badania ogranicza wnioski dotyczące stabilnych rankingów i niezawodności w miejscu pracy.

Każdy model otrzymał jedno uruchomienie dla każdej mapy i warunku pamięci. Autorzy wskazują również, że w obecnych materiałach towarzyszących manuskryptowi brakuje wspierających dzienników epizodów i skryptów analitycznych. Ograniczenia te utrudniają ocenę powtarzalności i szczegółową diagnozę zgłoszonych błędów.

Dopasowany test może mimo to dostarczać użytecznych obserwacji. Zapewnienie systemom porównywalnych warunków początkowych pomaga interpretować zgłaszane różnice. Jednak pojedyncza obserwacja nie może ujawnić, jak konsekwentnie model zachowałby się przy ponownym uruchomieniu tego samego scenariusza.

Dla kupującego wybierającego między produktami konsekwencja działania jest częścią decyzji. System, który czasem kończy zadanie, a czasem się zatrzymuje, wymaga innego poziomu nadzoru niż system o przewidywalnych ograniczeniach. Średnia z rankingu nie opisuje w pełni tego obciążenia.

Osobne pytanie dotyczy tego, co mierzy środowisko. Badanie OvercookedV2 argumentuje, że niepowodzenia we wcześniejszych środowiskach koordynacyjnych mogą odzwierciedlać niewystarczające pokrycie sytuacji napotykanych podczas treningu. Jego autorzy wprowadzili zmiany mające stworzyć bardziej wymagające scenariusze koordynacji.

To perspektywa metodologiczna, a nie bezpośrednia krytyka DuoCook. Przypomina czytelnikom, że widoczne niepowodzenie nie ujawnia automatycznie swojej podstawowej przyczyny. Różne interwencje eksperymentalne mogą prowadzić do odmiennych wyjaśnień zachowania, które początkowo wygląda podobnie.

Na przykład kontroler może mieć trudności, ponieważ nie rozumie interfejsu. Inny może rozumieć interfejs, ale wybrać nieskuteczny harmonogram. Trzeci może potrzebować znanego przykładu, zanim zastosuje dostępną skądinąd wiedzę.

Te hipotetyczne wyjaśnienia wymagają różnych środków zaradczych. Pokazują też, dlaczego niski wynik ukończenia zadania powinien rozpoczynać badanie, a nie je kończyć. Mocne twierdzenia o przyczynie wymagają eksperymentów zaprojektowanych tak, aby odróżniać alternatywy.

Generalizacja tworzy kolejną granicę. Generalizacja oznacza skuteczne działanie poza sytuacjami wykorzystanymi do opracowania lub oceny systemu. Wynik uzyskany w stałym zestawie kuchni nie może sam w sobie potwierdzać wydajności w niepowiązanych rodzajach pracy.

Overcooked Generalisation Challenge ocenia w szczególności współpracę z nieznanymi partnerami w nieznanych środowiskach. Jego autorzy zgłaszają trudności związane z tym połączonym wyzwaniem. Bada więc wymiar odmienny od scentralizowanego sterowania obiema postaciami.

Te kierunki badań powinny się wzajemnie uzupełniać, nie będąc jednak łączone w jeden ranking. Kontroler zarządzający wspólnymi zasobami i agent dostosowujący się do niezależnego współpracownika stoją przed powiązanymi, lecz odrębnymi wymaganiami. Ich wyniki wymagają interpretacji w ramach odpowiednich konfiguracji.

Nazwy modeli również wymagają ostrożności. GPT-6-Astra, Claude, Gemini i Qwen identyfikują systemy oceniane w porównaniu przedstawionym w tej pracy. Wyniki nie ustanawiają uniwersalnego porządku ich możliwości w różnych zastosowaniach.

Najmocniejszy możliwy do obrony wniosek pozostaje konkretny: testowana konfiguracja ujawnia znaczną ilość niedokończonej pracy i rodzi pytania warte powtórzenia. Szersze twierdzenia o inteligencji ogólnej, zastępowaniu ludzi lub nieuchronnym komercyjnym niepowodzeniu wykraczałyby poza dostępne dowody.

Co uczyniłoby kolejne wyniki bardziej przekonującymi

Kolejne użyteczne osiągnięcia to powtarzalne wyniki, jaśniejsze wyjaśnienia niepowodzeń oraz udane testy poza pierwotnym zestawem kuchni.

W ciągu najbliższych kilku miesięcy pierwszym sygnałem wartym obserwacji będzie powtarzana ocena w dopasowanych warunkach. Kolejne uruchomienia powinny pokazać, czy wiodący model utrzymuje przewagę i jak bardzo różnią się wyniki. Stabilne rezultaty wzmocniłyby obecne porównanie; niestabilne osłabiłyby zaufanie do rankingu.

To samo dotyczy ustaleń dotyczących pamięci. Jeśli zgłaszane korzyści i spadki będą się powtarzać, deweloperzy zyskają solidniejsze podstawy do badania zachowań charakterystycznych dla poszczególnych modeli. Jeśli będą często się odwracać, pierwotne średnie będą wymagać bardziej ostrożnej interpretacji.

Powtarzana ocena pomogłaby również czytelnikom odróżnić imponujący epizod od niezawodnego systemu. Udana demonstracja jest użytecznym dowodem, że dane zachowanie może wystąpić. Dostarcza mniej informacji o tym, czy użytkownik może konsekwentnie oczekiwać takiego zachowania.

Drugim sygnałem jest dostępność szczegółowych zapisów wykonania oraz odtwarzalnej analizy. Trajektoria, czyli zarejestrowana sekwencja obserwacji i działań, pomogłaby badaczom zbadać, gdzie postęp się zatrzymuje. Materiały pomocnicze pozwoliłyby także innym sprawdzić, jak obliczono zgłoszone podsumowania.

Zapisy te powinny umożliwiać testowanie konkurencyjnych wyjaśnień. Czy nieprawidłowa obserwacja poprzedziła niepowodzenie? Czy poprawna instrukcja dotarła w niewłaściwym momencie? Czy zapamiętane stwierdzenie było sprzeczne z bieżącą sytuacją?

Odpowiedzi pomogłyby ustalić, czy następny eksperyment powinien zmienić percepcję, harmonogramowanie, informacje zwrotne czy pamięć. Ograniczyłyby również pokusę wyjaśniania każdego niepowodzenia szeroką etykietą, taką jak słabe rozumowanie.

Trzecim sygnałem jest poprawa w nieznanych środowiskach oraz porównywalnych praktycznych procesach pracy. Mocniejszy wynik zachowałby skuteczność ukończenia zadania, gdy zmieniają się układy, zależności lub ograniczenia zasobów. Wzmocniłoby to argument, że poprawa wykracza poza pierwotne przykłady.

Zysk ograniczony do znanych map nadal byłby użyteczny, lecz wspierałby węższe twierdzenie. Deweloperzy powinni odróżniać dostosowanie systemu do znanego testu od poprawy jego zdolności do radzenia sobie z nowymi sytuacjami.

Praktyczne porównania powinny opierać się na tej samej logice. Pilotaż w miejscu pracy potrzebuje własnej definicji zadania, kryteriów ukończenia i zapisu interwencji. Wynik z gotowania nie może zastąpić takiej oceny, niezależnie od tego, czy pilotaż dotyczy badań, przygotowywania dokumentów czy operacji programistycznych.

Dla użytkowników rozsądną odpowiedzią jest wyraźne określenie linii mety. Należy sprecyzować, co musi istnieć po zakończeniu delegowanego zadania i które warunki wymagają przeglądu. Zapewnia to zarówno asystentowi, jak i jego oceniającemu wyraźniejszy cel.

Podczas oceny kolejnego wyniku benchmarku DuoCook należy podążać za dowodami od nagłówkowej liczby do ukończonej pracy. Sprawdź, czy porównanie wykorzystuje dopasowane warunki, czy powtarzane uruchomienia potwierdzają ranking oraz czy szczegółowe zapisy wyjaśniają poprawę. Następnie zapytaj, jak system zachowuje się, gdy zmienia się otoczenie. Zastosuj te pytania do demonstracji asystenta, zanim powierzysz mu dłuższy proces pracy. Przekonujące kolejne działanie może być użyteczne, lecz niezawodne delegowanie wymaga sekwencji, która prowadzi do oczekiwanego rezultatu. Jakie dowody pokazałyby, że asystent potrafi ukończyć Twoje zadanie, odzyskać sprawność, gdy jego plan zawiedzie, i pozostawić Ci mniej pracy koordynacyjnej?