Agent AI czy workflow: z siedmiu naszych systemów tylko jeden musiał być agentem

Całe pytanie brzmi: kto jest właścicielem kolejności kroków

Anthropic rysuje tę granicę jednym zdaniem na stronę. Z ich tekstu inżynierskiego o budowaniu skutecznych agentów: „Workflows are systems where LLMs and tools are orchestrated through predefined code paths. Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage”. Czyli workflow to system, w którym modele i narzędzia są orkiestrowane przez z góry napisane ścieżki kodu, a agent to system, w którym model sam kieruje własnym procesem i użyciem narzędzi. Nic w tej definicji nie mówi o tym, jak mądry jest system ani ile ma narzędzi. Różnica sprowadza się do tego, kto decyduje, co dzieje się dalej.

Pierwsza bramka jest więc pytaniem, na które odpowiesz przed napisaniem linijki kodu. Jeśli kolejność kroków jest za każdym razem ta sama, chcesz pipeline. Jeśli kolejność zmienia się w zależności od tego, co model zobaczy, chcesz agenta. Większość projektów oblewa ten test w kierunku, którego nikt się nie spodziewa: zespół opisuje agenta, a potem wychodzi mu na tablicy, że każde uruchomienie robi te same pięć rzeczy w tej samej sekwencji.

Druga bramka jest nasza i wzięła się z produkcji. Ile kosztuje błędna odpowiedź i czy maszyna umie ją wykryć? Jeśli błąd jest wykrywalny maszynowo, czyli kod się nie kompiluje albo link zwraca 404, albo liczba nie zgadza się ze źródłem, bramka w kodzie wygrywa z agentowością: taniej, szybciej, a gdy zadziała, wiadomo, która kontrola padła. Po autonomię sięgasz wtedy, gdy błąd jest kwestią oceny. Ten sam test rozstrzyga piętro wyżej, czy proces w ogóle warto automatyzować.

Rekomendacja samego Anthropic brzmi: szukać „the simplest solution possible, and only increasing complexity when needed”, czyli najprostszego rozwiązania, i dokładać złożoność dopiero wtedy, gdy jest potrzebna. Piszą też wprost, że zwykle wystarczy dopracować pojedyncze wywołania modelu z retrievalem i przykładami w kontekście. Dex Horthy formułuje obserwacyjną wersję tej samej myśli w 12-Factor Agents: większość produktów reklamujących się jako agenty AI wcale nie jest specjalnie agentowa, to w większości deterministyczny kod z krokami LLM wstawionymi w odpowiednich miejscach. Agentowość bywa kupowana po to, żeby nie projektować systemu: skoro model decyduje o wszystkim w locie, nikt nie decyduje niczego na etapie projektu, a rachunek przychodzi później, w trace'ie, którego nikt nie umie przeczytać.

Agent AI czy workflow, wymiar po wymiarze

Każdy wiersz poniżej to świadomy kompromis. To nie punktacja, w której jedna kolumna wygrywa.

Nic z tego nie robi z agentów złego pomysłu. Robi z agentowości zakup: kupujesz elastyczność, a płacisz przewidywalnością kosztu i łatwością debugowania. Opłaca się, gdy elastyczność jest produktem, i jest złym interesem, gdy kupiłeś ją dlatego, że pytanie o architekturę wydało się trudne.

Siedem systemów na produkcji, jeden uczciwy agent

Definicje są tanie, więc zamiast nich nasz własny bilans, poukładany według pierwszej bramki. Wszystkie siedem działa, a każdej klasyfikacji poniżej bronilibyśmy na code review.

Dwa z siedmiu nie mają modelu w gorącej ścieżce, i akurat są to dwa systemy o największym wolumenie: backend OTT, w którym dziesiątki tysięcy widzów naciskają play w tej samej minucie, i telegramowy tracker zleceń pracujący przy milionach wiadomości dziennie. Przy takim wolumenie wywołanie modelu na każdą pozycję to osobna pozycja w kosztach i osobna w latencji, a żaden z tych systemów nie ma pytania, na które model odpowiedziałby lepiej niż zapytanie do bazy.

