AI agent nije chatbot s popisom zadataka. To je sustav koji promatra situaciju, odabire radnju, koristi alate, provjerava što se dogodilo i odlučuje što učiniti sljedeće. Ta petlja zvuči jednostavno, ali većina neuspjeha agenata proizlazi iz tretiranja nje kao implementacijskog detalja, a ne kao ključnog dizajna proizvoda.

Ako izrađujete, kupujete ili radite uz AI agente, najkorisniji mentalni model je ovaj: agent je tijek rada za donošenje odluka koji djeluje u uvjetima nesigurnosti. Model doprinosi razumijevanjem jezika i rezoniranjem. Okolni sustav pruža stanje, ovlasti, alate, ograničenja i provjeru.

Ako te dijelove postavite ispravno, agent može ukloniti značajan operativni posao. Ako ih postavite pogrešno, može s pouzdanjem automatizirati zbrku.

Petlja agenta pravi je proizvod

Većina praktičnih agenata slijedi ciklus: primi cilj, pregleda relevantan kontekst, odabere radnju, izvrši je, procijeni rezultat te nastavi ili stane. Jezični model može sudjelovati u nekoliko faza, ali aplikacija upravlja petljom.

while not task.is_complete():
    context = collect_relevant_context(task)
    action = model.choose_action(task, context, tools)

    result = execute(action)
    record(task, action, result)

    if result.failed:
        task = handle_failure(task, result)
    else:
        task = update_state(task, result)

Ovo je namjerno važnije nego što se čini. Ne treba pretpostaviti da model zna je li radnja uspjela. Potrebni su mu strukturirani rezultati sustava s kojima komunicira. Isto tako, aplikacija ne bi trebala pretpostaviti da je uvjerljiv odgovor modela valjan plan.

Korisna arhitektura agenta svaku fazu čini eksplicitnom: koji je cilj, koje su informacije bile dostupne, koja je radnja predložena, što je stvarno izvršeno i zašto je proces završio.

Odvojite rezoniranje od ovlasti

Jezični modeli dobri su u tumačenju dvosmislenih zahtjeva, izvlačenju namjere iz neurednog teksta i predlaganju sljedećih koraka. Oni nisu sustav ovlasti. Agent bi trebao moći široko rezonirati, a djelovati ograničeno.

Na primjer, internom agentu za podršku može biti dopušteno pretraživati dokumentaciju, sažimati povijest korisničkog slučaja i sastavljati odgovor. Ne bi mu trebalo automatski biti dopušteno izdavati povrate novca, mijenjati vlasništvo računa ili izvoziti osjetljive zapise samo zato što može te radnje tečno opisati.

Dizajn alata mjesto je gdje ta razlika postaje konkretna. Umjesto izlaganja nejasne funkcije kao što je manage_customer_account, izložite male radnje s ograničenim ulazima:

• get_account_status(account_id)
• list_recent_invoices(account_id)
• draft_refund_request(invoice_id, reason)
• submit_refund_request(request_id)

Razdvajanje stvara točke za provjeru i jasnije revizijske tragove. Također smanjuje vjerojatnost da loše formuliran upit postane previše moćna uputa.

Dajte agentima stanje, a ne samo povijest razgovora

Povijest razgovora korisna je, ali je slaba zamjena za stanje aplikacije. Dugi prijepisi postaju skupi, ometajući i teško ih je provjeriti. Također mogu zadržati zastarjele pretpostavke dugo nakon što je sustav naučio nešto novo.

Pohranite činjenice koje agent treba u strukturiranom obliku: status zadatka, dodijeljeni vlasnik, dovršeni koraci, odobrena ograničenja, izlazi alata, broj ponovnih pokušaja i reference na relevantne dokumente. Zatim dohvatite samo kontekst potreban za sljedeću odluku.

Razmotrite agenta koji priprema promjenu u implementaciji. Njegovo radno stanje moglo bi uključivati ciljno okruženje, odobreni vremenski prozor za promjenu, trenutačnu verziju, rezultat provjere stanja, mogućnost vraćanja na prethodno stanje i podatak o tome je li zabilježeno ljudsko odobrenje. To je mnogo sigurnije nego tražiti od modela da zaključi cijelu situaciju iz niza poruka.

Kontekst bi trebao odgovoriti na određeno pitanje

Svaki dio konteksta trebao bi opravdati svoje mjesto. Prije dodavanja dokumenta, rezultata baze podataka ili prošlog razgovora u upit agentu, zapitajte se: koju će odluku ova informacija poboljšati? Ako odgovor nije jasan, vjerojatno je riječ o šumu.

Relevantan kontekst poboljšava odluke. Previše konteksta može agenta učiniti sporijim, manje predvidljivim i sklonijim slijeđenju nevažne upute ugrađene u nepouzdan sadržaj.

