Stawiam swoją firmę na proaktywnych agentów

Agenci potrafią zrobić prawie wszystko, o co ich poprosisz, i na tym polega problem: nadal musisz prosić.

Ciągle słyszę, jak ludzie nazywają agentów „cyfrowymi współpracownikami”. To ujęcie jest błędne. Współpracownik, który siedzi w milczeniu, dopóki nie podasz mu idealnie zakreślonego zadania, wykonuje je, a potem wraca do czekania, nie jest współpracownikiem. Każdy agent, którego kiedykolwiek używano, działa dokładnie tak. Modele zmądrzały, harnessy się poprawiły, przebiegi się wydłużyły, ale interfejs nigdy się nie zmienił: ty przynosisz pracę, agent przynosi wykonanie.

I większość ludzi tego nie zauważyła, bo pole promptu po cichu stało się tym, czym AI jest w naszych głowach.

Ask anything about your stack...

Każdy interfejs to nadal pole promptu

Od pola wejściowego zaczęła się cała ta era. ChatGPT postawił jedno na modelu i stał się najszybciej rosnącym produktem w historii, a my wszyscy to skopiowaliśmy. Każdy produkt AI od tego czasu jest wariacją na temat tej samej interakcji: człowiek pisze, maszyna odpowiada, maszyna czeka.

Claude Code był następną ewolucją. Agent przeniósł się do twojego terminala, wziął twoje pliki, powłokę i historię git i zaczął wykonywać prawdziwą pracę, zamiast o niej mówić. Zmieniło to, co agenci potrafią, ale nie to, jak zaczynają: piszesz, on pracuje, zatrzymuje się i czeka, aż znów napiszesz.

~/app

$ claude

✳ 12 files · main · last session 2h ago

> fix the failing checkout tests

? for shortcuts

Potem agenci przenieśli się do chmury. Codex, Devin, Claude Code w przeglądarce. Działają godzinami zamiast minutami, odpalają subagentów, żeby zrównoleglić pracę, i nie umierają, gdy zamykasz laptopa. Dajesz jednemu zadanie przed lunchem i wracasz do pull request.

Prompt przestał nawet być czymś wyłącznie z klawiatury. Agenty w tle można odpalić alertem albo webhookiem, a większość platform agentowych oferuje teraz automatyzacje: gdy odpali się to zdarzenie albo tyknie ten cron, uruchom agenta z tymi instrukcjami.

Triage Sentry alerts Enabled

When

a Sentry alert fires

Do

investigate, open an incident if it's real

Then

post the findings to #incidents

Ale czym jest automatyzacja? To prompt napisany z wyprzedzeniem. Przewidziano tryb awarii, wybrano zdarzenie i spisano, co z tym zrobić. Wyzwalacz odpala agenta, ale ocena w jego środku jest twoja, zamrożona w chwili konfiguracji. Automatyzacja wyłapuje dokładnie to, co przewidziano, i nic więcej.

To ty jesteś schedulerem

Odrzuć narzędzia, a podział pracy nie ruszył się od trzech lat. Agent wykonuje pracę. Decydowanie, czym ta praca jest, pozostaje twoim zadaniem.

Czytasz dashboardy, słuchasz użytkowników, ustalasz, co ma znaczenie, i kompresujesz wszystko, czego się dowiedziano, do promptu, na żywo przy klawiaturze albo z wyprzedzeniem w wyzwalaczu. Agent wykonuje znakomicie, ale każdy element oceny w systemie pochodzi od ciebie.

Następna ewolucja: agenci, którzy znajdują pracę

Stawiam na to, że następną ewolucją są agenci, którzy sami odkrywają, co jest do zrobienia. Bez promptu, bez wyzwalacza do skonfigurowania, bez instrukcji napisanych z wyprzedzeniem. Podłączasz swój stack, a agent sam znajduje pracę: obserwuje te same sygnały, które obserwujesz ty, zauważa, co jest nie tak, decyduje, czy to ma znaczenie, i zaczyna nad tym pracować autonomicznie.

