LLM u agentskoj petlji po prirodi je nedeterministički; isti prompt, alati i podaci ne jamče uvijek isti rezultat. Jednom će odabrati pravi alat, drugi put prerano zaključiti da je posao gotov, vratiti drukčiji JSON ili krenuti popravljati nešto sasvim nepovezano. Temperatura postavljena na nulu varijacije može smanjiti, ali ih ne uklanja. Problem raste sa svakim krugom agentske petlje. Ako, samo radi ilustracije, pretpostavimo da svaki korak ima 95 posto izgleda za uspjeh, deset neovisnih koraka ima tek oko 60 posto izgleda da svi završe bez pogreške. Što agent dulje samostalno opaža, odlučuje, poziva alate i provjerava rezultate, više je mjesta na kojima može krenuti krivo. Sposobniji model taj problem ublažava, ali ga ne uklanja.

Pritom zapravo često nije kriv samo model, nego njegov harness, a tu je klasičan primjer context rot. Kako povijest zadatka raste, kontekst se puni starim odlukama, rezultatima alata i podacima pa model sve teže razlikuje bitno od nebitnog. Bez sažimanja i odbacivanja zastarjelog sadržaja dugotrajni zadaci postaju manje pouzdani. Ni previše alata ne pomaže. Dvadeset ili pedeset sličnih funkcija agentu samo otežava izbor, a dovoljna je promjena parametra, strukture povratnog JSON-a ili načina prijave pogreške da alat počne pogrešno koristiti. Tu su još latencija, memorija i RAG. Svaki novi korak može značiti novi poziv modelu, API-ju ili bazi, pa se jednostavan zadatak pretvara u desetak sekundi čekanja. Ako harness iz memorije ili RAG-a dovuče pogrešan dokument, LLM može vrlo uvjerljivo zaključivati na pogrešnim činjenicama. A bez provjere rezultata i jasno postavljenih guardrailova, radnje poput slanja poruke, brisanja podataka ili administrativnih zahvata brzo prestaju biti bezazlene.

Zato je korisno razlikovati fazu izrade (build-time) od faze izvođenja (run-time). LLM je izvrstan upravo u fazi izrade jer može istražiti API, predložiti arhitekturu, složiti prvi n8n workflow, napisati LangGraph kôd i testove te pronaći rubne slučajeve. U fazi izvođenja, međutim, LLM-u treba dati najmanju moguću i jasno ograničenu ulogu. Primjerice, neka pročita poruku, svrsta je u kategoriju „hitno“, „račun“, „newsletter“ ili „ostalo“ i vrati rezultat prema definiranoj shemi. Raspored izvršavanja, grananje, dozvole, ponovne pokušaje, idempotenciju, zapisivanje rezultata i završnu radnju bolje je prepustiti determinističkom workflowu.

Takva arhitektura možda nije toliko atraktivna kao ideja da se sve prepusti agentu, ali ju je mnogo lakše održavati. Agent ima smisla ondje gdje između ulaza i izlaza nešto treba protumačiti ili odlučiti, primjerice prepoznati desetke načina na koje korisnik može postaviti zapravo isto pitanje. Ostatak posla neka odradi klasična automatizacija. I tu se vraćamo na osnovno pitanje: treba li nam uopće agent? Automatizacija najviše smisla ima kada se posao često ponavlja i proces možemo jasno kontrolirati. Agent se dodaje samo ondje gdje pravila više nisu dovoljna. Za sve ostalo čovjek s dvije minute vremena još uvijek ima vrlo dobar omjer cijene, brzine i pouzdanosti.