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

Spis treści