De ce agenții au nevoie de limite înainte de autonomie
Agentul prea serviabil
Agentul nu s-a răzvrătit. Merită spus de la început, pentru că poveștile despre sisteme autonome sunt adesea spuse ca și cum software-ul ar fi citit literatură științifico-fantastică proastă după miezul nopții. Acest agent s-a comportat cu o ascultare impresionantă. A primit o instrucțiune amplă să rezolve problemele deschise cu furnizorii înainte de sfârșitul lunii. A citit căsuța poștală, a căutat în sistemul de tichete, a găsit cazuri de integrare vechi, a trimis memento-uri, a închis duplicatele, a actualizat foaia de calcul și a escaladat orice părea urgent. Până la 09:15 a doua zi dimineață, făcuse mai multă muncă administrativă decât reușea echipa de obicei înainte de a doua cafea.
De asemenea, redeschisese o dispută pe care departamentul juridic o blocase intenționat, trimisese un memento unui furnizor aflat în perioada de interdicție a negocierilor, închisese un duplicat care nu era duplicat pentru că firma avea două subsidiare cu nume aproape identice și actualizase o celulă de prognoză pe care finanțele o foloseau ca intrare pentru un pachet de raportare pentru consiliu. Agentul nu halucinase. Nu își ignorase instrucțiunea. Urmase forma sarcinii așa cum fusese dată. Problema era că sarcina nu avea limite.
Echipa ceruse autonomie înainte să definească teritoriul. Îi dăduseră agentului instrumente, credențiale, un obiectiv și un ton de încredere. Nu definiseră care sisteme erau doar pentru citire, care acțiuni necesitau aprobare, care furnizori erau sensibili, care înregistrări erau autoritare, care câmpuri contau ca controale financiare, cum să se oprească atunci când identitatea era ambiguă sau ce dovezi trebuiau păstrate atunci când se făcea o modificare. Agentul nu era prea inteligent. Era insuficient guvernat. Asta e mai puțin dramatic și mai frecvent.
Agentii au nevoie de limite înainte de autonomie, pentru că autonomia nu este o trăsătură de personalitate. Este permisiunea de a urmări un obiectiv prin mai mulți pași. Fiecare permisiune are un perimetru, altfel devine o scurgere. Întrebarea utilă nu este cât de autonom îl putem face. Întrebarea utilă este ce sarcină delimitată poate îndeplini acest sistem, cu ce instrumente, sub ce reguli de evidență și ce trebuie să se întâmple când lumea nu se mai potrivește cu scenariul ideal.
Un agent este un flux de lucru cu inițiativă
Cuvântul agent face oamenii să își imagineze un coleg digital. Această metaforă este utilă până nu mai este. Un coleg are context de angajare, judecată socială, teamă de întâlniri stânjenitoare, memorie a greșelilor trecute, un manager și bunul simț de a nu trimite un e-mail departamentului juridic la 02:00 decât dacă clădirea chiar arde. Un agent software are o buclă. Observă, planifică, apelează instrumente, citește rezultate, actualizează starea și decide dacă să continue. Acea buclă poate fi puternică. Nu este același lucru cu maturitatea organizațională într-o cutie.
Să numim sistemul „agent" nu ar trebui să scuze un design vag. Ar trebui să ceară un design mai strict, pentru că sistemul poate face mai mulți pași fără ca un om să intervină între ei. Un chatbot poate răspunde greșit și se oprește. Un agent poate răspunde greșit, poate deschide un tichet, poate modifica un câmp, poate trimite un mesaj, poate declanșa un flux de lucru, poate cheltui bani și apoi poate folosi rezultatul acelei acțiuni ca dovadă pentru acțiunea următoare. O neînțelegere mică poate deveni un proces mic. Procesele sunt locul unde organizațiile stochează consecințele.
Viziunea de agent este utilă atunci când face echipele să cartografieze bucla completă. Ce poate observa agentul. Ce surse sunt autoritare. Cum interpretează intenția. Ce instrumente poate apela. Ce apeluri de instrumente sunt reversibile. Care necesită aprobare. Câți bani, cât timp, câtă putere de calcul sau câtă atenție poate cheltui. Ce stare păstrează. Cum știe că a terminat. Cum cere ajutor. Ce dovezi rămân după ce bucla se încheie. Aceste întrebări nu sunt birocrație. Sunt manualul de operare pentru acțiunea delegată.
Fără acest manual, autonomia devine permisiunea de a improviza în sistemele de afaceri. Improvizația este în regulă în jazz. Este mai puțin fermecătoare atunci când editează datele master.
Limitele nu sunt cătușe
Echipele uneori rezistă la limite pentru că sună ca o modalitate de a face agenții mai puțin utili. Este invers. Limitele sunt ceea ce face ca utilitatea să fie suportabilă. O persoană poate conduce rapid pentru că drumurile au benzi, indicatoare, limite de viteză, frâne și reguli pentru intersecții. Elimină aceste constrângeri și nu ai creat un sistem de transport mai avansat. Ai creat o întâlnire cu asigurare.
O limită bună îi spune agentului ce poate optimiza și ce trebuie să păstreze. I se poate permite să reducă timpul de răspuns, dar nu ocolind aprobarea. I se poate permite să redacteze mesaje către furnizori, dar nu să le trimită către părți restricționate. I se poate permite să reconcilieze înregistrări, dar nu să suprascrie un sistem autoritar fără un prag de încredere și o cale de revizuire. I se poate permite să cheltuie putere de calcul, dar doar în limita unui buget și cu un motiv. Limita nu este o negare a autonomiei. Este forma care face autonomia lizibilă.
Limitele fac, de asemenea, rezultatele testabile. Dacă agentul are un domeniu clar de instrumente, evaluatorii pot testa utilizarea greșită a instrumentelor. Dacă are un domeniu de date, pot testa scurgerile. Dacă are un buget, pot testa buclele scăpate de sub control. Dacă are reguli de escaladare, pot testa ambiguitatea. Dacă are cerințe de dovezi, pot testa auditabilitatea. Autonomia vagă nu poate fi testată decât așteptând până când se întâmplă ceva ciudat și apoi ținând o întâlnire în care toată lumea folosește cuvântul aliniere cu semnificații diferite.
Cea mai utilă limită este adesea plictisitoare: citește înainte de a scrie. Permite agentului să citească pe scară largă sub permisiune, să propună schimbări și să scrie doar în sisteme înguste unde corectarea este ușoară. Apoi extinde. Autonomia ar trebui să crească din comportament dovedit, nu din entuziasm. Entuziasmul este un model slab de control al accesului, deși are un departament de vânzări puternic.
Accesul la instrumente este locul unde autonomia devine reală
Un agent fără instrumente este, în mare parte, un planificator vorbăreț. Un agent cu instrumente este software operațional. În momentul în care poate trimite un e-mail, actualiza o înregistrare, rula o interogare, crea o cerere de achiziție, muta un fișier, apela o API sau declanșa un alt flux de lucru, sistemul a trecut de la sugestie la acțiune. Această trecere merită mai multă ceremonie decât o căsuță bifată numită „activare instrumente”.
Permisiunile pentru instrumente ar trebui împărțite în funcție de consecințe. Citirea unei înregistrări despre un client nu este același lucru cu editarea ei. Redactarea unui e-mail nu este același lucru cu trimiterea lui. Crearea unui tichet nu este același lucru cu închiderea unuia. Rularea unei analize nu este același lucru cu publicarea rezultatului. Un design matur de agent tratează fiecare acțiune cu instrumentul ca pe un contract: intrări, utilizatori autorizați, ținte permise, efecte secundare, idempotență, revenire, dovezi și aprobare. Dacă pare prea greoi, începeți cu mai puține instrumente. Răspunsul la un control slab nu este o rază de explozie mai mare.
Acțiunile ireversibile necesită un tratament special. Plățile, ștergerile, suspendările de conturi, notificările legale, angajamentele față de clienți, modificările de preț și deciziile de politică nu ar trebui să fie apeluri obișnuite de instrumente, cu excepția cazului în care domeniul are controale extrem de solide. Multe fluxuri de lucru pot folosi un model în doi pași: agentul pregătește, explică și pune în coadă acțiunea; o persoană sau un serviciu de control separat aprobă execuția. Aceasta nu este o supraveghere umană paternalistă. Este separarea atribuțiilor, o idee suficient de veche încât să fi supraviețuit multor tendințe software și mai multor fonturi.
Chiar și acțiunile reversibile au nevoie de jurnale de audit. Dacă un agent actualizează un câmp, înregistrarea ar trebui să arate valoarea anterioară, valoarea nouă, dovada, versiunea politicii, apelul instrumentului, versiunea agentului și dacă o persoană a modificat ulterior. În caz contrar, revenirea devine o ghicitoare. Ghicitul este costisitor atunci când este făcut de oameni cărora li s-a promis că automatizarea va economisi timp.
Starea este date de afaceri
Agenții își amintesc lucruri. Păstrează starea sarcinilor, starea conversațiilor, rezultatele instrumentelor, rezumate, ciorne, planuri, înglobări, preferințe și, uneori, memorie pe termen lung. Această memorie poate îmbunătăți continuitatea. Poate deveni, de asemenea, un sistem de afaceri paralel dacă nimeni nu o guvernează. Agentul își poate aminti că un furnizor este dificil, că un client preferă o reducere, că un caz pare suspect sau că o soluție de rezervă funcționează de obicei. Aceste amintiri pot modela acțiuni viitoare. Nu mai sunt note inofensive.
Starea are nevoie de proprietate, păstrare, corectare și reguli de acces. Cine poate vedea ce își amintește agentul. Cât timp o păstrează. Poate un utilizator să o corecteze. Moștenește sensibilitatea din sursă. Este folosită pentru decizii viitoare. Se mută între utilizatori. Este inclusă în prompturi. Este ștearsă când înregistrarea sursă este ștearsă. Acestea sunt întrebări obișnuite de guvernanță a datelor, deghizate în agent. Deghizarea nu schimbă nimic, în afară de viteza cu care problemele se pot răspândi.
Scratchpad-urile pe termen scurt merită și ele atenție. Un plan poate conține raționamente sensibile, credențiale din greșeală, fapte deduse sau presupuneri greșite. Dacă este înregistrat pe scară largă, poate să scurgă informații. Dacă nu este înregistrat deloc, sistemul devine greu de depanat. Răspunsul corect depinde de riscul din domeniu, dar trebuie să existe un răspuns. Politica de memorie nu ar trebui să fie orice s-a întâmplat să stocheze framework-ul marțea trecută.
Când starea este guvernată, agenții devin mai ușor de îmbunătățit. Echipele pot vedea unde s-a blocat bucla, ce presupuneri s-au repetat, ce surse au fost utile, ce apeluri de instrumente au eșuat și ce intervenții umane au corectat traseul. Fără stare guvernată, evaluarea devine o ședință de spiritism cu stack trace-uri.
Ambiguitatea este cazul normal
Multe demonstrații cu agenți funcționează pentru că lumea din demonstrație este ordonată. Clientul are un singur cont. Politica are o singură excepție. Furnizorul are o singură entitate juridică. Sarcina are un singur pas următor evident. Operațiunile reale sunt mai puțin politicoase. Numele se ciocnesc. Înregistrările sunt duplicate. Permisiunile sunt învechite. Cineva a scris vezi emailul anterior, o expresie care a făcut mai mult rău automatizării decât multe standarde tehnice. Agentul trebuie proiectat pentru ambiguitate ca fiind cazul normal, nu ca o întrerupere jenantă.
Limitele bune îi spun agentului când să nu acționeze. Dacă încrederea în identitate este scăzută, oprește-te. Dacă două surse autoritare nu sunt de acord, oprește-te sau escaladează. Dacă acțiunea cerută implică o parte restricționată, oprește-te. Dacă costul depășește un buget, oprește-te. Dacă rezultatul instrumentului contrazice planul, oprește-te. Dacă același pas se repetă prea des, oprește-te. Dacă agentul nu își poate explica dovezile, oprește-te. Condiția de oprire nu este un eșec. Este o funcție de siguranță cu umilință.
Escaladarea ar trebui să fie specifică. Nu oferi unei persoane un mesaj vag care spune că agentul are nevoie de ajutor. Spune ce limită a fost atinsă, ce dovezi au fost văzute, ce acțiune a fost propusă, ce risc rămâne și ce decizie este necesară. Oamenii sunt buni la judecată atunci când sistemul aduce contextul potrivit. Sunt mai puțin buni când sunt chemați într-o ceață și rugați să o binecuvânteze.
Există aici o problemă de demnitate pentru lucrători. Dacă agenții aruncă fiecare caz dificil către oameni fără context, automatizarea devine o mașină care concentrează mizeria asupra acelorași oameni ca înainte. Dacă agenții ascund ambiguitatea și acționează oricum, oamenii moștenesc consecințele. Limitele ar trebui să distribuie munca onest: mașinile gestionează repetiția limitată, oamenii gestionează judecata nerezolvată, iar sistemul păstrează suficiente dovezi încât nicio parte să nu fie nevoită să prefacă.
Supravegherea umană este un design, nu un scaun
Expresia „a pune omul în circuit” este populară pentru că sună responsabil și nu costă nimic pe un slide. În practică, înseamnă adesea că o persoană trebuie să observe tot ce ar putea face sistemul greșit, în timp ce ține pasul cu munca pe care automatizarea trebuia să o reducă. Asta nu este supraveghere. Asta este o poziție de stres cu un dashboard.
O supraveghere bună definește ce anume revizuiește omul și de ce. Persoana aprobă o acțiune a unui instrument, validează dovezi, rezolvă un conflict, gestionează o excepție, schimbă o politică sau eșantionează rezultatele pentru calitate. Fiecare rol are nevoie de informații diferite. Aprobarea are nevoie de acțiunea propusă și de consecință. Revizuirea dovezilor are nevoie de surse și versiuni. Rezolvarea conflictelor are nevoie de pretențiile concurente. Eșantionarea calității are nevoie de distribuții, nu de anecdote. Atenția umană este limitată. Cheltuiește-o ca pe infrastructură.
Supravegherea trebuie, de asemenea, sincronizată corect. Revizuirea după o acțiune ireversibilă nu este supraveghere; este arheologie cu sentimente. Revizuirea fiecărui pas banal distruge valoarea automatizării. Modelul util este cel al porților bazate pe risc. Acțiunile reversibile cu risc scăzut pot continua cu înregistrare. Acțiunile cu risc mediu pot necesita revizuire atunci când încrederea este scăzută sau o limită este aproape. Acțiunile cu risc ridicat necesită aprobare înainte de execuție. Fluenta modelului nu ar trebui să decidă poarta. Consecința ar trebui.
Oamenii au nevoie de autoritate egală cu responsabilitatea. Dacă un revizor poate doar să aprobe sau să respingă, dar nu poate corecta datele sursă, actualiza o limită, îmbunătăți o regulă sau semnala un instrument defect, aceeași problemă va reveni. Supravegherea ar trebui să alimenteze sistemul. Altfel, oamenii devin un strat decorativ de siguranță, ceea ce este nedrept pentru oameni și surprinzător de inutil pentru siguranță.
Frontiera autonomiei
Autonomia nu este un întrerupător. Este o frontieră care se mută pe măsură ce dovezile se îmbunătățesc. La un capăt, un agent redactează recomandări și nu poate acționa. Apoi poate acționa într-un sandbox. Apoi poate scrie în sisteme cu risc scăzut. Apoi poate efectua acțiuni de producție limitate. Apoi poate coordona între sisteme cu aprobări. Apoi, pentru domenii foarte mature, poate gestiona muncă restrânsă cu supraveghere bazată pe excepții. Fiecare pas ar trebui câștigat prin performanță, nu promis prin diagrame de arhitectură.
Frontiera este diferită pentru fiecare domeniu. Un agent care programează întâlniri interne poate avea mai multă libertate decât unul care modifică termenii de plată. Un agent care etichetează documente poate avea mai multă libertate decât unul care le șterge. Un agent care ajută un inginer să trieze jurnalele poate avea mai multă libertate decât unul care contactează clienții. Același model de bază poate sta în spatele unor niveluri diferite de autonomie, deoarece consecința, nu modelul, determină limita.
Mișcarea de-a lungul frontierei necesită dovezi: rezultate ale evaluărilor, istoricul incidentelor, ratele de eroare ale instrumentelor, calitatea escaladărilor, succesul revenirilor, încrederea utilizatorilor, conformitatea cu politicile și comportamentul costurilor. Dacă agentul întâlnește în mod repetat aceeași ambiguitate, răspunsul poate fi date mai bune, o politică mai clară sau un domeniu mai restrâns, nu mai multă autonomie. Dacă agentul performează bine într-o coadă, nu presupune că se va comporta la fel în alta. Contextul de afaceri nu este un parc de distracții. Cerințele de înălțime sunt locale.
De aceea, expresia „pe deplin autonom” este de obicei mai puțin utilă decât speră oamenii. Autonom deplin în ce anume. Pentru cât timp. Cu ce instrumente. Sub ce buget. În conformitate cu ce politică. Cu ce cale de atac. Versiunea serioasă este mai restrânsă și mai puternică: autonom în cadrul acestei sarcini limitate, cu aceste controale, până la aceste condiții de oprire. Sună mai puțin impresionant. Este mai probabil să supraviețuiască contactului cu marțea.
Granitele trebuie întreținute
O graniță nu este gata când a fost scrisă. Regulile de business se schimbă, furnizorii fuzionează, datele se mută, echipele se reorganizează, modelele se actualizează, instrumentele capătă funcții noi, iar utilizatorii descoperă scurtături. O graniță de agent care avea sens în ianuarie poate fi greșită în martie. Nu este un eșec al designului inițial. Este realitatea oferind control de versiuni în stilul ei obișnuit de nepoliticos.
Întreținerea granițelor are nevoie de responsabilitate clară. Cineva deține declarația de scop. Cineva deține domeniul datelor. Cineva deține permisiunile instrumentelor. Cineva deține limitele bugetare. Cineva deține regulile de escaladare. Cineva deține evaluarea. Cineva deține analiza incidentelor. Dacă toți dețin granița, agentul o deține, ceea ce este o modalitate poetică de a spune că nimeni nu o face. Granițele ar trebui versionate, revizuite și conectate la incidente și la comportamentul observat.
Controlul schimbărilor ar trebui să includă teste. Dacă un instrument capătă o acțiune nouă, agentul nu o primește automat. Dacă o sursă de date își schimbă schema, regăsirea și gestionarea stării ar trebui verificate. Dacă o politică se schimbă, prompturile, regulile și cazurile de evaluare ar trebui să se schimbe odată cu ea. Dacă o versiune de model se schimbă, testele de regresie ar trebui să includă selecția instrumentelor, refuzul, escaladarea și calitatea dovezilor. Agentul nu este un strat magic peste proces. Este proces cu o bătăi de inimă mai rapidă.
Întreținerea înseamnă și retragerea autonomiei. Dacă mediul devine mai riscant, dacă rata incidentelor crește, dacă un furnizor devine sensibil, dacă reglementările se schimbă sau dacă calitatea dovezilor scade, autonomia ar trebui să meargă înapoi. Asta poate părea un eșec. Este de fapt controlul funcționând. Frânele nu sunt o recunoaștere că mașinile au fost o greșeală.
Lecția organizațională
Agentele scot la iveală cât de bine înțelege o organizație propria muncă. Dacă fluxul de lucru este plin de excepții informale, responsabilități neclare, înregistrări duplicate, politici ascunse și memorie umană eroică, un agent nu va face magie să îl curețe. Se va împiedica, va acționa greșit sau va cere atât de multe aprobări încât oamenii vor începe să îl folosească ca pe o formă mai lentă de email. Agentul nu a creat haosul. L-a făcut executabil.
Asta poate fi util. Designul de agent forțează echipele să numească postul, să definească autoritatea, să clasifice datele, să separe instrumentele, să scrie condiții de oprire și să păstreze dovezi. Acestea sunt obiceiuri operaționale sănătoase chiar și înainte de automatizare. O echipă care nu poate defini granițe pentru un agent probabil nu poate explica nici fluxul de lucru suficient de bine pentru oameni. Software-ul este pur și simplu mai puțin politicos în privința ambiguității.
Cele mai bune implementări de agenți încep mai restrâns decât ambiția. Ele aleg un flux de lucru real, cu limite cunoscute, volum semnificativ, impact limitat și responsabili care pot îmbunătăți sistemul. Ele observă unde oamenii folosesc judecata. Automatizează repetiția delimitată. Păstrează dovezi. Escaladează clar. Se extind doar când limita actuală s-a dovedit. Acest lucru nu este lent. Așa evită viteza să devină curățenie.
Autonomia fără limite cere unui sistem să se comporte ca un angajat bun, refuzându-i însă contextul organizațional care îi face pe angajați buni. Autonomia delimitată pune o întrebare mai bună: ce parte a muncii poate fi delegată într-un mod care rămâne verificabil, reversibil acolo unde este posibil și onest atunci când nu știe. Această întrebare este mai puțin spectaculoasă. Este și cea care le permite agenților să devină operațiuni, nu teatru.
Lecția
Agenții au nevoie de limite înainte de autonomie, pentru că fiecare pas autonom este un act delegat. Delegarea fără scop nu este încredere. Este abdicare cu terminologie mai frumoasă. Definește mai întâi sarcina, datele, instrumentele, bugetele, starea, dovezile, condițiile de oprire, escaladarea și căile de reparare. Apoi autonomia poate crește acolo unde sistemul o merită.
Scopul nu este să faci agenții timizi. Scopul este să îi faci utili în locurile unde munca contează. Limitele le permit agenților să acționeze mai repede fără să facă consecințele invizibile. Ele le permit oamenilor să supravegheze judecata în loc să supravegheze mecanica. Transformă greșelile în reparații, nu în mistere. Cel mai important, ele oferă organizației o modalitate de a spune în ce are voie agentul să fie bun.
Un agent liber sună interesant până întâlnește un flux de lucru real. Un agent delimitat poate suna mai puțin eroic. Bine. Eroismul este un model operațional slab. Limitele sunt modul în care autonomia devine muncă responsabilă.