Kako AI agent automatizuje dosadan posao u firmi

Prošle godine sam za jednog klijenta automatizovao posao koji je tri osobe radile po dva sata dnevno: prepisivanje podataka iz mejlova u CRM, kategorizacija, slanje potvrde. Šest meseci kasnije, agent radi 24/7, košta oko 40 EUR mesečno u API tokenima, i niko iz tima više ne otvara taj inbox osim kad agent eskalira nešto. Ovaj post je tačno taj proces, korak po korak, bez ulepšavanja.

Šta zapravo znači "AI agent" u produkciji

AI agent je program koji ima cilj, skup alata (funkcija) koje može da pozove, i petlju u kojoj LLM odlučuje koji alat da zove dok ne završi zadatak. To nije chatbot, i nije workflow sa fiksnim koracima. Razlika je ključna: workflow zna unapred šta radi, agent odlučuje u hodu.

U praksi, 70% zadataka koje firme zovu "AI agent" su zapravo deterministički workflow sa jednim LLM pozivom za klasifikaciju ili ekstrakciju. I to je sasvim u redu. Pravi agent ti treba samo kad imaš realnu nepredvidivost u ulazu, ili kad zadatak ima više od 3-4 koraka koji zavise od konteksta.

Moje pravilo: ako mogu da nacrtam ceo proces kao flowchart bez grananja "zavisi šta LLM kaže", to nije agent, to je pipeline sa LLM-om unutra. I pipeline je jeftiniji, brži, i lakši za debug. Ne pravi agenta zato što je trendy.

Kako da izabereš pravi posao za automatizaciju

Najgora greška koju vidim: ljudi krenu od "imamo AI, gde da ga ugurimo". Treba obrnuto. Krećeš od posla koji ispunjava četiri uslova:

1. Repetitivan i dovoljno čest (minimum nekoliko puta dnevno, idealno desetinama puta)
2. Strukturisan ulaz, strukturisan izlaz (mejl -> CRM zapis, PDF -> tabela, tiket -> kategorija + odgovor)
3. Tolerancija na grešku postoji, ili može da postoji kroz human-in-the-loop za rubne slučajeve
4. Stvarni trošak vremena koji možeš da izmeriš u satima mesečno

Evo brze tabele kako ja procenjujem kandidate:

Konkretno za prvi projekat u firmi, ja uvek biram nešto iz prvog ili četvrtog reda. Tu je ROI brz, neuspeh nije katastrofalan, i tim vidi rezultat za dve nedelje umesto za šest meseci.

Realan primer: agent koji obrađuje dolazne porudžbenice

Da ne pišem apstraktno, evo primera koji sam radio. Firma dobija porudžbenice mejlom, u različitim formatima (PDF, Excel, ponekad samo tekst u telu mejla). Operativac otvori mejl, prepiše stavke u ERP, pošalje potvrdu kupcu sa očekivanim datumom isporuke, i flaguje sve što je neobično.

Cilj agenta:

• Pročita mejl + attachmente
• Izvuče stavke (SKU, količina, tražen datum)
• Proveri zalihe i cene preko API-ja ERP-a
• Kreira porudžbenicu u sistemu
• Pošalje potvrdu kupcu
• Ako nešto ne štima (SKU ne postoji, količina van norme, kupac nije u sistemu), eskalira čoveku

To je agent jer u svakom koraku odluka zavisi od prethodne. Ako SKU ne postoji, agent treba da pokuša fuzzy match pre nego što eskalira. Ako kupac traži datum koji ne možemo da ispoštujemo, agent treba da predloži alternativu na osnovu zaliha. Tu fiksni workflow počinje da puca.

Korak po korak: kako ovo gradim

1. Mapiraj postojeći proces sa čovekom koji ga radi

Ne pretpostavljaj. Sedi pored operativca dva sata i gledaj. Pišeš svaki edge case koji vidiš. Ja sam ovde naučio da operativac u glavi radi pet provera koje niko nije nikad zapisao, i te provere su pola vrednosti njegovog posla.

Output ovog koraka je dokument sa: tipovi ulaza (sa primerima), koraci, sve provere, sve "ako se dogodi X onda" pravila, i tipovi izlaza.

2. Definiši alate, ne prompt

Ovo je najveća zamka. Ljudi krenu od pisanja "ultimate prompt"-a od 2000 reči. Loše. Krećeš od liste alata (funkcija) koje agent treba da ima:

tools = [
    "read_email(message_id) -> EmailContent",
    "extract_attachments(message_id) -> list[File]",
    "parse_pdf(file) -> str",
    "search_product(query: str) -> list[Product]",
    "check_stock(sku: str) -> StockInfo",
    "get_customer(email: str) -> Customer | None",
    "create_order(customer_id, items: list) -> OrderId",
    "send_email(to, subject, body)",
    "escalate_to_human(reason: str, context: dict)",
]

Svaki alat treba da bude tanka funkcija koja radi jednu stvar i vraća strukturisan rezultat. LLM nikad ne kuca SQL direktno, ne pravi HTTP zahteve sirovo, ne dotiče ništa što može da pukne na neočekivan način. Ti kontrolišeš površinu napada.

3. Napiši sistemski prompt kao runbook

Sistemski prompt nije "ti si pomoćni asistent". Sistemski prompt je runbook. Piši ga kao da pišeš dokumentaciju za novog zaposlenog koji prvi dan radi taj posao:

• Šta je tvoj cilj
• Koje alate imaš i kada koji koristiš
• Šta su pravila firme (npr. "nikad ne potvrđuj porudžbenicu preko 50.000 EUR bez eskalacije")
• Kako rukuješ greškama
• Kako izgleda mejl koji šalješ kupcu (sa primerom)
• Kada eskaliraš čoveku

Drži ga ispod 1500 tokena ako možeš. Sve preko toga obično znači da treba da podeliš agenta na dva manja.

4. Stavi tvrde guardrails van LLM-a

Ovo je deo gde inženjeri sa iskustvom razlikuju od onih koji su čitali tutorijale. Nikad ne veruj LLM-u za nešto što ne sme da pođe naopako.

Primer: agent nikad ne sme da pošalje mejl kupcu bez provere da je to polje validan mejl koji postoji u CRM-u. Ta provera nije u promptu, ona je u Python kodu funkcije send_email. Ako LLM pokuša nešto čudno, funkcija odbije i vrati grešku, koju agent vidi i može da reaguje.

def send_email(to: str, subject: str, body: str):
    if not is_valid_email(to):
        return {"error": "invalid_email"}
    if to not in known_customer_emails():
        return {"error": "unknown_recipient", "action": "escalate"}
    if contains_pii_leak(body):
        return {"error": "pii_check_failed"}
    return _actually_send(to, subject, body)

5. Petlja sa budžetom

Agent radi u petlji: LLM gleda kontekst, bira alat, dobije rezultat, ponavlja. Bez ograničenja, agent može da uđe u beskonačnu petlju i napravi račun od 200 EUR za jedan zadatak. Uvek stavi tvrde limite:

• Maksimalan broj iteracija (ja obično krećem od 15)
• Maksimalan broj tokena po zadatku
• Timeout po alatu
• Cost ceiling po zadatku, sa eskalacijom kad se približi

Kako verifikuješ da agent stvarno radi

Ovo je deo koji svi preskaču, i zato čujem priče kako "AI agent je halucinirao i poslao kupcu pogrešnu cenu". Verifikacija ide u tri sloja.

Sloj 1: Eval set pre puštanja u produkciju. Uzmi 50-100 realnih primera iz proteklih meseci, sa tačnim rezultatima. Pusti agenta na njih u shadow modu (ne šalje stvarno mejlove, samo loguje šta bi uradio). Uporedi sa stvarnim rezultatima. Ja ne idem u produkciju ispod 95% tačnosti na ovom setu, i ispod 99% za "kritične" odluke (slanje mejla kupcu, kreiranje porudžbenice).

Sloj 2: Shadow mode u produkciji. Pusti agenta paralelno sa čovekom dve nedelje. Agent radi sve, ali ne deluje, samo loguje. Operativac radi normalno. Pa uporediš. Ovo otkriva edge case-ove koje eval set nije pokrio.

Sloj 3: Postupno puštanje sa human-in-the-loop. Prvo agent radi 10% saobraćaja sa obaveznom ljudskom potvrdom pre slanja. Pa 50% bez potvrde za niskorizične slučajeve. Pa 100% sa eskalacijom samo za rubne slučajeve. Nikad ne ideš od 0 na 100 preko noći.

