AI agenti pomiču softverski rad izvan poznatog obrasca „postavi pitanje, primi odgovor”. Sve je korisniji obrazac: definiraj ishod, pruži ograničenja i pristup, a zatim prepusti sustavu da planira, djeluje, provjerava i izvještava.

To agente ne čini čarobnim autonomnim inženjerima. Ipak ih čini važnim novim slojem u načinu na koji timovi dizajniraju, upravljaju i unapređuju softver. Kada se temelje na jasnim radnim tijekovima i pouzdanim alatima, agenti mogu preuzeti povezujući rad između sustava: istraživanje incidenata, pripremu promjena, provjeru podataka, koordinaciju rutinskih operacija i usklađivanje dokumentacije sa stvarnim stanjem.

Od korisnog sučelja do aktivnog sudionika sustava

Asistent je prvenstveno razgovorni alat. Sažima dokument, objašnjava stog poziva ili izrađuje nacrt funkcije kada ga se zatraži. Agent dodaje petlju oko te inteligencije. Može promatrati stanje, odabrati sljedeću radnju, upotrijebiti alat, pregledati rezultat i nastaviti dok ne dosegne definiranu točku zaustavljanja.

Ta je petlja ključna razlika. Koristan agent nije samo model s dopuštenjem za pozivanje API-ja. To je softverska komponenta s ciljem, ograničenim mogućnostima, trajnim kontekstom, izričitim zaštitnim mjerama i načinom utvrđivanja je li njegov rad uspio.

Razmotrite radni tijek trijaže podrške. Uobičajeni asistent može pomoći čovjeku protumačiti zahtjev. Agent može klasificirati zahtjev, potražiti relevantni račun i status usluge, pretražiti poznate probleme, prikupiti dijagnostički kontekst, predložiti odgovor i usmjeriti slučaj odgovarajućem vlasniku. Čovjek i dalje može odobriti konačnu poruku za korisnika, ali velik dio ponavljajuće koordinacije nestaje.

Arhitektura je važnija od upita

Najjači sustavi agenata obično nemaju glamurozne temelje. Ovise o dobrim inženjerskim praksama: strogo tipiziranim sučeljima, uskim ovlastima, strukturiranim podacima, idempotentnim operacijama, zapisnicima, testovima i jasnom vlasništvu. Sofisticirani model ne može nadoknaditi nepouzdan API za implementaciju ili poslovni proces koji nitko zapravo nije definirao.

Za razvojne inženjere to mijenja pitanje pri dizajnu. Umjesto da pitate samo: „Što model može generirati?”, pitajte: „Koje odluke ovaj sustav može sigurno donositi i koji su mu dokazi potrebni?”

Agentima dajte ograničene alate

Alati bi trebali izražavati korisne poslovne radnje, a ne izlagati cijelo infrastrukturno okruženje. Agentu koji treba istražiti upozorenje možda je potreban pristup za čitanje praćenja, zapisnika, nedavnih implementacija i vlasništva nad uslugama. Rijetko mu je potreban neograničen pristup ljusci ili mogućnost izravne promjene produkcijske konfiguracije.

Dobar ugovor za alat čini sigurnu radnju jednostavnom, a nesigurnu radnju teškom. Dajte prednost operacijama kao što su get_deployment_status, search_incidents ili create_change_request pred generičkim alatom koji može izvršavati proizvoljne naredbe. Strukturirani ulaz i izlaz također olakšavaju testiranje ponašanja i reviziju odluka.

Odvojite planiranje od nepovratnih radnji

Mnogi su zadaci agenata sigurniji kada se podijele u faze: prikupljanje dokaza, izrada plana, predstavljanje plana, a zatim izvršavanje odobrenih koraka. To je osobito vrijedno za produkcijske promjene, financijske operacije, radne tijekove osjetljive na sigurnost i vanjsku komunikaciju.

Primjerice, agent može prepoznati zastarjele resurse u oblaku i pripremiti plan brisanja. Može navesti obuhvaćene resurse, procijeniti ovisnosti i otvoriti zahtjev za promjenu koji se može pregledati. Osoba ili mehanizam pravila tada mogu odobriti brisanje. Agent ostaje koristan, a ne postaje nekontrolirani operater.

Gradite za ponovne pokušaje i djelomične neuspjehe

Stvarni sustavi zakazuju na uobičajene načine: ovisnost prekorači vremensko ograničenje, vjerodajnica istekne, zapis je već ažuriran ili vanjska usluga vrati nepotpune podatke. Radni tijekovi agenata trebaju istu otpornost kao i svaki distribuirani sustav.

Svaka radnja treba imati jasan uvjet uspjeha, vremensko ograničenje, pravilo ponovnog pokušaja gdje je to prikladno i smislen put u slučaju neuspjeha. Za operacije pisanja, ključevi idempotentnosti ili ekvivalentne zaštite sprječavaju agenta da pri ponovnom pokušaju duplicira zahtjev, povrat novca, obavijest ili implementaciju.

{
  "action": "create_change_request",
  "idempotency_key": "cleanup-2026-08-11-service-a",
  "dry_run": true,
  "requires_approval": true
}

