LLM jako selektor akcji: dlaczego 72% to pułap, którego nie przeskoczysz bez zmiany architektury

Twój agent kończy zadanie w 1,8 sekundy, trace jest czysty, żadnego błędu w logach. A mimo to wybrał złe narzędzie. Nie wiesz o tym, bo Twój stack observability nie patrzy na jakość decyzji — patrzy na jej wykonanie. To nie jest problem promptu. To problem architektury.

Twój agent działa poprawnie — i właśnie dlatego nie widzisz, że się myli

Silent failure mode: latencja OK, trace czysty, LLM pewny siebie — wynik zły

Standardowy monitoring agenta mierzy to, co łatwo zmierzyć: czas odpowiedzi, liczbę tokenów, status HTTP narzędzia. Jeśli tool zwrócił 200, trace jest zielony. Problem w tym, że "narzędzie odpowiedziało poprawnie" i "agent wybrał właściwe narzędzie" to dwa różne zdania.

Autor eksperymentu opisanego na r/LangChain wskazuje wprost: observability stack nie flaguje błędów selekcji akcji — latencja i trace wyglądają poprawnie mimo złych wyborów [1]. Agent jest pewny siebie, bo LLM zawsze jest pewny siebie. Nie ma mechanizmu, który powiedziałby mu "poprzednim razem ta akcja nie zadziałała w tym kontekście".

Dlaczego 72% correct action rate to norma, nie wyjątek

Baseline LLM-driven action selection w benchmarku tego samego eksperymentu osiągnął 72% poprawnych akcji [1]. Brzmi nieźle — do momentu, gdy policzysz, co to znaczy w produkcji. Przy 1000 zadań dziennie 280 kończy się złym wyborem narzędzia. Część z nich zostanie naprawiona przez retry, część przez użytkownika, część po cichu zepsuje wynik.

72% to nie wyjątek od reguły — to właśnie reguła dla stateless LLM-selekcji w złożonych zadaniach [1]. I żaden lepszy prompt tego nie zmieni, bo problem leży głębiej.

LLM jako selektor akcji: dlaczego stateless decision-maker nie pasuje do stateful środowiska produkcyjnego

Każda decyzja od zera — brak pamięci o tym, co działało w poprzednich sesjach

LLM podejmuje każdą decyzję o wyborze narzędzia bez dostępu do historii wyników produkcyjnych. Nie wie, że w poprzednich 50 sesjach z podobnym zadaniem tool A działał w 91% przypadków, a tool B w 43%. Nie ma tej informacji, bo nikt mu jej nie daje.

To jest główna przepaść między demo a produkcją: brak mechanizmów uczenia się z błędów między sesjami [6]. W demo agent wygląda świetnie, bo zadania są proste i izolowane. W produkcji kontekst się komplikuje, narzędzia mają ograniczenia, a LLM powtarza te same błędy, bo każda sesja zaczyna się od zera.

ReAct i tool-calling: gdzie kończy się elastyczność, a zaczyna losowość

ReAct i function-calling to dziś dominujące wzorce selekcji akcji — i jednocześnie rosnąca krytyka ich niezawodności w złożonych zadaniach [6]. Elastyczność, którą dają, ma cenę: niedeterminizm. Ten sam prompt z minimalnie innym kontekstem może wybrać inne narzędzie. W środowisku produkcyjnym, gdzie kontekst zmienia się przy każdym żądaniu, to nie jest cecha — to ryzyko.

Produkcyjne systemy agentowe coraz częściej rozdzielają odpowiedzialność: LLM do rozumowania, deterministyczne komponenty do routingu i orkiestracji [5]. Nie dlatego, że LLM jest zły — ale dlatego, że do selekcji akcji nie potrzeba rozumowania. Potrzeba historii wyników.

Benchmark: trzy architektury, jeden zestaw zadań, twarde liczby

