Kiedy nie budować agenta

przez Łukasz | cze 5, 2026

Cały ten hub uczy, jak budować agenty.

Ten wpis jest o tym, że najczęściej nie powinieneś.

Jest taka pokusa, która przychodzi po przeczytaniu kilku tekstów o agentach: zbudujmy agenta. Do obsługi maili. Do raportów. Do tego procesu, który teraz robi się ręcznie. Agent brzmi jak odpowiedź na wszystko, co ma w sobie słowo „automatyzacja”.

W większości tych przypadków agent jest złą odpowiedzią. Nie dlatego, że jest słaby — dlatego, że jest za duży. To jak wynajęcie pracownika z własną głową do zadania, które rozwiązuje formularz. Zadziała. Będzie kosztować więcej, działać wolniej i mylić się tam, gdzie formularz nigdy by się nie pomylił.

Ten wpis jest mapą: kiedy wystarczy coś prostszego — i jak rozpoznać te rzadsze przypadki, w których agent faktycznie jest właściwym narzędziem.

Czym płacisz za agenta

Najpierw uczciwie o cenie, bo bez niej cała reszta nie ma sensu. Agent — model w pętli, z dostępem do narzędzi i swobodą decydowania, co zrobić dalej — kupuje Ci jedną rzecz: elastyczność. Zdolność do radzenia sobie z sytuacją, której nie dało się przewidzieć z góry.

Za tę elastyczność płacisz w czterech walutach naraz:

Przewidywalnością. Agent sam decyduje o krokach, więc ten sam input może dać różną ścieżkę. To z natury mniej powtarzalne niż proces o ustalonych krokach.

Kosztem. Pętla obraca się wielokrotnie, każdy obrót to wywołanie modelu. Ile to realnie kosztuje w produkcji, liczy osobny wpis serii — i sumy potrafią zaskoczyć.

Czasem. Każda iteracja to latencja. Proces, który deterministycznie trwałby sekundę, jako agent może trwać kilkanaście.

Powierzchnią ataku. Agent, który działa i wciąga treści z zewnątrz, otwiera się na zatruty kontekst — problem, którego prosty skrypt po prostu nie ma.

Jeśli nie potrzebujesz elastyczności, którą agent daje — płacisz te cztery ceny za nic.

Drabina: użyj najprostszego, co rozwiązuje problem

Zanim sięgniesz po agenta, przejdź drabinę od dołu. Zatrzymaj się na pierwszym szczeblu, który załatwia sprawę.

1. Deterministyczna automatyzacja — bez LLM w ogóle. Jeśli zadanie jest oparte na regułach, ma ustaloną strukturę i przewidywalne wejście — nie potrzebuje modelu. „Gdy przyjdzie faktura, zapisz załącznik i dodaj wiersz do arkusza” to workflow, nie agent. W n8n to przepływ bez węzła AI. Jest darmowy w utrzymaniu, działa w milisekundy i nigdy nie „halucynuje”.

2. Pojedyncze wywołanie LLM. Jeśli potrzebujesz zrozumienia albo wygenerowania języka, ale jednorazowo, bez wieloetapowych decyzji — wystarczy jedno wywołanie. Klasyfikacja zgłoszenia, wyciągnięcie danych z tekstu, streszczenie, wygenerowanie opisu. Jedno wejście, jedno wyjście. To nie agent — to model użyty raz.

3. Łańcuch o ustalonych krokach. Jeśli kroków jest kilka, ale to Ty definiujesz ich kolejność, a nie model — zbuduj stały pipeline. „Streść → przetłumacz → sformatuj” to trzy wywołania w ustalonej sekwencji. Przewidywalne, testowalne, tańsze niż agent. Kluczowa różnica: kolejność jest sztywna, bo Ty ją znasz z góry.

4. RAG — gdy problem to „odpowiedz z wiedzy”. Jeśli zadanie sprowadza się do odpowiadania na podstawie bazy wiedzy, a nie do działania — najczęściej wystarczy RAG, bez całej maszynerii agenta. Reguła z tamtego wpisu wraca tu jako test: RAG odpowiada, agent realizuje cel. Jeśli nie potrzeba realizować celu w wielu krokach — nie potrzeba agenta.

5. Agent — dopiero gdy ścieżki nie da się ustalić z góry. Na ten szczebel wchodzisz, gdy żaden niższy nie wystarcza: gdy kolejne kroki naprawdę zależą od tego, co agent odkryje po drodze, gdy narzędzia trzeba wywoływać w kolejności, której nie znasz zawczasu, gdy zadanie wymaga adaptacji do sytuacji. Wtedy — i dopiero wtedy — elastyczność agenta zarabia na swoje cztery ceny.

Test rysunku: czy umiesz narysować ten proces?

Jest jedno pytanie, które rozstrzyga szybciej niż cała drabina: czy umiesz narysować ten proces jako schemat blokowy z góry?

Jeśli tak — jeśli da się go zamknąć w „jeśli to, zrób tamto”, w ustalonych gałęziach i krokach — to nie potrzebujesz agenta. Potrzebujesz tego schematu, zbudowanego wprost. Schemat jest tańszy, szybszy i przewidywalny.

Agent jest dla sytuacji, w których schematu nie da się narysować z góry, bo ścieżka zależy od tego, co odkryje się w trakcie. „Zbadaj ten problem i zaproponuj rozwiązanie” nie da się narysować z góry — nie wiesz, co agent znajdzie i dokąd go to poprowadzi. „Przetwórz tę fakturę” — da się narysować w pięć minut. Pierwsze to robota dla agenta. Drugie nigdy nią nie było.

Pułapka „agent-washingu”