Model može odlučiti koji će odobreni alat sljedeći pozvati, ali temeljna platforma trebala bi provoditi što taj poziv može učiniti. Pouzdanost je svojstvo sustava, a ne crta osobnosti modela.

Gdje agenti stvaraju praktičnu vrijednost

Agenti su najprivlačniji ondje gdje je posao repetitivan, zahtijeva mnogo konteksta i raspoređen je kroz više sustava. Manje su privlačni kada je zadatak dvosmislen, rijedak, visokorizičan ili ga je teško provjeriti.

• Inženjerske operacije: povezuju upozorenja s implementacijama, prikupljaju dijagnostičke dokaze, predlažu korake iz operativnih priručnika i otvaraju pravilno oblikovane zapise o incidentima.
• Isporuka softvera: sažimaju kontekst zahtjeva za povlačenje, prepoznaju testove koji nedostaju, ažuriraju bilješke o izdanju i provjeravaju ispunjava li promjena dogovoreni kontrolni popis.
• Održavanje znanja: otkrivaju dokumentaciju koja je u sukobu s trenutačnom konfiguracijom ili ponašanjem proizvoda, a zatim pripremaju ciljane izmjene za pregled.
• Poslovni radni tijekovi: usklađuju zapise u različitim sustavima, prepoznaju iznimke, traže informacije koje nedostaju i usmjeravaju slučajeve prema izričitim pravilima.

Uočite zajedničku nit: to nisu samo zadaci generiranja teksta. Zahtijevaju dohvaćanje aktualnih činjenica, primjenu pravila, poduzimanje ograničenih radnji i ostavljanje revizijskog traga. Zato je dizajn integracije toliko važan.

Ljudski nadzor treba osmisliti, a ne pretpostaviti

„Čovjek u petlji” može postati prazna fraza ako čovjek primi dugo objašnjenje i jedan gumb za odobravanje. Učinkovit nadzor daje recenzentima prave informacije u pravoj točki odlučivanja: što je agent opazio, što predlaže, koja je pravila primijenio, što će se promijeniti i kako poništiti radnju.

Zahtjevi za odobrenje trebaju odražavati posljedice, a ne novost. Agent često može automatski djelovati na niskorizičnim, povratnim zadacima uz snažnu provjeru, poput označavanja dupliciranih zahtjeva ili osvježavanja izvješća. Trebao bi eskalirati kada je pouzdanost niska, podaci proturječni, radnja nepovratna ili učinak zahvaća korisnike, novac, sigurnost ili dostupnost produkcije.

Timovi također trebaju jasan odgovor na osnovno pitanje: tko je vlasnik ponašanja agenta nakon pokretanja? Vlasništvo uključuje pregled neuspjeha, održavanje ugovora za alate, mijenjanje pragova pravila, praćenje troškova i povlačenje radnih tijekova koji više ne odgovaraju poslovanju.

Mjerite ishode, a ne dojmljive demonstracije

Demonstracija agenta može izgledati izvanredno, a pritom donositi malu operativnu vrijednost. Procjenjujte sustave prema radnom tijeku koji trebaju unaprijediti. Korisne mjere mogu uključivati kvalitetu dovršetka, stopu eskalacije, stopu ispravaka, vrijeme do rješenja, stopu neuspjeha alata i količinu potrebnog ljudskog pregleda.

Započnite s uskim radnim tijekom i uspostavite polaznu vrijednost. Ako je moguće, najprije pokrenite agenta u načinu promatranja: neka izrađuje preporuke bez poduzimanja radnji, usporedite te preporuke s ljudskim odlukama i ispitajte gdje mu nedostaje kontekst ili pogrešno primjenjuje pravila. Tek tada proširite ovlasti i opseg.

Testiranje bi trebalo obuhvatiti i protivničke i svakodnevne slučajeve. Što se događa kada zahtjev korisnika sadrži obmanjujuće upute? Što se događa kada nedostaje ključno polje? Što se događa kada agent vidi proturječne zapise sustava ili kada njegov preferirani alat nije dostupan? Odgovori bi trebali biti ugrađeni u logiku radnog tijeka i pravila, a ne prepušteni optimizmu.

Nova je arhitektura suradnička

AI agenti neće ukloniti potrebu za softverskim arhitektima. Čine arhitekturu važnijom. Netko i dalje mora odlučiti što je sustavu dopušteno znati, koje radnje može poduzeti, gdje se nalazi ovlast, kako je stanje predstavljeno i kako se sustav oporavlja od pogrešaka.

Trajna prilika nije zamijeniti prosudbu agentom. Ona je pretvoriti dobro shvaćenu prosudbu u pouzdane radne tijekove, uz očuvanje ljudske pozornosti za iznimke, kompromise i nove probleme. Timovi koji će imati najviše koristi tretirat će agente kao softverske sustave s inteligencijom u sebi: korisne, odgovorne, vidljive i namjerno ograničene.

To je prijelaz za koji se vrijedi pripremiti. AI postaje dio arhitekture kroz koju se posao obavlja. Ključna vještina nije samo naučiti postavljati bolja pitanja. Ona je naučiti dizajnirati sustave koji mogu odgovorno djelovati na temelju odgovora.