Jeden wpis jest sporny: AI rektora. Władze uczelni zadają mu otwarte pytania naturalnym językiem, a system przydziela zadania wydziałom, co brzmi agentowo podwójnie. Tyle że każda liczba jest pobierana w momencie pytania, przydziały zatwierdza człowiek, zanim wyjdą, a każde działanie jest logowane. Model wybiera, czego poszukać, a kod jest właścicielem tego, co dzieje się dalej. Według pierwszej bramki to workflow z elastycznymi drzwiami wejściowymi, czyli kształt, w którym ląduje sporo asystentów wewnętrznych w chwili, gdy ktoś pyta, kto zatwierdził zapis. W polskich realiach to pytanie pada szybciej, bo logi trzeba pokazać przy RODO, a dochodzą do tego obowiązki przejrzystości z AI Act. Ustaloną ścieżkę w kodzie opisujesz w dokumentacji jednym akapitem. Ścieżkę agenta opisujesz trace'em, który trzeba przechowywać.

W pipeline'ach trudna nigdy nie była autonomia

Trzy z tych systemów to klasyczna automatyzacja workflow AI: model siedzi w środku, ale kolejnością rządzi kod. Weźmy pipeline design-to-code. Kuszący projekt to agent-recenzent: niech model spojrzy na wygenerowany ekran, oceni, czy zgadza się z projektem, i powie, co poprawić. To, co wdrożyliśmy, renderuje kod headlessowo i porównuje go piksel po pikselu z oryginalną klatką. Skrajne przypadki auto-layoutu rozjeżdżały mniej więcej 15% klatek, a pixel diff mierzy to w milisekundach, podczas gdy ocena modelu kosztuje round trip i tak zostaje opinią. Niepowodzenia wracają do kolejki z dołączonym diffem. Pętla jest, ale jej właścicielem jest kod: ponowienie wyzwala liczba, a nie opinia modelu.

Pipeline treści jest jeszcze prostszy. Termin wchodzi z CSV, pobierana jest żywa sitemapa, żeby linki wewnętrzne wskazywały na istniejące strony, jedno wywołanie GPT-4o pisze ciało HTML, każdy link dostaje realne zapytanie HTTP, drugie wywołanie zwraca metadane SEO jako ustrukturyzowany JSON, a payload leci do admin API. Zastępuje 20-40 minut pracy pisarza, które kosztował każdy termin. Kolejność nigdy nie musiała się zmienić, bo praca była oparta na regułach, zanim ktokolwiek ją zautomatyzował. Najbardziej polski przykład tego samego kształtu to obieg faktury: pipeline dla KSeF ma tę samą kolejność przy każdym dokumencie, a większość błędów wyłapuje walidacja, nie ocena.

Baza wiedzy z 500 tys. rekordów to miejsce, w którym po agenta sięga się najmocniej, bo oczywiste ujęcie brzmi: research. Szukaj, czytaj, szukaj znowu, przestań, gdy wystarczy. Wygrała struktura. Retrieval najpierw rozwiązuje encję do kanonicznego ID, a potem szuka wewnątrz tego ograniczenia, hybrydowo i z rerankingiem, a każda liczba jest weryfikowana względem źródłowego chunku, zanim odpowiedź wyjdzie. Inteligencja poszła w projekt retrievalu, a nie w pozwolenie modelowi, żeby błądził po dużej bazie.

Wiarygodność każdego z tych trzech systemów zrobiła kontrola, którą umie wykonać maszyna. To druga bramka przy pracy, a z innej strony również większość tego, co znaleźliśmy, szukając, gdzie wdrożenia AI naprawdę pękają. Ani jednej z tamtych awarii nie naprawiłoby danie modelowi większej swobody.

Ten jeden, który naprawdę musiał być agentem

Wyjątkiem jest głosowy inżynier wyścigowy do sesji iRacing na żywo. Kierowca trzyma push-to-talk w środku zakrętu i pyta na głos. Odpowiedź musi wrócić w niecałe dwie sekundy, w stylu radia F1, oparta na telemetrii, która zmienia się w trakcie wypowiadania zdania.

Ten system oblewa pierwszą bramkę bezdyskusyjnie. Jest 19 narzędzi MCP w sześciu kategoriach, od surowej telemetrii po komendy pit-stopu. „Czy wjeżdżać do serwisu na tym okrążeniu?” pobiera aktualny status obsługi w alei serwisowej, średni czas okrążenia auta, tabelę wyników i raport uszkodzeń w jednej pętli rozumowania. Pytanie o zużycie opon potrzebuje innego podzbioru. Tej kolejności nie da się zapisać z góry, bo nie znasz z góry pytania. Model wybiera narzędzia i kolejność z tego, co usłyszał.

