Softver je oduvijek odgovarao na upute. Agenti umjetne inteligencije obećavaju nešto zanimljivije: sustave koji mogu promatrati kontekst, oblikovati plan, koristiti odobrene alate i nastaviti se kretati prema ishodu bez potrebe da osoba opisuje svaki klik.

To agente ne čini čarobnim suradnicima. Čini ih novom arhitektonskom odgovornošću. Korisno pitanje nije: „Kako dodati agenta?” Nego: „Koje odluke ovaj sustav može sigurno donositi, koje bi dokaze trebao koristiti i gdje čovjek mora zadržati kontrolu?”

Od sučelja za razgovor do operativne petlje

Chatbot uglavnom proizvodi tekst. Agent djeluje u petlji: prima cilj, prikuplja relevantno stanje, bira radnju, procjenjuje rezultat te nastavlja ili staje. Jezični model može pokretati zaključivanje, ali okolni sustav određuje je li rezultat pouzdan.

Razmotrite agenta za trijažu korisničke podrške. Slabija verzija čita tiket i sastavlja odgovor. Snažnija verzija može klasificirati problem, pretražiti bazu znanja, pregledati dopušteni kontekst korisničkog računa, predložiti sljedeći korak i usmjeriti slučaj kada je razina pouzdanosti niska. Potonja je vrijedna zato što je povezana s kontroliranim radnim tokom, a ne zato što može pisati tečniji prozni tekst.

Ta je razlika važna za softverske timove. Većina vrijednosti u produkciji dolazi iz integracijskog sloja: identiteta, dozvola, dohvaćanja podataka, ugovora alata, upravljanja stanjem, zapisa revizije i evaluacije. Model tretirajte kao jednu komponentu većeg sustava za donošenje odluka.

Počnite s ograničenim radom, a ne širokom autonomijom

Najuspješniji rani agenti obično preuzimaju uski, ponovljiv dio posla. Imaju jasan ulaz, ograničen skup alata i ishod koji se može provjeriti. Široki upiti poput „upravljaj našim inženjerskim zaostatkom” skrivaju previše procjena i previše načina za nanošenje štete.

Bolje početne točke uključuju:

• Pripremu sažetka zahtjeva za povlačenje iz definiranog skupa promjena u repozitoriju.
• Izdvajanje strukturiranih polja iz pristiglih dokumenata i označavanje nesigurnih vrijednosti.
• Istraživanje rutinskih upozorenja prikupljanjem zapisnika i povezivanjem relevantnog priručnika za postupanje.
• Izradu nacrta testnih slučajeva iz odobrene specifikacije za ljudsku provjeru.
• Usklađivanje zapisa među sustavima uz eskaliranje nepodudarnosti, umjesto automatskog mijenjanja podataka.

Ti zadaci dijele važno svojstvo: uspjeh se može promatrati. Agent je ili pronašao relevantni priručnik za postupanje, proizveo valjan strukturirani izlaz ili identificirao iznimku. To omogućuje iteraciju.

Dizajnirajte alate jednako pažljivo kao i upite

Alati agenta njegove su mogućnosti u stvarnom svijetu. Neodređeno sučelje alata potiče neodređeno ponašanje. Precizno sučelje smanjuje dvosmislenost, ograničava opseg štete i olakšava dijagnosticiranje kvarova.

Na primjer, interni alat za implementaciju ne bi trebao izlagati generičku radnju nazvanu deploy s neograničenim tekstualnim argumentom. Dajte prednost eksplicitnim operacijama kao što su create_deployment_preview, request_deployment_approval i deploy_approved_release. Svaka operacija trebala bi validirati ulaze, provoditi autorizaciju neovisno o modelu i vraćati strukturirane rezultate.

{
  "environment": "staging",
  "release_id": "release-2026-08-31-42",
  "change_ticket": "CHG-1042"
}

Model može odlučiti treba li zatražiti pregled, ali ne bi mu trebalo vjerovati da sam provodi produkcijsku politiku. Kritična pravila stavite u uobičajeni softver: autorizaciju na strani poslužitelja, validaciju sheme, ograničenja brzine, provjere odobrenja, ključeve idempotentnosti i granice transakcija.

Učinite radnje reverzibilnima gdje je moguće

Agenti će povremeno krenuti nekorisnim putem. Dizajnirajte za oporavak. Alat koji arhivira zapis često je sigurniji od onoga koji ga trajno briše. Alat koji priprema skup plaćanja sigurniji je od onoga koji ga šalje. Alat koji otvara nacrt zahtjeva za povlačenje sigurniji je od onoga koji spaja kod.

Reverzibilnost nije samo sigurnosna značajka; omogućuje brže učenje. Timovi mogu agentu ranije dodijeliti korisne odgovornosti kada su posljedice pogrešne radnje ograničene.