Eksperyment opisany jednocześnie na r/LangChain i r/aiagents w marcu 2026 roku testował trzy podejścia na tym samym zestawie zadań [1][2]:

Baseline — LLM-driven selection: 72% poprawnych akcji. Agent samodzielnie wybiera narzędzie na podstawie opisu zadania i dostępnych toolów. Brak dostępu do historii wyników.

LLM z outcome-scored recommendations w prompcie: 87% poprawnych akcji. Do promptu wstrzykiwane są rekomendacje oparte na historii wyników dla podobnych zadań. LLM nadal podejmuje ostateczną decyzję, ale ma kontekst historyczny.

Deterministyczny outcome-based router bez LLM w pętli decyzyjnej: 94% poprawnych akcji. Router samodzielnie wybiera narzędzie na podstawie similarity search i weighted success rate. LLM zostaje w architekturze, ale tylko do interpretacji wyniku i generacji tekstu.

Różnica między baseline a routerem deterministycznym wynosi 22 punkty procentowe [1]. Przy 1000 zadań dziennie to 220 mniej błędnych wyborów. Przy 10 000 — 2200.

Jak działa outcome-based router — architektura krok po kroku

Co trafia do logów: zadanie, kontekst narzędzi, wybrana akcja, ocena wyniku

Fundament całego systemu to log każdej decyzji routingowej z oceną wyniku — to warunek konieczny do budowy outcome-based systemu [4]. Bez tego nie masz danych, na których router może operować.

Każdy wpis w logu zawiera cztery elementy: opis zadania (lub jego embedding), kontekst dostępnych narzędzi, wybraną akcję oraz binarną lub skalarną ocenę wyniku. Ocena może być automatyczna (czy downstream task się powiódł?) lub manualna, ale musi być spójna.

Similarity search po historii + weighted success rate jako mechanizm routingu

Gdy przychodzi nowe zadanie, router robi similarity search po historycznych logach — szuka wpisów z podobnym zadaniem i podobnym kontekstem narzędzi [2]. Dla każdego kandydującego narzędzia liczy weighted success rate: ile razy to narzędzie zadziałało poprawnie w podobnych warunkach, z wagą wyższą dla nowszych wpisów.

Narzędzie z najwyższym weighted success rate w danym kontekście wygrywa. Bez LLM, bez promptu, bez niedeterminizmu. Deterministycznie.

Gdzie LLM zostaje: interpretacja wyniku i generacja tekstu, nie wybór toola

To ważne rozróżnienie: LLM nie znika z architektury [1][2]. Zostaje tam, gdzie jest naprawdę dobry — w interpretacji tego, co narzędzie zwróciło, i w generacji odpowiedzi dla użytkownika. Do tego nie potrzeba historii wyników. Do tego potrzeba rozumowania języka naturalnego, i tu LLM nie ma konkurencji.

Podział odpowiedzialności jest więc prosty: router decyduje co wywołać, LLM decyduje co powiedzieć o wyniku. Każdy komponent robi to, do czego jest zoptymalizowany.

EvoRoute i dynamiczne sieci agentów: czy nauka potwierdza ten kierunek?

EvoRoute: experience-driven self-routing jako formalizacja tego samego pomysłu

W styczniu 2025 roku na arXiv ukazała się praca EvoRoute, która formalizuje dokładnie ten pomysł: experience-driven self-routing jako alternatywa dla statycznego LLM-driven selection [3]. System przechowuje historię wykonań i używa jej do dynamicznego routingu nowych zadań do właściwych sub-agentów.

EvoRoute działa w kontekście sieci agentów, nie pojedynczego agenta z toolami — ale mechanizm jest identyczny. Historia wyników jako podstawa decyzji routingowej, nie prompt i nie statyczna reguła. Eksperyment z Reddita i praca akademicka doszły do tego samego miejsca niezależnie, co jest dobrym sygnałem dla builderów rozważających tę architekturę.

