AI agenti i agentic workflows: šta je stvarno

Prošle nedelje sam gledao demo gde "agent" u tri koraka rezerviše let, hotel i sastanak. Publika oduševljena. Ja sam u međuvremenu razmišljao koliko bi taj isti sistem koštao mesečno u produkciji, koliko puta bi halucinirao pogrešan datum i ko bi bio odgovoran kad rezerviše Beograd umesto Berlina. To je razlika između demoa i sistema koji radi.

Gradio sam agentske sisteme u produkciji dovoljno dugo da razumem gde stvarno donose vrednost, a gde su marketing preko realne inženjerske potrebe. Ovaj tekst je moj trezven pogled iznutra, bez hype-a, ali i bez odbacivanja onoga što stvarno radi.

Šta je zapravo "agent" u produkciji

Agent nije LLM kome smo dodali funkcije. Agent je sistem u kome model bira sledeći korak na osnovu prethodnog rezultata, u petlji, dok ne postigne cilj ili ne odustane. Ključna reč je "bira". Ako ti unapred znaš tačan redosled koraka, to je pipeline, ne agent, i skoro uvek je jeftiniji, brži i pouzdaniji.

Anthropic je u svom blogu o gradnji efektivnih agenata napravio korisnu podelu koju i sam koristim u glavi:

• Workflow: unapred definisani koraci, LLM na fiksnim mestima. Deterministički skelet.
• Agent: LLM dinamički odlučuje šta dalje, koje alate poziva, kada staje.

U 80% slučajeva koje sam video u praksi, klijent zove "agent" nešto što je zapravo workflow sa jednim ili dva LLM koraka. I to je dobra vest, jer je jeftinije i mnogo lakše za debagovanje.

Gde agenti stvarno rade

Iz mog iskustva, postoje tri konteksta u kojima agentska petlja opravdava svoju cenu i nepredvidljivost:

1. Zadaci gde je prostor koraka prevelik da bi se hardkodovao. Klasičan primer je istraživanje: prikupi izvore o temi, uporedi ih, sintetizuj. Ne znaš unapred koliko izvora, koje pretrage, kada da staneš. Moj ContentStudio radi tako za deo koji radi konkurentsku analizu, i tu je agent stvarno na svom mestu.

2. Coding asistenti sa alatima. Claude Code, Cursor agent mod, Aider. Ovi rade jer je feedback loop veoma jak (kompajler, testovi, linter), a domen prirodno self-verifying. Ako kod ne radi, agent to zna odmah.

3. Operativni zadaci sa jasnim uspehom. Odgovor na ticket koji zahteva pretragu baze znanja, klasifikaciju i eskalaciju. Uspeh je merljiv (rešeno ili prosleđeno), a rizik ograničen (čovek pregleda pre slanja).

Van ovih zona, agent obično dodaje trošak i nepredvidljivost bez proporcionalne dobiti.

Gde su agenti preskupa komplikacija

Ovde je moj najoštriji stav. Većina biznis automatizacija koje se prodaju kao "agentske" su zapravo linearni tokovi gde je agent najgori mogući izbor.

Primeri koje viđam skoro nedeljno:

U svakom od ovih slučajeva, deterministički pipeline sa jednim LLM pozivom je 5-10x jeftiniji, 3-5x brži, i mnogo lakši za debagovanje. Agentska petlja se plaća po tokenu za svaki korak, a većina koraka je bila predvidljiva od početka.

Konkretan primer troška iz projekta: linearni pipeline za klasifikaciju i rutiranje ticket-a košta oko 0.003 USD po ticketu. Ista funkcionalnost u agentskoj petlji sa ReAct pristupom i mogućnošću da sam bira alate ispada oko 0.02-0.05 USD po ticketu, jer petlja u proseku napravi 4-7 poziva. Na 50.000 ticket-a mesečno, to je razlika između 150 USD i 2500 USD, za istu izlaznu vrednost.

