PilotDeck 2.0 Open Source stawia realizację zadań biurowych przed czatem
PilotDeck 2.0 open source zadebiutował 15 października z konkretną obietnicą: utrzymywać spójność pracy agenta przez 2 000 wiadomości interakcji i dostarczać gotowe pliki biurowe. Za wydaniem stoją THUNLP z Uniwersytetu Tsinghua, ModelBest, OpenBMB i AI9Stars. Projekt ma wypełnić trwałą lukę między asystentem, który omawia pracę, a agentem, który niezawodnie ją wykonuje.
To rozróżnienie ma większe znaczenie niż kolejny ranking modeli. PilotDeck zakłada, że użyteczną jednostką pracy AI nie jest odpowiedź, prompt ani pojedyncze wywołanie narzędzia. Jest nią możliwa do odtworzenia przestrzeń robocza zawierająca instrukcje, pliki, pamięć, rejestry wykonania i końcowe artefakty.
Wydanie podważa tym samym dwa utrwalone podejścia. Hostowani asystenci zwykle oferują wygodny dostęp w ramach istniejącego pakietu produktywności. Agenci zorientowani na deweloperów, tacy jak Claude Code i Codex, stawiają na elastyczne wykonanie sterowane narzędziami. PilotDeck próbuje przenieść drugie podejście do powszechnej pracy biurowej, zachowując otwartą warstwę operacyjną i możliwość wyboru modelu.
To atrakcyjna koncepcja, lecz nadal pozostaje deklaracją projektową. Projekt nie opublikował niezależnej oceny pokazującej, że sesja obejmująca 2 000 wiadomości konsekwentnie tworzy poprawne dokumenty, arkusze kalkulacyjne lub prezentacje. Najnowsze badania nad agentami biurowymi sugerują, że trudną częścią nadal pozostaje jakość końcowego rezultatu, a nie długość rozmowy.
PilotDeck 2.0 Open Source zmienia jednostkę pracy agenta
PilotDeck 2.0 traktuje trwałą projektową przestrzeń roboczą, a nie pojedynczy czat, jako podstawowy kontener pracy agenta.
Projektowe otwarte repozytorium opisuje PilotDeck jako zorientowaną na zadania platformę produktywności z agentami AI. Ogłoszenie z 15 października podkreśla instalację jednym kliknięciem, konfigurację wizualną, ciągłość długotrwałych zadań oraz nowe umiejętności dla Worda, Excela i PowerPointa.
Samo oprogramowanie zostało już udostępnione jako open source w maju 2026 roku. Ogłoszenie wersji 2.0 lepiej rozumieć jako rozszerzenie produktu niż pierwsze publiczne wydanie kodu projektu. Przenosi ono akcent z otwartego interfejsu agenta na system mający dostarczać pliki gotowe do użycia w pracy biurowej.
PilotDeck nazywa swoją podstawową jednostkę organizacyjną WorkSpace. Każdy WorkSpace skupia się wokół rzeczywistego katalogu roboczego i łączy pliki projektu, sesje, pamięć, rozszerzenia oraz stan wykonania. Oddzielne sesje mogą współdzielić te same pliki projektu i długoterminowy kontekst, realizując różne cele.
Ta struktura rozwiązuje praktyczny problem długich zadań. Konwencjonalny czat często traci użyteczne szczegóły wraz z rozrastaniem się historii. Ma również słaby związek z bieżącym stanem plików poza rozmową.
PilotDeck zamiast tego zapisuje wiadomości, wyniki narzędzi, stan zadań i wygenerowane artefakty. Dokumentacja wskazuje, że historyczne sesje mogą przywracać swoje ustawienia oraz ostatnio skompresowany kontekst. Agent następnie ponownie odczytuje rzeczywisty katalog roboczy przed kontynuowaniem pracy.
To rozdzielenie jest istotne. Podsumowanie wcześniejszego działania nie dowodzi, że działanie poprawnie zmieniło plik. Ponowne sprawdzenie bieżącego środowiska daje agentowi większą szansę wykrycia tego, co faktycznie się wydarzyło.
Wydanie promuje również umiejętności tworzenia dokumentów Word, arkuszy kalkulacyjnych i prezentacji. Umiejętność to wielokrotnie wykorzystywany zestaw instrukcji zadaniowych i wiedzy operacyjnej. Może wskazywać agentowi, jak analizować materiały źródłowe, tworzyć artefakt i weryfikować wynik.
Takie podejście różni się od dodania trzech przycisków eksportu do chatbota. Kompletne zadanie biurowe może wymagać odczytania kilku plików, wydobycia faktów, obliczenia wartości, przygotowania treści, zastosowania formatowania i sprawdzenia gotowego pakietu. PilotDeck ma utrzymywać te kroki w jednym możliwym do odtworzenia środowisku wykonawczym.
Zapowiedzianą możliwość obsługi 2 000 wiadomości należy interpretować ostrożnie. Odnosi się ona do historii interakcji, którą system, według deklaracji, potrafi zarządzać dzięki budżetowaniu i kompresji kontekstu. Niekoniecznie oznacza 2 000 kolejnych autonomicznych działań bez nadzoru, błędów czy utraty kontekstu.
Ta różnica określa główne napięcie artykułu. Dłuższa ciągłość daje agentowi więcej przestrzeni na ukończenie rzeczywistej pracy. Tworzy też więcej okazji, by błędne założenie, nieaktualny plik lub wadliwy wynik narzędzia wpłynęły na wszystko, co nastąpi później.
Wydanie mimo to zmienia rozmowę o agentach biurowych. Zachęca użytkowników, by oceniali oprogramowanie po artefakcie pozostawionym w przestrzeni roboczej, a nie po płynności jego ostatniej odpowiedzi.
Mechanizm opiera się na pamięci, plikach i możliwym do odtworzenia wykonaniu
Główny argument techniczny PilotDeck brzmi: niezawodne dostarczanie rezultatów wymaga trwałego stanu poza bezpośrednim oknem kontekstu modelu.
Model nie może wiecznie przechowywać każdej wcześniejszej wiadomości, dokumentu i wyniku narzędzia. Każdy model ma okno kontekstu, czyli ograniczoną ilość informacji, które może przetwarzać podczas jednego żądania. Długotrwale działające agenty muszą decydować, co zachować, skompresować, odzyskać lub przechować gdzie indziej.
Architektura produktu PilotDeck podaje, że system zestawia dla każdego żądania podstawowe instrukcje, instrukcje projektu, umiejętności, wiadomości historyczne, wyniki narzędzi i pamięć długoterminową. Następnie przydziela te materiały zgodnie z pojemnością kontekstu wybranego modelu.
Duże wyniki narzędzi mogą być przechowywane jako pliki, zamiast stale zajmować wejście modelu. Wiadomości historyczne można kompresować do podsumowań zachowujących kluczowe relacje zadaniowe. Pamięć długoterminowa pozostaje oddzielona od kompresji sesji.
To rozróżnienie ogranicza jedno z powszechnych źródeł nieporozumień. Kompresja sesji pomaga kontynuować bieżące zadanie, gdy jego surowy transkrypt staje się zbyt duży. Pamięć długoterminowa przenosi wiedzę możliwą do ponownego użycia między odrębnymi sesjami.
Żaden z tych mechanizmów nie gwarantuje poprawności. Skompresowane podsumowanie może pominąć zastrzeżenie, które później okaże się ważne. Zapisana pamięć może utrwalić błędną interpretację. Korzyścią jest ciągłość operacyjna, a nie automatyczna prawda.
PilotDeck dodaje kolejną warstwę poprzez routing modeli. Użytkownicy mogą skonfigurować wielu dostawców i przypisywać różne modele do różnych poziomów złożoności zadań. Lżejszy model może obsługiwać rutynową pracę, podczas gdy bardziej zaawansowany model otrzymuje etapy wymagające intensywnego rozumowania.
Router obsługuje także łańcuchy awaryjne, gdy żądanie do modelu zakończy się niepowodzeniem. PilotDeck rejestruje statystyki użycia i może szacować różnice względem skonfigurowanej wartości bazowej. Dokumentacja ostrzega, że szacowane kwoty nie są równe rzeczywistym rachunkom dostawców.
Wybór modelu jest zatem oddzielony od samej przestrzeni roboczej. Zespoły mogą łączyć usługi za pomocą obsługiwanych protokołów, zamiast wiązać każdy projekt z modelem jednego dostawcy. To jedna z najwyraźniejszych różnic między PilotDeck a zamkniętymi asystentami produktywności.
System udostępnia także narzędzia do edycji plików, wykonywania poleceń, dostępu do sieci i usług zewnętrznych. MCP, czyli Model Context Protocol, pozwala zgodnym usługom występować jako narzędzia możliwe do wywołania w przepływie wykonawczym agenta. Konfiguracje na poziomie projektu mogą zastępować połączenia globalne, gdy konkretna przestrzeń robocza wymaga innego dostępu.
Narzędzia działają w granicach uprawnień. PilotDeck podaje, że parametry i uprawnienia są sprawdzane przed wykonaniem, a dostęp do plików zależy od katalogu roboczego i innych autoryzowanych ścieżek. Tworzy to widoczne miejsce do określenia, czego agent może dotykać.
Środowisko wykonawcze koordynuje te elementy przez iteracyjną pętlę. Model wybiera działanie, narzędzie zmienia lub sprawdza środowisko, a wynik wraca do modelu. Wykonanie kończy się po ukończeniu, anulowaniu, nieodwracalnym błędzie lub osiągnięciu skonfigurowanego limitu pętli.
Brzmi to znajomo, ponieważ agenci programistyczni już korzystają z podobnych wzorców. Zakład PilotDeck polega na tym, że ten sam model operacyjny może obsłużyć szerszą pracę opartą na wiedzy, gdy zostanie połączony z umiejętnościami specyficznymi dla pracy biurowej i kontrolami artefaktów.
Zadanie przygotowania prezentacji ilustruje tę różnicę. Zwykły asystent może przygotować tekst slajdów w odpowiedzi na czacie. Agent działający w przestrzeni roboczej może przeanalizować dokumenty źródłowe, utworzyć prezentację, sprawdzić jej strukturę, poprawić przeładowane slajdy i pozostawić edytowalny plik obok materiałów wejściowych.
Zadanie dotyczące arkusza kalkulacyjnego stawia inne wymagania. Agent musi zachować typy danych, formuły, etykiety i strukturę skoroszytu. Wiarygodnie brzmiące wyjaśnienie tekstowe nie zrekompensuje uszkodzonego odwołania w dostarczonym pliku.
Właśnie dlatego instrukcje procesu wielokrotnego użycia mają znaczenie. Zespoły tworzące workflow AI potrzebują stabilnych danych wejściowych, jasnych kontroli i możliwych do sprawdzenia wyników. PilotDeck porządkuje te elementy wokół katalogu projektu, zamiast pozostawiać je rozproszone między promptami.
Mechanizm jest spójny: trwałe pliki zakotwiczają rzeczywistość, zapisy sesji zachowują historię wykonania, kompresja ogranicza wzrost kontekstu, a umiejętności kierują powtarzalną pracą. Otwarte pozostaje pytanie, jak dobrze te warstwy opierają się kumulującym błędom podczas wymagających zadań.
Agenci biurowi konkurują teraz rezultatami, a nie odpowiedziami
PilotDeck wywiera presję zarówno na hostowanych asystentów biurowych, jak i platformy agentów dla deweloperów, aby udowodniły, że potrafią kończyć pracę nad wieloma plikami.
Hostowani asystenci korzystają z bliskości aplikacji, których ludzie już używają. Microsoft i Google mogą umieszczać funkcje AI obok dokumentów, arkuszy kalkulacyjnych, poczty e-mail i kalendarzy. Taka dystrybucja zmniejsza trudności związane z konfiguracją i daje asystentowi dostęp do znanych przepływów pracy.
Ich podejście utrzymuje użytkowników także w środowisku kontrolowanym przez dostawcę. Wybór modelu, szczegóły orkiestracji i głębsze zachowanie wykonawcze są często mniej otwarte na modyfikacje. Organizacje muszą działać w ramach integracji i mechanizmów kontroli udostępnianych przez każdego dostawcę.
PilotDeck wybiera przeciwną drogę. Jego kod korzysta z licencji GNU Affero General Public License w wersji 3. Warunki AGPL pozwalają na analizę i modyfikację, nakładając jednocześnie obowiązki udostępniania źródeł w objętych licencją scenariuszach użycia sieciowego.
Ta otwartość może mieć znaczenie dla deweloperów, badaczy i organizacji, które chcą analizować zachowanie agenta. Tworzy również dodatkową pracę. Ktoś musi wdrożyć system, skonfigurować dostawców, zarządzać poświadczeniami, definiować uprawnienia, oceniać umiejętności i utrzymywać aktualizacje.
Repozytorium oferuje pakiety desktopowe i ścieżki instalacji dla Windows, macOS i Linux. Publiczna historia wydań pokazuje również dalsze kompilacje i poprawki po ogłoszeniu wersji 2.0. Ta aktywność wspiera obraz utrzymywanego projektu, choć nie mierzy niezawodności produkcyjnej.
Agenci ukierunkowani na deweloperów stają wobec innej formy presji. Ich wykonanie sterowane narzędziami pokazało, że modele potrafią poruszać się po repozytoriach, edytować pliki, uruchamiać polecenia i poprawiać pracę po nieudanych testach. Agenci biurowi coraz częściej zapożyczają ten wzorzec operacyjny.
PilotDeck wyraźnie opiera się na pomysłach i komponentach związanych z interfejsami agentów programistycznych, routerami modeli, systemami pamięci, frameworkami wyszukiwania informacji i umiejętnościami. Jego wkładem jest próba przekształcenia tych elementów w ogólną przestrzeń roboczą dla bieżących zadań.
Nie czyni to z PilotDeck bezpośredniego zamiennika każdego agenta programistycznego. Repozytoria oprogramowania zapewniają wyjątkowo silne sprzężenie zwrotne. Testy mogą kończyć się niepowodzeniem, kompilatory mogą odrzucać niepoprawną składnię, a system kontroli wersji może ujawniać dokładne zmiany.
Artefakty biurowe często nie mają porównywalnych mechanizmów kontroli. Prezentacja może otworzyć się poprawnie, mimo że zawiera niepoparte dowodami twierdzenie. Arkusz kalkulacyjny może zawierać prawidłowe formuły, ale opierać się na błędnym założeniu biznesowym. Raport może spełniać wymagania formatowania, a jednak pomijać decydujące źródło.
Granica konkurencji przebiega więc między przejrzystością wykonania a wygodą korzystania z aplikacji. PilotDeck zapewnia kontrolę nad przestrzenią roboczą, modelami, narzędziami i umiejętnościami. Hostowane pakiety oferują ściślejszą integrację z powszechnie używanymi aplikacjami biurowymi i systemami tożsamości.
Żadne z tych podejść nie rozwiązało jeszcze problemu weryfikacji na ostatnim etapie. Lokalny, otwarty agent wciąż może wygenerować dopracowany, ale błędny artefakt. Głęboko zintegrowany komercyjny asystent nadal może źle zrozumieć polecenie lub pozostawić ważną pracę niedokończoną.
Ma to znaczenie dla nabywców korporacyjnych, ponieważ jakość modelu jest tylko jednym elementem systemu. Muszą oni również ocenić projekt uprawnień, możliwość audytu, kompatybilność plików, zachowanie podczas odzyskiwania, sposób przetwarzania danych oraz wysiłek potrzebny do utrzymywania instrukcji specyficznych dla danego zadania.
Model przestrzeni roboczej PilotDeck ułatwia kontrolę tych warstw operacyjnych. Użytkownicy mogą zobaczyć pliki, zapisy wykonania, wywołania narzędzi i skonfigurowane rozszerzenia. Ta widoczność wspiera debugowanie i wewnętrzną weryfikację.
Nie należy jednak mylić obserwowalności z poprawnością. Pełny dziennik może wyjaśnić, w jaki sposób agent doszedł do błędnego wyniku. Nie zapobiega on błędowi, chyba że rozpozna go człowiek, test lub system pomocniczy.
Wydanie 2.0 utrudnia konkurentom unikanie tego rozróżnienia. Jeśli agenci biurowi obiecują ukończoną pracę, dostawcy muszą pokazać więcej niż atrakcyjne demonstracje czatów. Potrzebują dowodów, że końcowe pliki pozostają użyteczne po długich, rozgałęzionych przepływach pracy.
Przebieg 2 000 wiadomości nie jest benchmarkiem niezawodności
Główne twierdzenie PilotDeck dotyczące wytrzymałości ma znaczenie tylko wtedy, gdy dokładność zadań utrzymuje się wraz z większą długością pracy.
Projekt twierdzi, że PilotDeck 2.0 może utrzymywać długotrwałą pracę na właściwym torze przez 2 000 wiadomości interakcji. Jest to konkretne twierdzenie dotyczące pojemności, lecz publiczne ogłoszenie nie przedstawia niezależnego benchmarku łączącego tę długość z pomyślnym dostarczaniem artefaktów biurowych.
Liczba interakcji jest również niedoskonałą miarą trudności zadania. Dwa tysiące krótkich doprecyzowań może wymagać mniej rozumowania niż 40-etapowe zadanie obejmujące niespójne pliki źródłowe. Długi zapis rozmowy może oznaczać produktywną iterację, powtarzające się niepowodzenia albo jedno i drugie.
Silniejszym testem jest to, czy końcowy artefakt spełnia szczegółową rubrykę oceny. Powinien zawierać właściwe informacje, zachowywać wymaganą strukturę, pozostawać edytowalny i otwierać się w oczekiwanym oprogramowaniu. Powinien również unikać niepopartych dodatków.
Istniejące badania dają powody do ostrożności. Ocena OfficeBench z 2024 r. testowała agentów w realistycznych biurowych przepływach pracy i wielu aplikacjach. GPT-4 Omni osiągnął najwyższy zgłoszony wskaźnik zaliczeń na poziomie 47 procent, nadal poniżej standardu wymaganego dla niezawodnej automatyzacji pracy biurowej.
Badacze powiązali niepowodzenia z redundantnymi działaniami, halucynacjami i trudnością przełączania się między aplikacjami. Problemy te stają się szczególnie istotne, gdy agent musi koordynować dokumenty, arkusze kalkulacyjne, prezentacje i informacje zewnętrzne.
Nowsze badania dochodzą do podobnego wniosku poprzez ocenę na poziomie artefaktów. Benchmark office-agent z 2026 r. zawiera 100 długoterminowych zadań wywiedzionych z próśb praktyków. Każde zadanie wymaga średnio 2,32 godziny pracy człowieka i jest oceniane za pomocą szczegółowych kontroli opartych na kodzie.
Badanie wykazało, że oceniani agenci modeli językowych wykonywali pracę szybciej i przy niższym koszcie inferencji niż pracownicy. Żaden z nich nie zbliżył się jednak do ludzkiego poziomu jakości dostarczanych materiałów.
Benchmark wykazał również, że dłuższe zadania wykonywane przez ludzi zwykle prowadziły do niższych wyników agentów. Badacze przypisali ten wzorzec wymaganiom dotyczącym długotrwałego planowania, szczegółowej manipulacji plikami i większej liczbie okazji do kumulowania się błędów strukturalnych.
Porównanie metod działania jest szczególnie istotne dla PilotDeck. Konfiguracja oparta wyłącznie na kodowaniu uzyskała 14,41 w benchmarku, nieznacznie więcej niż hybrydowa konfiguracja kodowania i korzystania z komputera, która osiągnęła 13,77. Konfiguracja wyłącznie z użyciem komputera uzyskała 0,78.
Wyniki te dotyczą tego benchmarku i jego konkretnej struktury pomocniczej. Nie powinny być wykorzystywane jako wskaźniki wydajności PilotDeck. Mimo to wspierają szerszą ideę stojącą za umiejętnościami PilotDeck: bezpośrednia manipulacja plikami może być bardziej niezawodna niż długi łańcuch wizualnych kliknięć.
Ujawniają też pozostały problem. Programowa edycja ogranicza część błędów interfejsu, ale nie gwarantuje jakości semantycznej. Kod może umieścić błędny wniosek dokładnie w odpowiedniej komórce.
PilotDeck potrzebuje publicznych ocen odpowiadających jego deklaracjom. Użyteczny test powinien rozpoczynać się od plików źródłowych i ogólnego zadania, a następnie oceniać rzeczywisty dokument Word, skoroszyt lub prezentację pozostawione w przestrzeni roboczej.
Ocena powinna raportować całkowite niepowodzenia, częściowe ukończenie, niepoparte twierdzenia, wady formatowania i czas potrzebny na korektę przez człowieka. Powinna również oddzielać wydajność modelu od ulepszeń wprowadzonych przez strukturę agenta.
Testowanie długich sesji zasługuje na własną analizę awarii. Badacze powinni sprawdzić, czy kompresja kontekstu powoduje utratę wymagań, czy stare wspomnienia zastępują nowsze instrukcje oraz czy odzyskiwanie wznawia pracę z prawidłowego stanu pliku.
Bezpieczeństwo dodaje kolejną niewiadomą. Agent z dostępem do poleceń, narzędzi zewnętrznych i poświadczeń projektu ma szerszą powierzchnię działania niż chatbot. Kontrole uprawnień są pomocne, lecz administratorzy nadal muszą testować, jak system radzi sobie ze złośliwymi dokumentami, wstrzykiwaniem promptów i nadmiernie szerokim dostępem do narzędzi.
Otwarte repozytorium umożliwia zewnętrznym badaczom analizowanie tych kwestii. To rzeczywista zaleta. Niezależne testy nadal muszą jednak zostać przeprowadzone, zanim deklaracja projektu dotycząca wytrzymałości stanie się dowodem niezawodnej pracy bez nadzoru.
Na razie ostrożna interpretacja jest prosta. PilotDeck przedstawia wiarygodną architekturę do utrzymywania długich zadań, a nie dowód, że zadania te zakończą się poprawnie.
Trzy sygnały zdecydują, czy PilotDeck 2.0 ma znaczenie
Kolejny etap PilotDeck zależy od benchmarków artefaktów, powtarzalnego wykorzystania produkcyjnego i zdyscyplinowanego zarządzania rozszerzeniami.
Pierwszym sygnałem jest niezależna ocena dostarczania materiałów biurowych. Powinna porównywać PilotDeck z innymi strukturami agentów przy użyciu tych samych modeli, plików źródłowych, instrukcji i rubryk oceny.
Porównanie to ujawniłoby, czy przestrzeń robocza, pamięć, routing i umiejętności poprawiają wyniki ponad możliwości bazowego modelu. Powinno mierzyć jakość ukończenia i wysiłek naprawczy człowieka, a nie tylko opóźnienia lub zużycie tokenów.
Silny wynik wsparłby centralny argument PilotDeck, że architektura trwałego wykonywania poprawia pracę długoterminową. Słaby wynik sugerowałby, że system głównie wydłuża czas, przez który agent może podejmować niepewne decyzje.
Drugim sygnałem są dowody z powtarzalnego użycia w miejscu pracy. Najbardziej informacyjne przypadki będą obejmować cykliczne zadania z jasnymi kryteriami akceptacji, takie jak tworzenie cotygodniowego raportu operacyjnego na podstawie ustalonego zestawu danych wejściowych.
Użytkownicy powinni śledzić, jak często artefakt jest akceptowany bez korekty, jak często sesje wymagają ratowania oraz które błędy się powtarzają. Publiczny zbiór takich przypadków byłby bardziej przekonujący niż pojedyncze demonstracje.
Niezawodne użycie wymaga również prawdziwych stanów niepowodzenia. Agent powinien zatrzymać się, gdy brakuje niezbędnych informacji, ujawniać nierozwiązane konflikty i odróżniać ukończoną pracę od częściowego wyniku. Ciche wygenerowanie wiarygodnie wyglądającego pliku nie jest pomyślnym dostarczeniem.
Trzecim sygnałem jest zarządzanie umiejętnościami i narzędziami zewnętrznymi. Wielokrotnego użytku umiejętności mogą kodować wartościowe przepływy pracy, lecz mogą też zawierać słabe założenia, niebezpieczne polecenia lub nieaktualne wymagania.
Zespoły potrzebują wersjonowania, przeglądu, limitów uprawnień i przypadków testowych dla instalowanych rozszerzeń. Umiejętności specyficzne dla projektu powinny pozostawać zrozumiałe dla osób odpowiedzialnych za wynikającą z nich pracę.
Taka sama kontrola dotyczy pamięci. Użytkownicy potrzebują kontroli nad tym, co system zachowuje, jak aktualizuje przechowywaną wiedzę i jak usuwa się błędne wspomnienia. Trwały kontekst staje się obciążeniem, gdy nikt nie potrafi wyjaśnić, dlaczego agent wciąż powtarza złą decyzję.
PilotDeck 2.0 ma znaczenie, ponieważ umieszcza te kwestie operacyjne w centrum automatyzacji pracy biurowej. Nie traktuje dopracowanej odpowiedzi jako końcowego produktu. Traktuje przestrzeń roboczą i dostarczone w niej pliki jako produkt.
Takie ujęcie stawia wyższe wymagania niż zwykłe oprogramowanie asystujące. Wymaga od agenta zachowania stanu, obsługi narzędzi, odzyskiwania po przerwaniu oraz tworzenia artefaktów, które wytrzymują kontrolę.
Model open source daje PilotDeck użyteczną drogę naprzód. Badacze mogą tworzyć benchmarki, programiści mogą audytować jego zachowanie, a zespoły mogą dostosowywać umiejętności do rzeczywistych przepływów pracy. Deklaracja projektu dotycząca ciągłości na poziomie około 2 000 wiadomości daje również testerom konkretny cel.
Decydujące pytanie nie brzmi już, czy open source PilotDeck 2.0 potrafi utrzymać rozmowę agenta. Chodzi o to, czy zespół może przekazać agentowi skomplikowane zadanie, wrócić później i zaufać plikom, które po sobie zostawił. Przetestuj ten rezultat w jednym powtarzalnym przepływie pracy, oceń każdy artefakt i odnotuj każdą korektę dokonaną przez człowieka, zanim rozszerzysz jego uprawnienia.
