Većina softvera čeka da mu se kaže što treba učiniti. AI agent mijenja taj odnos: može protumačiti cilj, pregledati relevantan kontekst, odabrati sljedeći korak, upotrijebiti odobrene alate i izvijestiti o tome što se dogodilo. To zvuči kao „softver koji razmišlja”, ali korisna verzija manje je mistična. To je pažljivo dizajniran sustav koji sposobnosti jezičnog modela pretvara u ograničen i vidljiv rad.

Razlika je važna. Sučelje za razgovor može objasniti kako istražiti neuspjelu implementaciju. Agent može prikupiti zapisnike, usporediti neuspjeh s operativnim priručnikom, otvoriti nacrt sažetka incidenta i zatražiti odobrenje prije nego što unese promjenu. Vrijednost nije u modelu koji djeluje samostalno. Ona je u kombinaciji zaključivanja, konteksta, alata, ograničenja i ljudske prosudbe.

Što AI sustav čini agentom?

Agent se obično gradi oko petlje: primi cilj, razumije trenutačno stanje, odluči o radnji, izvrši je pomoću alata, pregleda rezultat te nastavi ili stane. Jezični model može usmjeravati odluke, ali ne bi trebao biti cijeli sustav.

U praktičnom smislu, agentu je potrebno nekoliko komponenti:

• Jasan cilj: ograničen ishod kao što je „razvrstaj ovaj zahtjev za podršku” ili „pripremi sažetak zahtjeva za povlačenje.”
• Pouzdan kontekst: relevantna prijava, metapodaci repozitorija, pravilo, zapis o korisniku ili operativno stanje.
• Pristup alatima: definirane operacije za pretraživanje, čitanje, izradu nacrta ili pokretanje kontroliranih radnih tijekova.
• Zaštitne ograde: granice dozvola, pravila provjere, ograničenja brzine i putevi eskalacije.
• Vidljivost: zapis ulaza, radnji, rezultata, neuspjeha i ljudskih nadjačavanja.

Bez tih dijelova, „agent” je često samo prompt s optimističnim brendiranjem. Model i dalje može biti koristan, ali ne može sigurno preuzeti značajnu odgovornost.

Počnite s radnim tijekom, a ne s osobnošću

Najbolje prilike za agente obično su ponavljajući radni tijekovi s neurednim ulazima i smislenom točkom ljudske provjere. To nisu nužno zadaci koji u demonstraciji izgledaju najimpresivnije.

Razmotrite dolazne sigurnosne upitnike. Koristan agent mogao bi izdvojiti tražene kontrole, pronaći odobrene dokaze u bazi znanja, utvrditi stavke bez odgovora i sastaviti nacrt odgovora. Ne bi trebao potajno obećavati ugovorne obveze ni izmišljati tvrdnje o usklađenosti. Radni tijek ima prirodnu granicu: pripremiti posao, a zatim ga usmjeriti odgovornom recenzentu.

Isti obrazac primjenjuje se u isporuci softvera. Inženjerski agent može klasificirati problem, pronaći vjerojatne vlasnike iz povijesti koda, sažeti nedavne povezane promjene i predložiti korake za reprodukciju. Može čak izraditi nacrt zahtjeva za povlačenje za uski, dobro testirani popravak. No implementacija u produkciju, promjena pristupa ili migracija baze podataka zaslužuju strože kontrole od nacrta dokumenta.

Odaberite rad s vidljivom definicijom dovršenosti

Dobar prvi slučaj upotrebe ima ulaze koje možete prepoznati, ishode koje možete procijeniti i zamjensko rješenje kada sustav nije siguran. „Poboljšaj produktivnost programera” cilj je; „pretvori provjereni problem u strukturirano izvješće o trijaži” radni je tijek.

Prije izgradnje zapišite kako izgleda uspjeh. Na primjer:

• Koje izvorne sustave agent smije čitati?
• Koje radnje smije automatski poduzeti, ako ih uopće ima?
• Koji dokazi moraju pratiti svaku preporuku?
• Kada mora zatražiti od osobe da odluči?
• Kako će tim otkriti loš ili nepotpun rezultat?

Ta pitanja nameću odluke o dizajnu na koje uglađeni prompt ne može odgovoriti.

Dajte agentima alate s uskim ugovorima

