Najveća promjena u radu na softveru uz pomoć umjetne inteligencije nije to što modeli mogu pisati kod. Već to što sada mogu sudjelovati u tijeku rada: čitati kontekst, predlagati plan, pozivati alate, provjeravati rezultate i predavati posao natrag kada je potrebna prosudba.

Ta nas promjena pomiče dalje od promptanja. Prompt je zahtjev. Agent je softverska komponenta koja djeluje unutar dizajniranog sustava. Ta je razlika važna jer korisni poslovni ishodi rijetko proizlaze iz jednog dobrog odgovora u prozoru za razgovor. Oni proizlaze iz pouzdanih slijedova odluka, radnji, provjere i odgovornosti.

Za programere i tehnološke čelnike pitanje više nije „Koji prompt daje najbolji rezultat?” Nego: „Gdje agent može sigurno stvoriti vrijednost i kako ga orkestrirati s ljudima, podacima i postojećim softverom?”

Promptovi stvaraju tekst; sustavi stvaraju ishode

Jezični model može sažeti izvješće o incidentu, sastaviti opis zahtjeva za povlačenje ili predložiti upit baze podataka. To su vrijedne mogućnosti, ali izolirani trenuci. Integrirani agent može preuzeti ograničen cilj, prikupiti dopušteni kontekst, upotrijebiti odobrene alate i usput zabilježiti što se dogodilo.

Razmotrite tijek rada za trijažu korisničke podrške. Osnovni prompt može klasificirati zalijepljenu poruku korisnika. Orkestrirani sustav može primiti zahtjev, dohvatiti relevantnu dokumentaciju proizvoda, utvrditi razinu računa iz CRM-a, sastaviti odgovor, otvoriti inženjerski zadatak kada dokazi upućuju na nedostatak i usmjeriti osjetljive slučajeve čovjeku. Model je samo jedan dio tog tijeka.

Orkestracijski sloj određuje stvarnu kvalitetu sustava. Definira koje su informacije dostupne, koje su radnje dopuštene, što zahtijeva odobrenje, kako se rješavaju neuspjesi i kako se procjenjuju rezultati. Bez tog sloja agent je često samo sposobno, ali nepredvidljivo sučelje.

Počnite s tijekom rada, a ne s modelom

Najuspješniji projekti s agentima započinju bolnim, ponavljajućim tijekom rada koji već ima jasnog vlasnika. Izbjegavajte početak s nejasnom ambicijom poput „dodati umjetnu inteligenciju u operacije”. Umjesto toga, mapirajte postojeći proces od pokretača do završetka.

Za svaki korak postavite četiri praktična pitanja: Koji su ulazi potrebni? Koja se odluka donosi? Koji alat izvršava radnju? Kako ćemo znati da je radnja bila ispravna?

• Ulazi: zahtjevi, promjene u repozitoriju, dokumenti, telemetrija, obrasci ili strukturirani zapisi.
• Odluke: klasificirati, odrediti prioritet, izdvojiti, usporediti, preporučiti ili eskalirati.
• Radnje: izraditi nacrt, ažurirati zapis, pokrenuti izvješće, otvoriti zadatak ili obavijestiti vlasnika.
• Provjera: provjere sheme, poslovna pravila, testovi, ljudski pregled ili naknadna potvrda.

Takva raščlamba sprječava čest način neuspjeha: traženje od modela da „obradi” proces čija pravila i rubne slučajeve nitko nije jasno iznio. Agenti ne uklanjaju potrebu za razumijevanjem rada. Oni to razumijevanje čine važnijim, jer skrivene pretpostavke postaju automatizirano ponašanje.

Dizajnirajte agente kao ograničene suradnike

Korisni agenti trebali bi imati usku ulogu, eksplicitne alate i razumljivu točku zaustavljanja. „Riješi probleme korisnika” nije prikladna uputa. „Sastavi odgovor na pitanja o naplati koristeći zapis računa i objavljenu politiku; eskaliraj sve što uključuje povrate novca ili pristup računu” mnogo je bliže provedivoj ulozi.

Pristup alatima zaslužuje jednaku pažnju kao dozvole aplikacije. Agent koji može čitati bazu znanja i izraditi nacrt ima vrlo drukčiji profil rizika od onoga koji može izdavati povrate novca, implementirati kod ili mijenjati produkcijske podatke. Dajte mu najmanji skup mogućnosti kojima može izvršiti dodijeljeni zadatak.