Realna cena agentske petlje

Kada procenjujem da li nešto treba da bude agent, mentalno prolazim kroz pet stavki. Ovo je heuristika koju koristim pre nego što napišem prvi red koda:

1. Broj koraka: Da li prosečan izvršni put ima više od 3-4 koraka koji se ne mogu unapred složiti? Ako ne, workflow.
2. Grananje: Da li se putanja stvarno menja u zavisnosti od međurezultata, ili samo teoretski? Ako je 90% slučajeva ista putanja, hardkoduj glavni put i imaj fallback.
3. Verifikacija: Postoji li automatski način da proverimo uspeh (test, šema, external API)? Bez ovoga, agent gradi na pesku.
4. Cena greške: Šta se dešava ako pogreši? Ako je odgovor "moramo da vratimo pare klijentu" ili "izgubili smo klijenta", human-in-the-loop je obavezan.
5. Vremenski budžet: Da li može da radi 30 sekundi pa i 5 minuta, ili korisnik čeka? Agenti su spori.

Ako na više od dva pitanja odgovor gura ka "ne treba agent", ne pravim agent. Pravim workflow sa jednim inteligentnim korakom.

Kako pravim agentske sisteme koji ne padnu

Kada zaista treba agent, ovo su pravila koja štite od katastrofe u produkciji:

Ograniči prostor alata

Agent sa 20 alata je agent koji halucinira. Praktičan limit je 5-8 alata po petlji, sa jasnim opisom kada se koji zove. Ako imaš više od toga, razbij u više specijalizovanih agenata sa jasnim granicama, ili napravi hijerarhiju (orchestrator koji poziva podagente).

Tvrdi limiti

Nikad ne pokrećem agentsku petlju bez ovoga:

MAX_ITERATIONS = 15
MAX_TOKENS_PER_RUN = 100_000
MAX_WALL_CLOCK_SECONDS = 180
MAX_COST_USD_PER_RUN = 0.50

Ovo nisu preporuke, ovo su hard stopovi koji ubijaju proces. Bez njih ćeš jednog dana dobiti račun od 4000 USD zbog jednog stuck loop-a. Video sam to kod drugih, nisam kod sebe, upravo zbog ovakvih ograničenja.

Strukturirani izlaz na svakom koraku

Ne dozvoljavam agentu da vraća free-form tekst između koraka. Svaki alat vraća JSON sa definisanom šemom, koju validiram pre nego što je prosledim nazad modelu. Ako validacija padne, retry sa greškom kao delom konteksta.

Idempotentnost alata

Ako agent pokuša isti korak dva puta (a hoće), ne sme da napravi dupli entry u bazi. Svaki write-alat mora da ima idempotency key. Ovo je detalj koji većina tutorijala preskoči, a bez njega agent u produkciji je bomba.

Observability od nultog dana

Logujem svaki tool call, svaki intermediate reasoning trace, svaki token count. Bez ovoga ne možeš da debaguješ zašto je agent doneo pogrešnu odluku pre tri sata. Koristim OpenTelemetry sa custom span-ovima za svaku iteraciju petlje, i to ide u strukturisanu bazu (ne samo u logove).

Human checkpoint na skupim akcijama

Za bilo koju akciju koja košta više od simbolične sume ili šalje spoljni komunikacioni signal (email klijentu, izmena naloga, transakcija), agent staje i čeka odobrenje. Ovo nije "manje autonoman", ovo je zdrav sistem.

Šta o "multi-agent" arhitekturama

Multi-agent je najprodavaniji, a najmanje razumljen deo priče. Ideja da imaš "menadžer agenta" koji koordinira "istraživač agenta", "pisac agenta" i "kritičar agenta" zvuči elegantno u prezentaciji.

U praksi:

• Cena se množi brojem agenata (svaki ima svoj kontekst).
• Latencija raste linearno ili gore.
• Debagovanje postaje pakao jer greška može biti u bilo kom agentu ili u komunikaciji.
• Konsenzus mehanizmi (glasanje, debata) često daju samo neznatno bolji rezultat od jednog dobrog agenta sa dobrim promptom.

Cognition (autori Devina) su pisali o tome i moje iskustvo se poklapa: većina multi-agent sistema u produkciji su ustvari jedan glavni agent sa specijalizovanim tool-ovima koji unutra pozivaju druge LLM pozive. To je pragmatičan pristup i mnogo je lakši za održavanje.

Pravi multi-agent sistemi imaju smisla kada su podzadaci stvarno paralelizabilni i kada svaki agent ima drastično drugačiji sistem prompt ili pristup alatima. Za tekstualnu generaciju i istraživanje, retko.

Realan primer: kada sam izabrao workflow umesto agenta

U ContentStudio pipeline-u, deo koji generiše i objavljuje sadržaj mogao je da bude agentski. Zamislio sam agenta koji sam istražuje temu, bira ključne reči, piše, optimizuje SEO, generiše slike, objavljuje.

Umesto toga sam napravio 7 fiksnih koraka. Svaki korak ima jasan ulaz i izlaz, svaki je zaseban Lambda function, svaki se može retry-ovati nezavisno. LLM se koristi samo tamo gde inteligencija stvarno treba (research sinteza, pisanje, optimizacija naslova).

Rezultat:

• Predvidljiva cena po članku (oko 0.15-0.30 USD).
• Predvidljivo vreme (2-4 minuta po članku).
• Ako pukne u koraku 5, ne rušim korake 1-4.
• Debag je trivijalan: log po koraku, jasno gde je pukao.

Agentska varijanta bi verovatno koštala 3-5x više po članku, radila bi neujednačeno, i debug bi bio noćna mora. Isti izlazni kvalitet.

Jedini deo koji je stvarno agentski je istraživanje konkurencije, jer tu unapred ne znam koliko strana treba pročitati ni kada da stanem. Tu petlja ima smisla, i tu je toleriram sa svim gore navedenim ograničenjima.

Šta bih ja uradio

Ako ti neko sada predlaže agentsku arhitekturu za tvoj biznis proces, postavi ova pitanja pre nego što potpišeš:

1. Nacrtaj tok trenutnog procesa na papiru. Ako staje u linearnu listu, agent ti ne treba. Treba ti pipeline sa jednim ili dva LLM koraka.
2. Pitaj za mesečnu procenu troška po jedinici (per-ticket, per-email, per-report). Ako ne mogu da odgovore, ne znaju šta grade.
3. Traži plan za kill switch, cost caps i human checkpoints. Odsustvo ovoga znači da sistem još nije spreman za produkciju.
4. Insistiraj na observability alatima. Bez logova tool poziva i reasoning trace-ova, ne možeš da održavaš sistem.
5. Kreni od najmanjeg mogućeg oblika. Prvi deploy nikad ne treba da bude potpuno autonoman agent. Uvek kreni od workflow-a, dodaj petlju samo tamo gde je stvarno dokazano potrebna.

Moj generalan stav: manje autonomije, više vrednosti. Sistem koji dobro radi 95% predvidljivog posla i pošteno traži čoveka za 5% nepredvidljivog je bolji od agenta koji juri savršenu autonomiju i pukne na produkciji.

Zatvaranje

Agenti su stvarna tehnologija sa realnom vrednošću u uskim slučajevima. Većina onoga što se danas prodaje kao agentska automatizacija je zapravo dobar workflow kome je stavljen skuplji šešir. Kada razumeš razliku, štediš klijentu novac i sebi nedelje debagovanja.

Ako razmišljaš o AI automatizaciji za svoju firmu i nisi siguran da li ti treba agent ili nešto jednostavnije, slobodno se javi preko lazar-milicevic.com/#contact. Uvek radije preporučim manji sistem koji radi nego veći koji zvuči impresivno.