Kiedy deterministyczny router zawodzi — warunki brzegowe i cold start problem

Tu jest realne ograniczenie, którego nie warto pomijać: deterministyczny router wymaga wystarczającej historii wyników przed wdrożeniem [4]. Bez logów nie ma similarity search. Bez similarity search router nie ma podstawy do decyzji.

Cold start problem jest realny. Jeśli budujesz agenta od zera lub wdrażasz go w nowym domenie, przez pierwsze tygodnie nie masz wystarczających danych. W tym oknie LLM-driven selection lub hybryda (LLM z rekomendacjami w prompcie, jak w wariancie 87%) jest lepszym wyborem niż pusty router.

Drugi warunek brzegowy: zadania muszą być klasyfikowalne. Jeśli każde zadanie jest na tyle unikalne, że similarity search nie zwraca nic sensownego z historii, router nie zadziała lepiej niż losowy wybór [4]. To architektura dla powtarzalnych wzorców zadań, nie dla one-off requestów.

Werdykt: kiedy warto wymienić LLM-selektor na router, a kiedy nie

Nie każdy agent potrzebuje tej zmiany. Oto kryterium decyzji:

Warto wymienić, jeśli:

• Masz co najmniej kilkaset historycznych logów z ocenami wyników w danej domenie zadań.
• Twoje zadania tworzą powtarzalne wzorce — podobne zapytania wracają regularnie.
• Mierzysz jakość selekcji akcji, nie tylko latencję i error rate.
• Działasz w polskiej firmie z SLA na dokładność — np. w obsłudze klienta, gdzie błędny routing oznacza eskalację do człowieka i realny koszt operacyjny.

Nie warto wymieniać, jeśli:

• Agent jest w fazie prototypu i nie ma jeszcze logów produkcyjnych.
• Zadania są zbyt różnorodne, żeby similarity search dawał sensowne wyniki.
• Masz mniej niż kilkadziesiąt unikalnych wzorców zadań — tu prosta reguła deterministyczna zadziała lepiej niż router oparty na historii.

Trzy pierwsze kroki na ten tydzień:

Pierwszy: zacznij logować każdą decyzję routingową już dziś — zadanie, dostępne narzędzia, wybrana akcja, wynik. Bez tego nie zbudujesz niczego.

Drugi: po zebraniu pierwszych 200–300 wpisów policz baseline correct action rate dla swojego agenta. Jeśli jesteś w okolicach 72%, masz potwierdzenie problemu [1].

Trzeci: zanim przepiszesz router, przetestuj wariant pośredni — wstrzyknij outcome-scored recommendations do promptu. Jeśli skoczysz z 72% do okolic 87% [1], masz dowód, że historia wyników działa w Twoim kontekście. Pełny deterministyczny router to kolejny krok, nie pierwszy.

Zmiana architektury nie jest konieczna od razu. Ale logowanie decyzji — tak.

Źródła

[1] I replaced my agent's LLM-driven action selection with outcome-based routing — r/LangChain — https://www.reddit.com/r/LangChain/comments/1sxvbsz/i_replaced_my_agents_llmdriven_action_selection/

[2] I replaced my agent's LLM-driven action selection with outcome-based routing — r/aiagents — https://www.reddit.com/r/aiagents/comments/1sxvdwc/i_replaced_my_agents_llmdriven_action_selection/

[3] EvoRoute: Experience-Driven Self-Routing LLM Agent Systems — arXiv — https://arxiv.org/html/2601.02695v1

[4] AI Agent Routing: Tutorial & Best Practices — Patronus AI — https://www.patronus.ai/ai-agent-development/ai-agent-routing

[5] How Building AI Agents Has Changed in 2026 — Pulumi Blog — https://www.pulumi.com/blog/how-building-ai-agents-has-changed/

[6] LLM agents: From demo to full automation (2026) — Make Blog — https://www.make.com/en/blog/llm-agents