Łatwo to powiedzieć i brutalnie trudno zbudować, bo proaktywność to trzy problemy ułożone jeden na drugim, a pominięcie któregokolwiek daje coś gorszego niż agent za polem wejściowym.

Kontekst. Oczywiście agent potrzebuje żywego modelu świata, w którym działa, a nie migawki wklejonej do okna kontekstu w chwili promptu. Reaktywny agent ze złym kontekstem daje złą odpowiedź. Proaktywny agent ze złym kontekstem kasuje twoją produkcyjną bazę danych, bo myślał, że to staging.

Ocena. To sprawia mi największą trudność. W każdej chwili tysiące rzeczy w systemie produkcyjnym są odrobinę nie tak. Agent, który zgłasza je wszystkie, jest maszyną do szumu, maszyny do szumu się wycisza, a wyciszeni agenci to martwi agenci. Cała wartość proaktywności mieści się w przestrzeni między „coś się zmieniło” a „coś ma znaczenie”:

[
  {
    "signal": "memory up 3% on checkout-edge",
    "verdict": "no anomaly",
    "reasoning": "within the seasonal range for this hour on this worker"
  },
  {
    "signal": "new error pattern, 2 minutes after deploy 9f3c2a1",
    "verdict": "incident",
    "reasoning": "error class never seen on this worker, tightly correlated with a deploy"
  }
]

Działanie. Zauważanie bez działania to tylko mądrzejszy alert, a alerty to właśnie to, co próbuję zabić. Agent musi dokończyć robotę, w granicach, które czynią autonomię bezpieczną: odwracalne działania, dowody na wszystko i twarda bramka przed czymkolwiek nieodwracalnym.

Żaden z tych trzech problemów nie polega na tym, że agent decyduje, jak wygląda dobrze. Decyduje, co jest nie tak, czy to ma znaczenie i co z tym zrobić, i to cała lista, bo na produkcji nikt nie musi definiować dobrze: błędy na zerze, opóźnienie na linii bazowej, kolejki opróżnione, certyfikaty ważne. Stan pożądany przychodzi razem z terytorium.

Co oznacza, że prawdziwa zmiana nie polega na przejściu od „ty promptujesz” do „agent promptuje sam siebie”. To przejście od operacji imperatywnych do operacji deklaratywnych. Automatyzacja jest imperatywna: wyliczasz z góry tryby awarii i skryptujesz odpowiedź na każdy. Proaktywny agent to pętla uzgadniania: zestawia system, który masz, z systemem, który powinien być, i pracuje nad zamknięciem luki. Kubernetes zrobił to dla infrastruktury dekadę temu, zapisujesz trzy repliki, a kontroler robi, co trzeba, żeby trzy repliki żyły. Nikt nie zrobił tego dla samego utrzymania oprogramowania. A tu nie ma nawet YAML-a do napisania, bo stan pożądany jest już znany. Działa od razu po wyjęciu z pudełka.

Zacząłem od operacji

Poproś proaktywnego agenta o wybór roadmapy produktu, a dostaniesz stażystę z własnym zdaniem, bo kierunek produktu to kwestia smaku. Produkcja nie. To jedyna dziedzina, w której wszystkie trzy problemy da się dziś rozwiązać.

Praca sama się zgłasza: wskaźniki błędów rosną, wdrożenie idzie w bok, certyfikat wygasa, kolejka się zapycha. Praca już siedzi w telemetrii i czeka, aż ktoś ją zauważy. I w odróżnieniu od dziedzin opartych na smaku istnieje tu prawda obiektywna: wskaźnik błędów albo skoczył, albo nie, rollback albo przywrócił linię bazową, albo nie, więc ocena agenta jest punktowana przez sam system, bez przerwy, bez miejsca na wrażenia.

Przede wszystkim już dziś obsadzamy to stanowisko ludźmi. Nazywamy to dyżurem: człowiek śpiący obok telefonu, czekający, aż maszyna powie, że inna maszyna jest nieszczęśliwa. Spędziłem lata w obserwowalności, założyłem firmę od obserwowalności, którą przejął Cloudflare, i napisałem cały manifest o strukturyzowaniu telemetrii tak, żeby odpowiedź była o jedno zapytanie stąd. Jego teza jest powodem istnienia tej firmy: w 2026 nikt nie powinien mieć dyżuru.