Agentowość nie była darmowa i rachunek widać w całym projekcie. Trzymanie całego łańcucha wywołań narzędzi w historii rozmowy zatruwa kolejną odpowiedź: czas okrążenia sprzed 30 sekund jest już błędny, a dla modelu to po prostu kolejny tekst. Więc historia to okno czterech wiadomości, każde pośrednie wywołanie narzędzia uruchamia się na świeżo i jest potem odrzucane, a stan na żywo żyje poza modelem, w workerze odpytującym symulator co 100 ms. Większość inżynierii poszła w ograniczanie agenta, który musiał pozostać agentem. Jeśli wolisz okablowanie od argumentacji, to temat tekstu o podłączeniu agenta do systemów na żywo przez warstwę narzędzi.

Nawet tutaj odebraliśmy sterowanie tam, gdzie to miało znaczenie. Odczyt jest autonomiczny. Komendy pit-stopu przechodzą przez bramkę human-in-the-loop, więc agent może zarekomendować i przygotować zjazd, a kierowca zatwierdza, zanim cokolwiek trafi do auta. Model może być właścicielem kolejności odczytów. Zapisy nie są jego decyzją.

Agenty na produkcji są krótsze, niż sugerują dema

Największe spojrzenie z pierwszej ręki na ten temat to Measuring Agents in Production, badanie zbudowane z 20 pogłębionych case studies i ankiety wśród 86 praktyków z 26 dziedzin. Podsumowanie tego, jak faktycznie budowane są wdrożone agenty: 68% wykonuje najwyżej 10 kroków przed interwencją człowieka, 70% opiera się na promptowaniu gotowych modeli zamiast na dostrajaniu wag, a 74% polega głównie na ocenie człowieka. Największym zgłaszanym wyzwaniem jest niezawodność, rozumiana jako powtarzalnie poprawne zachowanie w czasie, a zespoły z badania adresują ją projektem systemu, nie wyborem modelu.

Krótkie łańcuchy dominują z powodów arytmetycznych, a nie z ostrożności. Niezawodność mnoży się wzdłuż łańcucha, zamiast się uśredniać. Przy 95% na krok i niezależnych krokach dwadzieścia kroków z rzędu wychodzi poprawnie w 35,8% przypadków. Te 95% to założenie, nie pomiar, więc podstaw własną liczbę, ale krzywa zachowa kształt.

Pipeline nie ucieka przed tą arytmetyką, tylko ją przerywa. Każda bramka sprawdzalna maszynowo zeruje swój czynnik: gdy sprawdzenie linków złapie 404, a bramka strukturalna nierozwiązany import, te kroki przestają dokładać się do iloczynu. Dlatego liczba 68% czyta się jako kalibracja, a nie jako asekuracja. Krok jedenasty kosztował więcej, niż zwracał.

Więcej agentów to decyzja o kształcie zadania, nie ulepszenie

Google Research zrobiło systematyczną wersję pytania o multi-agent na 180 konfiguracjach, pięciu architekturach i czterech benchmarkach. W zadaniach sekwencyjnego planowania każdy testowany wariant wieloagentowy pogorszył wynik o 39-70% względem pojedynczego agenta. Niezależne agenty pracujące równolegle bez rozmowy między sobą wzmacniały błędy 17,2 razy. Orkiestrator w środku ograniczył to samo wzmocnienie do 4,4 raza.

Druga połowa trzyma je w uczciwości. Na równoległym rozumowaniu finansowym scentralizowana koordynacja poprawiła wynik o 80,9% względem pojedynczego agenta. Pytanie nigdy nie brzmiało więc, czy multi-agent jest dobry. Brzmi: czy twoje zadanie rozkłada się na kawałki, które mogą lecieć równocześnie, nie wchodząc sobie w drogę.

