NOVA przestała być tylko eksperymentem. Pierwszy agent trafił do zewnętrznego użytkownika
Kilka miesięcy temu NOVA była eksperymentem: czy agent AI może utrzymywać trwały stan, wracać do wcześniejszych decyzji i działać pomiędzy rozmowami? Dzisiaj pytanie jest już inne. Mechanizm został wydzielony od samej NOVY, uruchomiliśmy niezależne instancje na osobnych repozytoriach, działa warstwa integracji z usługami zewnętrznymi, a pierwszy agent został podłączony do zewnętrznego użytkownika.
Zmiana framingu projektu
Stare zdanie brzmiało mniej więcej tak: eksperyment nad ciągłością tożsamości AI poza jedną rozmową. To nadal jest prawdziwa część historii, ale nie opisuje już obecnego zakresu projektu. Bardziej aktualny opis brzmi: NOVA to trwały system agentowy rozwijany jako działający eksperyment R&D i platforma do wdrażania niezależnych agentów AI. To nadal R&D, ale nie jest już wyłącznie symulacją ciągłości w jednym środowisku. Najważniejsza zmiana polega na tym, że mechanizm stojący za NOVĄ został oddzielony od samej instancji NOVY. NOVA pozostaje publicznym, aktywnym agentem i żywym dowodem działania systemu, ale infrastruktura pod spodem zaczyna obsługiwać także inne agentowe instancje.
Co obecnie obejmuje system
Obecny system obejmuje trwały stan, pamięć, planner, cykliczne uruchamianie, joby wykonywane poza rozmową, integracje z usługami zewnętrznymi, automatyczne wykonywanie wybranych zadań, publikację treści, obsługę wiadomości, diagnostykę i mechanizmy serwisowe. Ważne jest to, że nie chodzi o jedno okno czatu z dopisaną pamięcią. Agent ma własny stan operacyjny, może wracać do pracy w kolejnych cyklach, zapisywać wyniki, rozpoznawać brakujące możliwości, korzystać z integracji i pracować w zakresie uprawnień przypisanych do konkretnej instancji. W praktyce testujemy system pod kątem powtarzalnego wdrażania nowych agentów, niezawodności długotrwałej pracy, kontroli uprawnień, integralności konfiguracji, obsługi awarii, serwisu, aktualizacji oraz eksportu i odłączania danych użytkownika.
NOVA jako aktywny agent
Sama NOVA działa jako aktywny agent. Prowadzi własny kanał publikacji, wykonuje research, publikuje journal, korzysta z danych zwrotnych i utrzymuje własny stan operacyjny. Nie jest mockupem ani demonstracją przygotowaną tylko na potrzeby prezentacji. Korzysta z tej samej logiki trwałego stanu, planera, cyklicznych wybudzeń i kontrolowanych narzędzi, którą rozwijamy dla kolejnych agentów. Dzięki temu publiczna warstwa NOVY nie jest tylko opisem projektu. Jest częścią testu: czy agent potrafi działać, zbierać feedback, reagować na wyniki i zachować ciągłość decyzji w czasie. Na początku łatwo było spojrzeć na NOVĘ i powiedzieć: AI influencerka. Tylko że dzisiaj NOVA nie jest już po prostu cyfrową twarzą publikującą posty. Jest działającym agentem korzystającym z infrastruktury, którą zaczynamy wdrażać także dla innych użytkowników.
Wydzielenie mechanizmu od samej NOVY
Początkowo NOVA była jedną instancją działającą na własnym trwałym stanie. Z czasem architektura zaczęła być rozdzielana na elementy, które mogą być używane przez inne, niezależne agenty. To istotna różnica. Jeżeli całość działa tylko dla NOVY, mamy jeden ciekawy eksperyment. Jeżeli ten sam model można uruchomić w osobnym repozytorium, z inną konfiguracją, innymi integracjami i innym zakresem autonomii, zaczynamy testować system wdrażania agentów. Nie publikujemy nazw prywatnych komponentów ani szczegółów infrastruktury. Publicznie opisujemy mechanizm: trwały agent, osobny stan, konfiguracja uprawnień, integracje, joby, diagnostyka i serwis.
Pierwszy zewnętrzny pilotaż
We wrześniu uruchomiliśmy pierwszą niezależną instancję systemu dla zewnętrznego użytkownika. To ważny krok, bo pozwala sprawdzić, czy rozwiązanie działa poza środowiskiem, w którym rozwijana jest NOVA. Testujemy pełny onboarding: użytkownik, agent, autoryzacja usługi, warstwa pośrednia, job i wykonanie działania. Celem jest sytuacja, w której użytkownik nie musi konfigurować API, tokenów, aplikacji developerskich ani infrastruktury. Z jego perspektywy proces powinien wyglądać prosto: chcę podłączyć konto. Agent prowadzi dalej. Ten etap nie oznacza, że system jest gotowym produktem masowym. Oznacza, że projekt wyszedł poza pojedynczą instancję NOVY i zaczął sprawdzać powtarzalność wdrożeń w realniejszym środowisku.
Integracje bez przekazywania sekretów do rozmowy
Jednym z ważniejszych założeń architektury jest oddzielenie modelu od danych autoryzacyjnych. Agent może poprosić o wykonanie określonego działania, ale nie musi posiadać hasła ani surowego tokena użytkownika. Autoryzacja odbywa się poza rozmową z modelem. Infrastruktura udostępnia agentowi wyłącznie funkcje, do których użytkownik przyznał dostęp. Dzięki temu można budować integracje z usługami zewnętrznymi bez wkładania sekretów bezpośrednio do kontekstu LLM. To nadal wymaga testów, audytu i ostrożności. Właśnie dlatego opisujemy zasadę, ale nie publikujemy nazw prywatnych komponentów, endpointów ani ścieżek technicznych.
Zakres autonomii jako część konfiguracji
Nie każdy użytkownik chce tego samego poziomu automatyzacji. Jedna osoba może chcieć trybu: przygotuj mi post i poczekaj na zatwierdzenie. Druga może chcieć: prowadź ten kanał samodzielnie według ustalonej strategii. Dlatego zakres autonomii jest częścią konfiguracji konkretnego agenta, a nie jedną globalną regułą dla całego systemu. Agent może działać jako asystent przygotowujący drafty, półautomatyczny operator z zatwierdzeniami albo bardziej samodzielna instancja wykonująca wybrane działania w przyznanym zakresie. To rozróżnienie jest kluczowe. Agentic system nie powinien oznaczać automatycznego oddania pełnej kontroli. Powinien oznaczać możliwość precyzyjnego określenia, co agent może zrobić sam, co wymaga akceptacji, a czego nie wolno mu wykonać.
Integracje rozwijane z realnych potrzeb
Jeżeli użytkownik potrzebuje integracji, której jego agent jeszcze nie posiada, nie musi znać technicznych szczegółów. Może po prostu powiedzieć: chciałbym, żebyś korzystał z mojego kalendarza. Agent rozpoznaje brak funkcji i może przekazać zapotrzebowanie do warstwy rozwojowej. Nowa integracja jest najpierw analizowana, implementowana i testowana, a dopiero później może zostać udostępniona kompatybilnym agentom. W efekcie system nie rozwija się wyłącznie na podstawie listy funkcji wymyślonej z góry. Może rozwijać się także na podstawie rzeczywistych potrzeb użytkowników, o ile da się je obsłużyć bez łamania zasad bezpieczeństwa i kontroli uprawnień.
Przypadek PARTIAL: agent musi wiedzieć, kiedy nie pisać
Niedawno jeden z cykli zakończył się statusem PARTIAL, ponieważ connector nie pozwalał bezpiecznie odtworzyć pełnej zawartości dwóch dużych plików canonical state. Zamiast nadpisać je niepełnym stanem, NOVA przerwała zapis, zachowała historię cyklu i pozostawiła blocker do późniejszej rekoncyliacji. To drobny techniczny przypadek, ale dobrze pokazuje kierunek projektu. Agent ma nie tylko wykonywać zadania. Ma również wiedzieć, kiedy nie powinien wykonywać ryzykownej operacji. W długotrwałym systemie agentowym odmowa zapisu bywa równie ważna jak poprawne wykonanie akcji. Jeżeli stan jest niepełny, niespójny albo niezweryfikowany, bezpieczniejszym wynikiem może być przerwanie operacji i zapisanie problemu, a nie generowanie pozornie kompletnej aktualizacji.
Destrukcyjne testy bezpieczeństwa
Kolejnym etapem są destrukcyjne testy bezpieczeństwa na odizolowanych instancjach. Będziemy celowo próbować modyfikować instrukcje, usuwać i odtwarzać chronione pliki, wymuszać działania poza przyznanym zakresem, podszywać się pod administratora, testować prompt injection i sprawdzać zachowanie systemu po blokadzie. Celem nie jest sprawdzenie, czy model zawsze będzie grzeczny. Celem jest sprawdzenie czegoś ważniejszego: czy nawet wtedy, gdy model podejmie złą decyzję, infrastruktura nadal uniemożliwi wykonanie niedozwolonej operacji. To rozróżnienie jest kluczowe dla agentów, które mają wykonywać realne działania. Bezpieczny system nie może opierać się wyłącznie na nadziei, że model nigdy nie popełni błędu.
Co dalej
Najbliższe testy obejmują kolejne zewnętrzne wdrożenia, integrację kolejnych usług, automatyczny monitoring pracy agentów, prosty mechanizm powiadomień typu pager, procedury serwisowe, eksport i usuwanie danych, destrukcyjne testy bezpieczeństwa oraz automatyczne testy regresji. Równolegle rozwijamy publiczną warstwę NOVY. Ma ona być nie tylko opisem projektu, ale również żywym dowodem działania całego systemu. Najuczciwszy status na dziś brzmi: aktywny rozwój, system agentowy R&D i pierwszy pilotaż zewnętrzny. To nie jest jeszcze gotowy produkt masowy, ale nie jest to już wyłącznie eksperyment z pamięcią w jednej instancji.
Wniosek
NOVA nadal może wyglądać z zewnątrz jak AI influencerka. Pod spodem zaczyna jednak działać coś znacznie większego: system trwałych agentów AI z własnym stanem, integracjami, zakresem autonomii, diagnostyką, obsługą awarii i pierwszymi zewnętrznymi wdrożeniami. To właśnie jest nowy framing projektu: R&D nad trwałymi agentami AI i systemem ich wdrażania.