Warto nazwać zjawisko, które zaciemnia te decyzje: nazywanie agentem wszystkiego, co ma w środku LLM, bo tak brzmi nowocześniej. Przepływ z jednym wywołaniem modelu to nie agent. Łańcuch o stałych krokach to nie agent. RAG to nie agent.

To nie jest spór o słowa. Gdy nazwiesz prosty pipeline „agentem”, zaczynasz go budować i utrzymywać jak agenta — z całą złożonością, kosztem i nieprzewidywalnością, których ten pipeline wcale nie wymagał. Trafna nazwa prowadzi do trafnej architektury. Agent to model, który decyduje o własnych krokach w pętli. Jeśli tego nie ma — masz coś prostszego, i dobrze.

A determinizm?

Jest jeszcze jeden powód, dla którego niższe szczeble drabiny bywają po prostu lepsze, nie tylko tańsze. Deterministyczna automatyzacja jest deterministyczna — to samo wejście zawsze daje to samo wyjście. Agent z natury taki nie jest; najwyżej można mu narzucić namiastkę powtarzalności (o czym przy context engineeringu i w eksperymentach na promptujemy.pl).

W procesach, gdzie powtarzalność jest wymogiem — rozliczenia, zgodność, cokolwiek, co musi dać identyczny wynik za każdym razem — to nie jest detal. To argument, żeby zejść z drabiny tak nisko, jak się da. Czasem najlepszą „automatyzacją AI” jest ta, która AI w krytycznym miejscu w ogóle nie używa.

Co z tego wynika

Agent to nie poziom wyżej. To inne narzędzie do innego problemu — problemu, którego nie da się rozpisać z góry. Tam, gdzie ścieżka jest znana, prostsze rozwiązanie nie jest „gorszą wersją agenta”. Jest właściwą wersją.

Reguła do zabrania: nie pytaj, czy da się zbudować agenta — pytaj, czy problem naprawdę wymaga jego elastyczności. Jeśli umiesz narysować proces, narysuj go i zbuduj wprost. Jeśli nie umiesz — bo zależy od tego, co odkryje się po drodze — to wtedy reszta tego huba jest dla Ciebie: jak agent działa od środka i jak składać mu kontekst, żeby tę elastyczność wykorzystać dobrze.

Najlepszy agent to często ten, którego nie zbudowałeś — bo zauważyłeś w porę, że wystarczył formularz.


Pojęcia ze słownika: Agent AI · RAG · Agent loop · Tool use · Human-in-the-loop · Structured output

Agent kończy, ale zadania nie wykonał

Agent kończy, ale zadania nie wykonał

Objawy Agent odpowiada: „Przygotowałem i wysłałem potwierdzenie do klienta." Potwierdzenie nie zostało wysłane. Albo: „Zaktualizowałem wszystkie rekordy" — zaktualizował trzy z dwunastu. Albo: „Nie znalazłem żadnych zamówień" — bo narzędzie zwróciło błąd, którego nikt...

Agent zrobił coś, o co nikt nie prosił

Agent zrobił coś, o co nikt nie prosił

Objawy Operacja, której nikt nie zlecił. Dane wysłane pod adres, którego nie ma w żadnej konfiguracji. Rekord zmieniony poza zakresem zadania. Odpowiedź, z której wynika, że agent dostał instrukcje od kogoś innego niż ty. Cecha wspólna: technicznie wszystko zadziałało...

Agent zrobił to samo dwa razy

Agent zrobił to samo dwa razy

Objawy Ten syndrom różni się od pozostałych jedną rzeczą: objaw widzi klient, nie ty. Trzy identyczne wiadomości w skrzynce. Dwa zamówienia zamiast jednego. Podwójne obciążenie. Duplikaty rekordów, które ktoś zauważa tydzień później. W twoim dzienniku wszystko wygląda...

Agent gubi wątek w długim zadaniu

Agent gubi wątek w długim zadaniu

Objawy Pierwsze kroki idą wzorowo. Po kilkunastu agent zaczyna się rozjeżdżać. Przestaje przestrzegać reguły z promptu systemowego, której trzymał się na początku. Zmienia format odpowiedzi w połowie zadania. Wraca do czegoś, co już ustalił, i ustala to inaczej....

Agent podaje dane, których nie ma

Agent podaje dane, których nie ma

Objawy Numer zamówienia w idealnym formacie, którego nie ma w bazie. Kwota, której w dokumencie nie ma. Nazwa pola API, które nigdy nie istniało. Cytat z regulaminu, brzmiący dokładnie jak reszta regulaminu i w nim nieobecny. Cecha wspólna wszystkich tych przypadków:...

Działał wczoraj, dziś nie działa

Działał wczoraj, dziś nie działa

Objawy Nic się nie wywala. Nie ma wyjątków, nie ma timeoutów, dziennik wygląda tak samo jak zawsze. Po prostu odpowiedzi są gorsze. Postacie, w jakich to się objawia: Jakość. Agent zaczyna pomijać kroki, które wcześniej wykonywał, albo odpowiada ogólniej. Format....

Agent wybiera złe narzędzie

Agent wybiera złe narzędzie

Objawy Agent odpowiada nie na to pytanie. Pobiera listę zamówień, gdy pytano o jedno konkretne. Odpowiada z pamięci, choć miał sprawdzić w bazie. Albo sięga po właściwe narzędzie i wpisuje w argumenty coś, czego nie da się użyć. Sygnał, który odróżnia ten syndrom od...

Agent kręci się w kółko

Agent kręci się w kółko

Objawy Agent wykonuje kolejne obroty pętli, nie zbliżając się do zakończenia zadania. W dzienniku widać jedną z trzech postaci. Powtórzenie. To samo narzędzie, te same argumenty, raz za razem — czasem dziesiątki razy pod rząd. Oscylacja. Agent wywołuje na przemian dwa...