Agent bi trebao komunicirati sa svijetom putem namjernih sučelja, a ne širokih vjerodajnica i nejasnih uputa. Alat nazvan get_open_incidents(service) lakše je zaštititi, testirati i revidirati od neograničenog pristupa operativnoj platformi. Alat koji stvara nacrt sigurniji je od onoga koji odmah šalje poruku.

Odgovori alata trebali bi, gdje je moguće, biti strukturirani. Umjesto vraćanja dugačkog, dvosmislenog bloka teksta, vratite polja koja sustav može provjeriti: identifikatore, vrijednosti statusa, vremenske oznake, dopuštene sljedeće radnje i kodove pogrešaka. To smanjuje mogućnost da model pogrešno pročita rezultat i donese samouvjerenu, ali netočnu naknadnu odluku.

Također dizajnirajte za neuspjeh. API-ji premašuju vremensko ograničenje, dozvole se mijenjaju, zapisi su nepotpuni, a izlazi modela mogu biti neispravno oblikovani. Agent bi trebao razlikovati „ne postoji odgovarajući zapis” od „pretraživanje nije uspjelo”, ponoviti pokušaj samo kada je to primjereno i stati kada siguran zaključak nije dostupan.

result = search_customer_account(account_id)

if result.status == "not_found":
    return request_more_information(account_id)

if result.status != "ok":
    return escalate("Account lookup could not be completed")

return create_response_draft(result.account)

Važna ideja nije jezik. To je izričito rukovanje stanjima. Model može pomoći pri odabiru formulacije ili klasifikaciji dvosmislenosti, dok konvencionalni kod provodi ključna pravila radnog tijeka.

Zadržite ljude ondje gdje prosudba ima posljedice

Ljudska provjera nije znak da agent nije uspio. Često je upravo značajka koja omogućuje usvajanje. Odgovarajuća razina provjere ovisi o cijeni pogreške.

Za rad niskog rizika agent može djelovati automatski i ostaviti revizijski trag: oblikovati bilješku sa sastanka, označiti duplicirani zahtjev ili prikupiti reference za dokument. Za rad srednjeg rizika može pripremiti preporuku i zahtijevati odobrenje: dodijeliti prioritet podrške, ažurirati nacrt baze znanja ili predložiti promjenu koda. Za rad visokog rizika trebao bi pomoći u istrazi i predstaviti mogućnosti, dok kvalificirana osoba odobrava odluku.

Ta se granica treba temeljiti na utjecaju, reverzibilnosti i pouzdanosti — a ne na tome zvuči li rezultat uvjerljivo. Jezični modeli posebno su dobri u stvaranju tečnih objašnjenja. Tečnost nije dokaz.

Procijenite sustav, a ne samo model

Sposoban model i dalje može proizvesti slabog agenta ako prima zastarjeli kontekst, koristi nepouzdane alate ili ima nejasne upute. Procjena mora obuhvatiti cijeli put od zahtjeva do ishoda.

Prije uvođenja izradite mali skup reprezentativnih slučajeva, uključujući uobičajene zahtjeve, nepotpune podatke, sukobljene upute, neuspjehe dozvola i pokušaje da se agent pogura izvan njegova opsega. Ne provjeravajte samo je li konačan odgovor prihvatljiv, nego i je li agent upotrijebio prave izvore, odabrao odgovarajuće alate i eskalirao u pravo vrijeme.

Povratne informacije iz produkcije trebale bi biti jednako konkretne. Pratite stope ispravaka, ishode odobravanja, neuspjehe alata, učestalost predaje i vrste posla koje sustav opetovano zbunjuju. Ti signali otkrivaju treba li poboljšati kontekst, redizajnirati alat, suziti radni tijek ili promijeniti prompt modela.

Gradite povjerenje jasnoćom

Ljudima ne treba agent koji oponaša kolegu. Treba im da bude pouzdan, iskren u vezi s nesigurnošću i jednostavan za ispravljanje. Koristan agent govori što je upotrijebio, što je promijenio i čemu još treba posvetiti pozornost. Ne skriva informacije koje nedostaju iza uglađenog odgovora.

Promjena koju vrijedi zapamtiti jest ova: AI agenti nisu zamjena za disciplinu softverskog inženjerstva. Oni su novi razlog da je primijenite. Timovi koji definiraju granice, dizajniraju humane petlje provjere i ponašanje modela tretiraju kao jednu komponentu većeg sustava dobit će više od pametnog asistenta. Izgradit će softver koji ljudima pomaže da s manje trenja i više sigurnosti prijeđu od namjere do djelovanja.