Dizajnirajte alate za neuspjeh, a ne samo za uspjeh

Stvarni sustavi prekoračuju vremenska ograničenja, vraćaju djelomične rezultate, odbijaju zahtjeve i mijenjaju se dok ih koristite. Agent koji vidi samo „uspjeh” ili „pogrešku” ne može inteligentno reagirati. Alati bi trebali vraćati strukturirane, djelotvorne ishode.

{
  "status": "retryable_error",
  "message": "The inventory service did not respond before the timeout.",
  "retry_after_seconds": 30,
  "safe_to_retry": true
}

Takav odgovor agentu govori što se dogodilo i što smije sigurno učiniti sljedeće. Nasuprot tomu, općenita poruka o pogrešci potiče nagađanje.

Također je važno razlikovati neuspjehe koje treba ponoviti od neuspjeha koji zahtijevaju eskalaciju. Privremeni mrežni prekid zbog vremenskog ograničenja može opravdati jedan ograničeni ponovni pokušaj. Odbijeno plaćanje, nedostajuće odobrenje ili konfliktan zapis obično bi trebali zaustaviti tijek rada i zatražiti ljudski unos.

• Postavite maksimalan broj poziva alata i ponovnih pokušaja.
• Operacije pisanja učinite idempotentnima kad je moguće, kako ponovni pokušaj ne bi duplicirao radnju.
• Zahtijevajte potvrdu prije nepovratnih radnji ili radnji s velikim utjecajem.
• Vratite strojno čitljive kategorije pogrešaka uz objašnjenja čitljiva ljudima.
• Zapisujte ulaze, izlaze, pozive alata i konačne odluke uz odgovarajuće kontrole privatnosti.

Provjera je mjesto gdje se stječe povjerenje

Agent ne bi trebao prijaviti dovršenost zato što je sastavio uvjerljivu rečenicu. Trebao bi prijaviti dovršenost zato što može ukazati na dokaz iz sustava evidencije.

Uzmimo agenta za programiranje kojem je zadano da ispravi pogrešku. Vjerodostojan tijek rada nije „uredi datoteke, zatim reci da je pogreška ispravljena”. On je „utvrdi neuspješno ponašanje, napravi ograničenu izmjenu, pokreni relevantne provjere, pregledaj rezultate i jasno prijavi svaku preostalu nesigurnost”. Ako se testovi ne mogu pokrenuti, to ograničenje pripada rezultatu umjesto da se potajno zamijeni sigurnošću.

Isto načelo vrijedi izvan softvera. Agent za raspoređivanje trebao bi provjeriti je li sastanak stvoren. Istraživački agent trebao bi razlikovati dohvaćeni materijal od vlastite sinteze. Financijski agent trebao bi provjeriti stanje transakcije prije nego što ikoga obavijesti.

Koristite ljude za prosudbu, a ne za rutinski posao

Ljudska je provjera najučinkovitija kada se pojavljuje na smislenim granicama. Traženje odobrenja nakon svakog pretraživanja niskog rizika čini agenta nezgrapnim. Dopustiti mu da bez provjere dovrši skupu vanjsku obvezu čini ga nepromišljenim.

Razuman obrazac jest automatizirati reverzibilan, dobro definiran posao i eskalirati odluke koje uključuju novac, pravnu izloženost, sigurnost, reputacijski rizik ili suprotstavljene poslovne prioritete. Agent može prikupiti kontekst, utvrditi mogućnosti i pripremiti preporuku. Osoba ostaje odgovorna za odluku koja zahtijeva prosudbu.

Cilj nije ukloniti ljude iz petlje. Cilj je ukloniti izbježno trenje iz petlje.

Počnite s uskim tijekom rada

Najjači prvi agent rijetko je digitalni zaposlenik opće namjene. Obično je to usmjeren tijek rada s jasnim okidačem, ograničenim alatima, mjerljivim rezultatom i očitim vlasnikom kada stvari pođu po zlu.

Odaberite posao koji je dovoljno čest da bude važan, dovoljno strukturiran da se može procijeniti i dovoljno niskog rizika da se postupno poboljšava. Zatim promatrajte stvarna izvršavanja. Gdje je agentu nedostajao kontekst? Koji je rezultat alata bio dvosmislen? Koja je iznimka zahtijevala osobu? Ti odgovori predstavljaju plan za povećanje sposobnosti sustava.

AI agenti postaju pouzdani ne samo većim upitom, nego discipliniranim dizajnom sustava: ograničenim ovlastima, korisnim stanjem, eksplicitnim rukovanjem neuspjesima i dovršenošću utemeljenom na dokazima. Gradite oko te temeljne logike i agenti mogu postati pouzdani suradnici, a ne impresivne demonstracije koje se slome na prvom neurednom rubnom slučaju.