Strukturirani izlazi još su jedna ključna granica. Ako naknadnoj usluzi trebaju prioritet, kategorija, objašnjenje i pokazatelj pouzdanosti, zatražite definiranu strukturu i provjerite je prije poduzimanja radnje. Ne dopustite da slobodno oblikovani tekst postane slučajni API ugovor.

{
  "category": "billing",
  "priority": "normal",
  "recommended_action": "draft_reply",
  "needs_human_review": false,
  "reason": "Question matches published invoice guidance."
}

Provjera i dalje treba pretpostaviti da model može biti u krivu. Provjerite obavezna polja, prihvaćene vrijednosti, pravila ovlaštenja i trenutačno stanje ciljnog sustava. Valjan JSON objekt nije dokaz da je njegov zaključak ispravan.

Gradite za ponovne pokušaje, nejasnoće i siguran neuspjeh

Produkcijski tijekovi rada susreću nedostupne usluge, nepotpune zapise, duplicirane događaje, sukobljene upute i zahtjeve koji se ne uklapaju u poznate kategorije. To nisu rijetke iznimke; to je uobičajeno okruženje automatizacije.

Odvojite zaključivanje agenta od nuspojava kad god je moguće. Neka najprije pripremi plan ili nacrt. Zatim neka uobičajena aplikacijska logika provjeri uvjete i izvrši promjenu. Za radnje s posljedicama dodajte korak odobravanja koji odgovornoj osobi prikazuje kontekst, preporuku i namjeravanu radnju.

Ponovni pokušaji zahtijevaju posebnu disciplinu. Zahtjev za stvaranje zahtjeva ili slanje poruke može uspjeti čak i ako usluga koja poziva istekne prije primanja potvrde. Upotrijebite stabilne identifikatore i idempotentne operacije tamo gdje ih ciljni sustav podržava. Zabilježite stanje tijeka rada kako bi se ponovni pokušaj mogao inteligentno nastaviti umjesto ponavljanja svake radnje.

Kada je pouzdanost niska, nejasnoća velika ili se dosegne granica politike, ispravno je ponašanje često stati. Dobro osmišljena eskalacija uspješan je ishod. Štiti korisnike i istodobno stvara povratne informacije koje mogu poboljšati upute, dohvaćanje, pravila i sučelja.

Mjerite tijek rada, a ne demonstraciju

Demonstracije agenata obično naglašavaju dojmljive pojedinačne odgovore. Operativna se vrijednost bolje mjeri kroz cijeli tijek rada. Pratite koliko često rad stiže na ispravno odredište, koliko se ljudskog truda štedi, koliko često pregledavatelj mijenja preporuku i gdje se neuspjesi grupiraju.

Redovito pregledavajte uzorke, uključujući slučajeve koji izgledaju uspješno. Sustav može djelovati produktivno dok potajno primjenjuje pogrešnu politiku ili stvara posao drugom timu. Procjena treba uključivati uobičajene slučajeve, podatke koji nedostaju, neprijateljske ulaze, zastarjelu dokumentaciju i iznimke s velikim utjecajem.

Jednako je važna i opažljivost. Bilježite verziju tijeka rada, dostupne alate, ulaze dopuštene pravilima, pozive alata, rezultate provjere i konačnu odluku. Zapisnici bi trebali podržavati otklanjanje poteškoća bez nepotrebnog zadržavanja osjetljivog sadržaja. Cilj je sljedivost: netko bi trebao moći razumjeti zašto je sustav djelovao ili odbio djelovati.

Ljudska uloga postaje vrijednija, a ne manje vrijedna

Orkestracija mijenja prirodu stručnosti. Ljudi troše manje vremena na premještanje informacija između sustava, a više na definiranje politika, pregled iznimki, poboljšavanje tijekova rada i donošenje odluka u kojima su važne vrijednosti ili kompromisi. To nije sporedan detalj implementacije. To je stvarni organizacijski redizajn koji stoji iza usvajanja agenata.

Najbolji prvi agent obično nije autonomna zamjena za cijeli posao. On je pouzdan suradnik u uskom, vidljivom procesu. Dajte mu jasan cilj, ograničene ovlasti, snažne provjere i jednostavan put za vraćanje posla.

Promptanje nas uči kako komunicirati s modelom. Orkestriranje nas uči kako oko njega izgraditi pouzdan softver. Organizacije koje će ostvariti trajnu vrijednost od umjetne inteligencije neće biti one s najdomišljatijim promptovima. Bit će to one koje korisne mogućnosti modela pretvore u sustave kojima ljudi mogu vjerovati.