Agentu pružite pravi kontekst, a ne sav kontekst

Kontekst je često razlika između dojmljive demonstracije i pouzdanog sustava. Ipak, neselektivno slanje više podataka modelu stvara probleme s troškovima, privatnošću i točnošću. Cilj je relevantan, aktualan i autoriziran kontekst.

Za agenta za održavanje softvera to može značiti aktivni problem, datoteku vlasništva pogođene usluge, nedavne tragove pogrešaka, relevantni API ugovor i priručnik za postupanje za upozorenje. Ne znači kopirati svaki dokument u tvrtki u upit.

Dohvaćanje podataka trebalo bi tretirati kao inženjerski problem. Definirajte koji su izvori mjerodavni, sačuvajte informacije o verziji dokumenta, priložite citate ili poveznice u izlaz agenta i učinite nedostajuće informacije vidljivima. Kada dokazi nisu dovoljni, ispravno je ponašanje često postaviti usmjereno pitanje ili eskalirati.

Agent bi trebao biti siguran u svoj proces, a ne siguran izvan onoga što dokazi potvrđuju.

Planirajte neuspjeh kao uobičajeno stanje

Vanjski sustavi prekidaju vezu zbog isteka vremena. Dozvole se mijenjaju. Rezultati pretraživanja nisu potpuni. Model može pogrešno razumjeti odgovor alata ili odabrati neučinkovit slijed radnji. Robusni agenti trebaju eksplicitne uvjete zaustavljanja i putanje neuspjeha.

Praktična petlja uključuje ograničenja broja poziva alata, proteklog vremena i pokušaja ponavljanja. Ponavljanja bi trebala biti selektivna: ponavljanje prolaznog mrežnog kvara može imati smisla, dok ponavljanje pogreške validacije bez promjene ulaza nema. Svako pokretanje trebalo bi zabilježiti cilj, dohvaćeni kontekst, pozvane alate, ishode i konačni status.

Predaja čovjeku trebala bi biti ishod prve klase, a ne neugoda. Korisna eskalacija sadrži prikupljene dokaze, pokušanu radnju, razlog zašto je napredak stao i preciznu odluku potrebnu od osobe koja preuzima slučaj.

Procijenite ponašanje prije proširenja pristupa

Tradicionalno testiranje softvera pita vraća li kod očekivani rezultat za poznate ulaze. Evaluacija agenta mora ispitati i prosudbu u različitim okolnostima: nepotpunom kontekstu, sukobljenim uputama, pogreškama alata, dvosmislenim zahtjevima i pokušajima poticanja nesigurnih radnji.

Izradite mali evaluacijski skup iz realističnih, sanitiziranih scenarija. Definirajte kako izgleda dobar rezultat, uključujući kada bi agent trebao odbiti, zatražiti pojašnjenje ili predati slučaj. Pregledavajte ne samo konačne odgovore već i korištenje alata. Odgovor koji zvuči točno, ali je do njega došao putem neautoriziranih podataka ili nepotrebne destruktivne radnje, nije uspješno pokretanje.

Praćenje produkcije zatim zatvara petlju. Pratite dovršenost zadataka, stopu eskalacije, stopu ispravaka, latenciju, kvarove alata i kršenja pravila. Metrike su korisne samo kada su povezane s uzorkovanim pregledima; rastuća stopa dovršenosti mogla bi odražavati stvarno poboljšanje ili agenta koji postaje previše sklon proglašavanju uspjeha.

Redefinirajte ulogu developera

Agenti ne uklanjaju potrebu za inženjerskom disciplinom. Čine je vidljivijom. Developeri sve više dizajniraju granice oko sustava za zaključivanje: pouzdane API-je, vjerodostojan pristup podacima, radne tokove koje je moguće pratiti, iskustva odobravanja i evaluacije koje odražavaju stvarni rad.

Najbolje implementacije manje djeluju kao zamjena ljudi, a više kao uklanjanje trenja oko njihove stručnosti. Inženjer u dežurstvu prima sažet opis incidenta umjesto da ručno prikuplja tragove. Financijski stručnjak pregledava iznimke umjesto da ponovno upisuje rutinska polja. Voditelj proizvoda počinje s dobro strukturiranim nacrtom, zadržavajući konačnu odluku.

To je trajno obećanje agenata umjetne inteligencije: softver koji predviđa sljedeći koristan potez, a pritom ostaje odgovoran za svaki potez s posljedicama. Izgradite ih s uskim ovlastima, snažnim dokazima, reverzibilnim radnjama i jasnim ljudskim vlasništvom pa automatizaciju mogu pretvoriti iz skupa prečaca u pouzdan dio načina na koji se posao obavlja.