Cognition doszło do tej samej granicy od strony praktyki. Don't Build Multi-Agents, napisane przez Waldena Yana w czerwcu 2025, stawia dwie zasady, „Share context, and share full agent traces, not just individual messages” oraz „Actions carry implicit decisions, and conflicting decisions carry bad results”, czyli: dziel pełne trace'y agenta, nie pojedyncze wiadomości, i pamiętaj, że działania niosą ukryte decyzje, a sprzeczne decyzje dają zły wynik. Domyślną architekturą jest tam jednowątkowy, liniowy agent. Dziesięć miesięcy później ukazała się rewizja: systemy wieloagentowe działają dziś najlepiej, gdy zapisy pozostają jednowątkowe, a dodatkowe agenty wnoszą inteligencję, a nie działania. To zaostrzenie tezy, nie jej wycofanie, i ląduje tam, gdzie wylądował nasz własny agent. Więcej inteligencji, proszę bardzo. Więcej rąk na tym samym obiekcie, nie.

Najlepszy argument za agentami, potraktowany poważnie

Najmocniejszy kontrargument wobec wszystkiego powyżej zasługuje na rzetelne postawienie. Sean Goedecke dowodzi w tekście build agents, not pipelines, że najskuteczniejsze produkty AI, czyli Claude Code, Codex, Cursor i Copilot, są agentami i nie przez przypadek: programowanie jest na tyle trudne, że działającego agenta do kodu nie da się zbudować z pipeline'ów. Drugi punkt jest ostrzejszy. Wstępne składanie kontekstu zawodzi, bo ustalenie, które informacje są istotne dla problemu, bywa równie trudne jak rozwiązanie samego problemu, i to właśnie położyło naiwny RAG. Trzeci powinien niepokoić każdego, kto zarabia na pisaniu pipeline'ów. Agenty dziedziczą postęp modeli, więc nowy model potrafi otworzyć agentowi zadania, które rok temu były poza zasięgiem, podczas gdy pipeline robi się tylko trochę lepszy.

Wszystkie trzy są prawdziwe. Dołożylibyśmy czwartą opcję, którą to ujęcie pomija, a nasz kontrprzykład akurat jest systemem RAG: gdy trafność jest trudna, autonomia to jedna odpowiedź, a struktura druga. Na bazie z 500 tys. rekordów rozwiązanie encji do kanonicznego ID przed wyszukiwaniem rozwiązało problem trafności, którego wyszukiwanie po embeddingach rozwiązać nie umiało, i zrobiło to deterministycznie, przy stałym koszcie na zapytanie.

Granicę przyznaje zresztą sam autor, i to jego ustępstwa są najbardziej użyteczne: pipeline'y nadal wygrywają, gdy potrzebujesz przewidywalnego kosztu, gdy okna kontekstu są ciasne i przy dużym wolumenie. Nasz bilans wstawia w te ustępstwa liczby, bo miliony wiadomości dziennie i dwusekundowy budżet na odpowiedź głosową nie są ograniczeniami abstrakcyjnymi. Jego argument trzyma się tam, gdzie trafności nie da się policzyć z góry, a to dokładnie kształt inżyniera wyścigowego. Spór jest więc węższy, niż sugerują tytuły. Tylko że w przeciętnym systemie firmowym znajdujemy takich zadań mniej niż w narzędziu do kodu.

Pięć pytań, którymi sklasyfikujesz własny projekt

To rozstrzygniesz sam, na tablicy, zanim ktokolwiek napisze kod albo przyśle ci wycenę. Odpowiadaj dla systemu, który chcesz mieć na produkcji, a nie dla jego demo.

Trzy albo więcej odpowiedzi w lewej kolumnie i budujesz pipeline, cokolwiek mówi prezentacja. To dobry wynik: kosztuje mniej w utrzymaniu, psuje się w miejscach, które umiesz znaleźć, i nadal możesz wstawić model w te dwa kroki, które wymagają oceny. Piętro wyżej stoi inne pytanie, czy w ogóle budować, czy kupić coś, co już to robi, i warto je zamknąć wcześniej, bo kupione narzędzie też ma architekturę i zwykle jest nią pipeline.

Najczęstsze pytanie to pierwszy wiersz: skąd mam wiedzieć, czy moja kolejność naprawdę jest stała? Wypisz ostatnie dwadzieścia realnych zgłoszeń, które przeszły przez ten proces, i zaznacz te, które wymagałyby innej sekwencji. Jeśli wyjdzie zero, masz odpowiedź, i to za cenę jednego popołudnia. Budujemy jedno i drugie, tak swoją drogą, a pipeline wyceniamy częściej. Jeśli wolisz, żeby ktoś przekonywał do drugiej strony na konkretnym projekcie, krótki audyt załatwia to na jednej rozmowie.

FAQ