Za stalno praćenje u produkciji: loguj svaki agent run sa ulazom, korišćenim alatima, troškom i ishodom. Jednom nedeljno sample-uj 20 random run-ova i pregledaj ručno. Ako vidiš drift, vraćaš na shadow mode.

Zamke koje me koštaju vremena

Stvari koje sam morao da naučim kroz ožiljke:

• Context window nije memorija. Agent ne pamti šta je radio juče. Ako ti treba memorija, gradiš je sam (Postgres + retrieval), ne nadaš se da će LLM "zapamtiti".
• JSON mode nije garancija strukture. I dalje validiraš sa Pydantic-om ili Zod-om. Video sam Claude-a kako vraća validan JSON sa poljem koje ne postoji u šemi.
• Modeli se menjaju. Agent koji radi 99% danas može da padne na 94% kad provider izbaci novu verziju modela. Pin verziju eksplicitno i imaj regression eval u CI.
• Token cena nije glavni trošak. Glavni trošak je vreme inženjera kad agent pukne u 3 ujutru jer je external API vratio 503. Investiraj u retry logiku, dead letter queue i alerting od prvog dana.
• Multi-agent setupi su skupi. Pre nego što podeliš zadatak na "researcher agent + writer agent + reviewer agent", probaj jedan agent sa pametnijim promptom. U 80% slučajeva to je dovoljno, i 5x je jeftinije.

Stack koji koristim

Bez religijskog tona, evo šta meni radi za ovaj tip projekta:

• LLM: Claude Sonnet za većinu odluka, Haiku za jednostavnu klasifikaciju. Za on-prem klijente, Llama preko Ollama, plus pgvector za retrieval.
• Orkestracija: Kreći sa običnim Python-om i tool calling API-jem. Frameworks (LangChain, LlamaIndex) dodaješ samo kad ti stvarno trebaju, ne preventivno.
• Infrastruktura: AWS Lambda + EventBridge za scheduled trigere, SQS za queue, DynamoDB ili Postgres za state. Sve serverless da skalira na nulu kad nema posla.
• Monitoring: Strukturisani logovi u CloudWatch, plus custom dashboard sa metrikama (success rate, avg cost po zadatku, eskalacije po danu).

Za frontend prema operativcima (kad treba da pregledaju eskalacije), Next.js + Supabase, najjednostavnija stvar koja radi.

Šta bih ja uradio na tvom mestu

Ako vodiš firmu i razmišljaš o ovome, evo redosleda koji bih ja preporučio:

1. Prve dve nedelje: ne piši kod. Sedi sa timom i identifikuj 3-5 kandidata za automatizaciju. Izračunaj sate mesečno za svaki.
2. Izaberi jedan koji je srednje težine, ne najteži. Cilj prvog projekta je da tim vidi da ovo radi i da vi naučite kako se gradi.
3. Postavi merljiv cilj pre nego što počneš: "Agent obrađuje 80% porudžbenica bez ljudske intervencije, sa manje od 1% grešaka koje dospeju do kupca." Bez broja, nema projekta.
4. Budžetiraj 6-10 nedelja za prvi agent u produkciji ako kreneš od nule. Ne dve, ne 26. Ko ti kaže dve nedelje, prodaje ti demo, ne produkciju.
5. Drugi agent ide 3x brže jer već imaš infrastrukturu, eval framework i mentalne modele.

I ne kreći od najskupljeg modela. Krećeš od najjeftinijeg koji daje 90%+ na eval setu, pa nadograđuješ. Video sam projekte gde je prelazak sa Sonnet-a na Haiku za klasifikaciju sekcije smanjio mesečni račun za 70% bez pada tačnosti.

Zatvaranje

AI agent u firmi nije magija, to je obična softverska komponenta sa LLM-om u sredini i ozbiljnim zahtevima oko verifikacije i guardrails-a. Ko god ti obeća "agenta za dve nedelje", verovatno ti prodaje demo. Ko god ti kaže "treba ti šest meseci samo da počneš", verovatno gradi nešto što ti ne treba.

Ako razmišljaš o konkretnom procesu u svojoj firmi i hoćeš drugo mišljenje pre nego što počneš (ili usred projekta koji je zapeo), javi mi se na lazar-milicevic.com/#contact. Često je 45 minuta razgovora dovoljno da se vidi da li uopšte treba agent, ili je dovoljan tanji workflow.