Bo niewygodna prawda o ostatniej dekadzie obserwowalności jest taka, że ułatwiliśmy ludziom przepytywanie systemów o 3 w nocy, a potem ogłosiliśmy zwycięstwo, podczas gdy to nadal ludzi budzono. Dashboardy stały się ładniejsze, a pager został na stoliku nocnym. Obserwowalność bez działania to tylko drogi magazyn.

Jak to wygląda

To właśnie robi Polylane. Oto konkretny wtorek:

Nikt nie skonfigurował kontroli dla tego trybu awarii. Nie ma reguł do pisania ani progów do strojenia: agenci oceniają każdy podłączony zasób w ciągłym rytmie, a twoje istniejące dashboardy i zapisane zapytania stają się ich listą kontrolną. Ocena to miejsce, w którym jestem najsurowszy. Domyślny werdykt to brak problemu, bo o wiele lepiej przegapić graniczny problem, niż budzić kogoś dla szumu. „Wdrożenie może wprowadzić błąd” jest prawdą o każdym wdrożeniu i nigdy nie jest powodem, żeby kogokolwiek budzić.

Gdy coś jest prawdziwe, dochodzenie prowadzi równolegle kilka konkurujących hipotez, a zadaniem każdego agenta jest obalenie swojej hipotezy, a nie jej potwierdzenie, więc korelacja nigdy nie może udawać przyczyny. Gdy potwierdzoną przyczyną źródłową jest zmiana w kodzie, poprawka przychodzi jako pull request z dołączonym dochodzeniem:

Restore Hyperdrive pool size in checkout-edge

PR open coreplane/checkout-edge

Investigation report attached Checks passing

Opened by Polylane · gated on review and CI

Proaktywny nie znaczy bez nadzoru

Autonomia jest w zauważaniu, triażu, archeologii o 3 w nocy i łagodzeniu skutków. Wszystko, co przywraca znany dobry stan, agent robi sam: cofa złe wdrożenie, przestawia flagę z powrotem. Te działania są odwracalne z konstrukcji i to one faktycznie uciszają pager. Bramkowane pozostaje wszystko, co tworzy nowy stan: zmiana w kodzie wychodzi przez twój przegląd i twoje CI, nigdy obok nich.

Granica nie przebiega między człowiekiem a agentem. Przebiega między odwracalnym a nieodwracalnym. I dlatego nie masz po cichu nadal dyżuru: rollback zakończył incydent o 02:33, sześć godzin przed scaleniem pull request. PR nigdy nie był tym, co zatrzymało krwawienie. Jest tym, co sprawia, że nie powtórzy się, a to może poczekać do kawy.

A bramkę możesz delegować. Agenci do przeglądu kodu już czytają każdy pull request w twoim repozytorium. Istnieje świat, niedaleko od tego, w którym twój agent przeglądający czyta poprawkę o 02:41, sprawdza ją względem dochodzenia, zatwierdza, a twoje CI wdraża na produkcję, zanim się obudzisz. Nic w pętli się nie zmienia poza tym, kto trzyma przycisk zatwierdzenia. Tam to się kończy: oprogramowanie, które naprawia się samo, a ty piszesz politykę, zamiast klikać scal.

Zauważ, czego brakuje w tej pętli:

Ask anything about your stack...

Pole promptu było świetnym sposobem, żeby nauczyć się ufać tym systemom, i jest okropnym sposobem na prowadzenie produkcji. Agent widział każde wdrożenie, każdy wiersz logu i każdą metrykę we wszystkich usługach naraz. Trzymanie go za promptem oznacza, że najlepiej poinformowany członek twojego zespołu odzywa się tylko wtedy, gdy ktoś się do niego zwróci.

W 2026 nikt nie powinien mieć dyżuru.