AI agentų stebimumas ir valdymas: naujo stebėjimo paketo kūrimas

Įvadas

Įmonėms diegiant vis daugiau autonominių AI agentų – nuo pokalbių asistentų iki užduotis automatizuojančių „botų“ – atsiranda naujas iššūkis: stebimumas. Šie agentai priima daugybę sprendimų, kviečia API, atnaujina kontekstą ir net veikia vartotojų vardu. Tačiau tradicinės stebėjimo priemonės suteikia tik siaurą vaizdą. Praktikoje komandos dažnai remiasi išsklaidytais žurnalais ar prietaisų skydeliais, kurie nebuvo sukurti agento daugiapakopiam mąstymui fiksuoti. Naujausia Dynatrace apklausa parodė, kad pusė AI valdomų projektų sustoja bandomojoje stadijoje, nes organizacijos „negali valdyti, patvirtinti ar saugiai plėsti“ savo agentų (www.itpro.com). Panašiai, „Microsoft“ saugumo vadovai įspėja, kad „negali apsaugoti to, ko nematome“ – pabrėždami, kad AI agentams reikia „stebimumo valdymo lygmens“ didėjant diegimui (www.itpro.com) (www.itpro.com). Šiame straipsnyje nagrinėjame stebėjimo spragas autonominiams ir pusiau autonominiams agentams (ypač susijusias su įrankių naudojimu, atmintimi ir sprendimų priėmimo keliais). Tada siūlome specializuotą stebimumo ir valdymo platformą, kuri fiksuoja visus veiksmus nuo pradžios iki pabaigos, įgyvendina politikas, simuliuoja darbo eigas ir gali atšaukti nesaugius veiksmus. Šį metodą lyginame su tradiciniais APM (programos veikimo stebėjimo) įrankiais, paaiškiname, kodėl agentams būdinga telemetrija yra kritiškai svarbi, ir apibrėžiame kainodaros/integravimo modelį (pvz., atsiskaitymas už agento minutę su PagerDuty/Jira integracijomis).

AI agentų stebėjimo spragos

AI agentai nėra pavieniai API iškvietimai; tai yra daugiapakopės darbo eigos, kurios planuoja, gauna informaciją, kviečia įrankius ir sintezuoja rezultatus esant neaiškumui (www.stackai.com). Šis sudėtingumas sukuria akląsias zonas įprastiniam stebėjimui:

• Fragmentuota telemetrija: Daugumoje aplinkų telemetrija yra izoliuota. Viena sistema registruoja galinių taškų įvykius, kita rodo tinklo srautą, trečioje saugomi autentifikavimo duomenys. „TechRadar“ pažymi, kad „dauguma AI agentų remiasi tomis pačiomis fragmentuotomis telemetrijos sistemomis, su kuriomis analitikai kovoja metų metus“ (www.techradar.com). Nesukorreliavus šių signalų, agentui trūksta konteksto, kad galėtų teisingai samprotauti. Pavyzdžiui, AI gali įtarti paskyros pažeidimą tik tuo atveju, jei mato ir neįprastą prisijungimą (iš žurnalų), ir įtartiną tinklo modelį – bet jei šie signalai yra skirtinguose įrankiuose, agentas „tiesiog nežino pakankamai“ (www.techradar.com) (www.techradar.com). Trumpai tariant, fragmentuoti duomenys sukuria matomumo spragą: agentai veikia turėdami nepilną informaciją, o tai veda prie tylių gedimų (neteisingų veiksmų, kurie lieka nepastebėti).

• Įrankių iškvietimų aklosios zonos: Agentai dažnai iškviečia išorinius įrankius ar API (pvz., duomenų bazes, žinių bazes, žiniatinklio paslaugas). Tradicinis stebėjimas gali tik užregistruoti, kad įvyko HTTP užklausa, tačiau agento stebimumas turi užfiksuoti, kuris įrankis buvo pasirinktas ir kodėl. Stebimumo platforma turėtų užfiksuoti tikslią užklausą ar kontekstą, nulėmusį to įrankio pasirinkimą, perduotus argumentus ir visą išvestį ar klaidos atsakymą (www.braintrust.dev). Be to, agentas gali pateikti neteisingus parametrus arba neteisingai interpretuoti įrankio atsakymą, ir problema liktų paslėpta. Pavyzdžiui, „Braintrust“ stebimumo vadove pabrėžiama, kad kiekvienas įrankio iškvietimas turėtų būti sekamas su jo įvestimi ir išvestimi, kad inžinieriai galėtų „aptikti haliucinuotus parametrus, trūkstamus laukus ar neteisingą formatavimą“ (www.braintrust.dev).

• Neskaidrios atminties operacijos: Daugelis agentų naudoja atminties ar paieškos sistemas (pvz., vartotojo profilį, RAG žinių saugyklą). Šis dinamiškas kontekstas gali sukelti gedimus, kurių neįmanoma aptikti neužregistravus „ką agentas skaito ir rašo“ (www.braintrust.dev). Pavyzdžiui, jei agentas gauna pasenusį atminties įrašą arba neteisingus vartotojo duomenis, atsakymas gali tyliai tapti neteisingu. Stebimumas turėtų registruoti paieškos užklausas, grąžintus elementus, atitiktumo balus ir atnaujinimo metaduomenis, kad būtų galima atsekti neteisingą išvestį iki pasenusio ar netinkamai nukreipto atminties skaitymo (www.braintrust.dev). Taip pat, kiekvienas atminties įrašymas turėtų būti registruojamas (kas buvo saugoma, kokiu raktu), siekiant aptikti kaupiamąsias klaidas arba duomenų nutekėjimą (pvz., vieno vartotojo informacija, pasirodanti kito sesijoje) (www.braintrust.dev).

• Nematomos sprendimų trajektorijos: Skirtingai nuo žiniatinklio užklausos su aiškiu „įvesti kodą, gauti atsakymą“ srautu, agentai paprastai vykdo planavimo-veikimo-stebėjimo ciklą. Jie sukuria planą, imasi veiksmų (pvz., „ieškoti žinių bazėje“), stebi rezultatą, tada nusprendžia perplanuoti arba tęsti. Paprasti žurnalai negali atskleisti šio šakojimosi kelio. Stebimumas reikalauja užfiksuoti kiekvieną žingsnį paeiliui, su agento „priežastimi“ kiekvienam veiksmui. Be to, mes galėtume matyti tik galutinę išvestį ir manyti, kad viskas gerai – net jei agentas pusiaukelėje nukrypo nuo užduoties arba užstrigo. Pavyzdžiui, „Braintrust“ pabrėžia „plano nukrypimą“ (agentas tyliai keičia tikslus) ir „begalinius ciklus“ kaip gedimų režimus, kuriuos gali atskleisti tik žingsnis po žingsnio sekimas (www.braintrust.dev). Tinkamas sekimas registruoja kiekvieną po-agento iškvietimą, šakojimosi sprendimą ir ciklo trukmę, aiškiai parodant, ar agentas atsakė į neteisingą klausimą, ar kartojo veiksmus be progreso.

• Tylūs kokybės gedimai: Daugelis agentų gedimų nesukelia HTTP klaidų ar avarijų. Vietoj to, agentas gali haliucinuoti duomenis, pažeisti vartotojo nurodymus arba nukrypti nuo politikos. Įprastiniai stebėjimo įrankiai (pvz., Datadog ar New Relic) tikrina tik vėlavimą ar klaidų dažnį (www.techradar.com), todėl sistema praneštų „viskas žalia“, net jei atsakymas buvo faktiškai neteisingas. „StackAI“ paaiškina, kad tradiciniai APM įrankiai numato deterministinę programinę įrangą – bet agentai pažeidžia šias taisykles (www.stackai.com). Pavyzdžiui, raginimo pakeitimas ar modelio atnaujinimas gali subtiliai pabloginti atsakymo kokybę, nesukeliant jokio akivaizdaus įspėjimo (www.stackai.com). Todėl stebimumas turi apimti semantinius patikrinimus: pvz., haliucinacijų dažnio ar politikos pažeidimų incidentų stebėjimą. Apibendrinant, įprastiniai monitoriai rodo, kad agentas atsakė laiku, tačiau tik agentams būdinga telemetrija gali parodyti, ar atsakymas buvo teisingas, tinkamas ar saugus.

• Valdymo ir saugumo rizikos: AI agentai sukuria naujų atitikties iššūkių (raginimų injekcijos, privatumo nutekėjimas, neautorizuoti veiksmai). Be pritaikytos telemetrijos šios rizikos yra nematomos. „StackAI“ pažymi, kad stebimumas ir valdymas susilieja: „negali įgyvendinti politikų, kurių negali aptikti“ (www.stackai.com). Pavyzdžiui, jei klientų aptarnavimo režime veikiantis agentas pradėtų nutekinti asmeninius duomenis, tik detalūs sekimo žurnalai galėtų atskleisti pažeidimo šaltinį. Todėl mūsų platforma turi stebėti politikos pažeidimus realiuoju laiku (pvz., žymėti PII išvestyse, blokuoti neleistinus API iškvietimus) ir teikti audito pėdsaką atitikčiai užtikrinti.

Apibendrinant, esami APM ir žurnalų paketai tiesiog nefiksuoja, kaip mąsto AI agentas: mąstymo grandinės, šakojimosi logikos ir dinaminio konteksto. Tai sukelia aklasias zonas įrankių iškvietimuose, atminties naudojime ir sprendimų trajektorijose. Neišsprendus šių spragų, įmonės rizikuoja tyliais agentų gedimais, saugumo pažeidimais ir pasitikėjimo praradimu.

AI agentų stebimumo ir valdymo platformos kūrimas

Siekiant užpildyti šias spragas, siūlome specializuotą AI agentų stebimumo ir valdymo platformą. Ši paslauga instrumentuotų agentus nuo pradžios iki pabaigos, užtikrintų valdymą ir leistų saugiai eksperimentuoti. Pagrindinės savybės apima:

Visiškas sekimas ir registravimas

Kiekvienas agento paleidimas turėtų sukurti seką (trace), kuri įrašo visą vykdymo grafiką. Įkvėptas paskirstytųjų sistemų praktikos, kiekvieno agento darbo eiga yra seka, o kiekvienas veiksmas (LLM raginimas, įrankio iškvietimas, atminties užklausa, po-agento perdavimas) yra tarpsnis (span) toje sekoje (www.stackai.com) (www.braintrust.dev). Tai reiškia, kad inžinierius gali matyti tikslią seką: kokį raginimą agentas matė, kaip jis padalijo užduotį į etapus ir ką grąžino kiekvienas įrankis. Pavyzdžiui, jei agentas užklausia dokumentų saugyklą, seka užregistruoja užklausą ir gautą turinį; jei tada ji performuluoja užklausą, tai yra naujas tarpsnis. Sesijos identifikatoriai susieja daugiapakopius pokalbius ar ilgas užduotis. Naudojant standartinius protokolus, tokius kaip OpenTelemetry, šios sekos gali patekti į esamas APM posistemes. Kaip pažymima viename vadove, „šie primityvai vis labiau tinka esamiems stebimumo modeliams“ (www.stackai.com). Praktiškai tai leidžia susieti agento elgesį su pagrindine infrastruktūra: procesoriaus viršūnes, tinklo I/O ar duomenų bazės iškvietimus galima peržiūrėti kartu su agento mąstymo etapais.

Vietoj to, kad registruotų neapdorotą tekstą laisvu formatu, platforma saugo struktūrizuotus tarpsnius (spans). Pavyzdžiui, tarpsnis gali užregistruoti: Įrankis: emailSender, Įvestis: JSON duomenų paketas, Išvestis: sėkmė arba klaida, Vėlavimas: 200 ms. Sudėjus tarpsnius (pvz., įrankio iškvietimus po pagrindiniu LLM iškvietimu), inžinieriai gali išsamiau ištirti, kur buvo sugaištas laikas arba kuris žingsnis sukėlė gedimą. Svarbu, kad visos vartotojo įvestys, sistemos instrukcijos ir atminties nuskaitymai taptų sekos duomenimis. Šis struktūrizuotas registravimas pakeičia varginantį „spausdinimo derinimo“ procesą ir leidžia ieškoti bei filtruoti žurnalus (pvz., parodyti visus paleidimus, kuriuose agentas naudojo financialAPI įrankį).

Politikos įgyvendinimas realiuoju laiku

Platforma veikia ir kaip valdymo lygmuo valdymui. Ji nuolat tikrina agento telemetriją pagal saugumo ir verslo politikas. Pavyzdžiui, jei agentas bando vykdyti neautorizuotą darbo eigą (pvz., prieiti prie HR atlyginimų sistemos, kai jam neleidžiama), politikos variklis gali nedelsiant įsikišti. Taisyklės gali būti apibrėžtos sekos duomenims: pvz., „Įspėti, jei išvestyje yra kredito kortelės duomenų modelių“ arba „Blokuoti bet kokį duomenų bazės įrašymą ne darbo valandomis (nuo 9 iki 17 val.).“ Kadangi „negali įgyvendinti politikų, kurių negali aptikti“ (www.stackai.com), šie stebimumo duomenys leidžia įgyvendinti politiką. Praktiškai pažeidimai gali sukelti automatizuotą sulaikymą: platforma gali pristabdyti agentą, eskaluoti įspėjimą arba atšaukti visus jo atliktus pakeitimus. Integruotas „agento išjungimo jungiklis“ leidžia administratoriams sustabdyti arba apriboti netinkamai veikiančius agentus (atkartojant patarimą, kad vadovybė turėtų žinoti „Kas yra išjungimo jungiklis?“ (www.techradar.com)). Pavyzdžiui, jei kenkėjiškos programinės įrangos skaitytuvo agentas pradeda veikti nekorektiškai, kai telemetrija pažymi nenormalų elgesį, sistema gali nedelsiant izoliuoti jo leidimus ir įspėti budintį inžinierių.

Politikos įgyvendinimas apima ir privatumo bei saugos patikrinimus. Sistema galėtų paleisti automatizuotus PII detektorius visiems siunčiamiems pranešimams arba turėti „LLM-kaip-teisėjo“ modulį, kuris aptiktų haliucinacijas ar politikos nukrypimus. Bet koks saugos pažeidimas registruojamas kaip incidentas. Integravus šiuos patikrinimus į stebimumo lygmenį, įmonės gauna tiesioginę saugos prietaisų skydelį be našumo metrikų.

Neprisijungusio režimo simuliacija ir „smėlio dėžės“ testavimas

Prieš diegiant bet kokius reikšmingus pakeitimus, verta simuliuoti scenarijus. Mūsų platforma apima smėlio dėžės aplinką agentų darbo eigų pakartotiniam paleidimui arba imitavimui. Komandos gali pateikti agentui testavimo atvejų rinkinį (atspindintį dažnus vartotojų prašymus ar kraštutinius atvejus) ir surinkti sekos žurnalus bandomajame paleidime. Šis neprisijungęs vertinimas užtikrina, kad nauji raginimai ar modelių atnaujinimai nepažeis politikų ir nesumažins kokybės (www.braintrust.dev). Pavyzdžiui, prieš suteikiant finansų agentui naujas API privilegijas, inžinieriai galėtų simuliuoti mėnesio pabaigos uždarymo užduotis, kad patikrintų, ar jis laikosi patvirtinimo srautų. Sistema taip pat gali aptikti regresijas: jei atnaujinta agento versija staiga neteisingai sukonfigūruoja įrankius, testavimo sekos atskleidžia klaidą, kol ji dar nepasiekė gamybos.

Iš esmės, tai panašu į chaoso inžineriją AI srityje: tyčinis agento veikimas grėsmės scenarijuose ar su neteisingais duomenimis, siekiant pamatyti, ar jis nukryps nuo kurso. „TechRadar“ pataria įmonėms „įvertinti pasirengimą smėlio dėžės vertinimais... kad sprendimų priėmimas būtų išbandytas ir būtų suprastas atsistatymo laikas“ (www.techradar.com). Platforma gali automatizuoti šiuos pratybas pagal tvarkaraštį, registruodama kiekvieną paleidimą. Tai padeda anksti aptikti paslėptus gedimus (pvz., pasenusį konteksto indeksavimą). Integravus vertinimą į kūrimo srautą, komandos pasiekia grįžtamojo ryšio ciklą: gamybos klaidos tampa naujais testavimo atvejais, o kiekvienas leidimas turi praeiti neprisijungusio režimo patikrą.

Vykdymo kontrolė ir atšaukimas

Net ir taikant prevenciją, klaidų gali pasitaikyti. Mūsų platforma teikia atkūrimo įrankius. Pirma, realaus laiko „stop“ komanda gali nedelsiant sustabdyti agento veiksmus. Ilgai trunkančioms ar asinchroninėms užduotims sistema gali iškviesti atšaukimo taškus, jei pažeidžiama politika (pvz., nutraukti operaciją, jei agentas bando išsiimti lėšas be patvirtinimo). Antra, kadangi visi veiksmai yra sekami, platforma gali pakartotinai atkurti arba anuliuoti padarinius. Pavyzdžiui, jei agentas klaidingai išsiuntė el. laiškus klientams arba atnaujino CRM, operatoriai gali naudoti žurnalus, kad atkurtų būseną prieš pakeitimą. Kartu su nekeičiamais audito žurnalais, tai leidžia atšaukti duomenų bazės operacijas ar failų sistemos pakeitimus, atliktus agento. „TechRadar“ pabrėžia šio poreikį: „organizacijos turi iš naujo įvertinti... atšaukimo kelius kiekviename AI diegime“ (www.techradar.com). Praktiškai platforma gali padaryti būsenos momentinę nuotrauką prieš vykdymą arba integruotis su versijuotomis duomenų saugyklomis, užtikrindama, kad nepavykę agento veiksmai galėtų būti atšaukti kaip klaidingas programinės įrangos diegimas.

Integracija su incidentų valdymu ir bilietų išrašymu

Stebimumas yra pusė mūšio; inžinieriai turi būti veiksmingai įspėjami. Platforma bus integruota su moderniomis incidentų valdymo ir bendradarbiavimo priemonėmis. Pavyzdžiui, ji gali perduoti kritinius agentų įspėjimus į PagerDuty, sukurdama budėjimo incidentą, kai įvyksta rimtas politikos pažeidimas. Ji gali skelbti santraukas Slack arba Microsoft Teams kanaluose („PagerDuty“ pažymi, kad jų sistema turi „pažangias Slack ir Microsoft Teams integracijas“, kad atsakingieji galėtų susikoncentruoti (www.pagerduty.com)). Integracija su bilietų sistemomis taip pat yra būtina: kai suveikia įspėjimas, platforma gali automatiškai sukurti „Jira“ arba „ServiceNow“ bilietą, iš anksto užpildytą sekos ID, paveikta pokalbio ir politikos detalėmis. Tai užtikrina, kad agentų incidentai patektų į tas pačias trikdžių šalinimo darbo eigas kaip ir kiti gedimai. „PagerDuty“ taip pat pabrėžia daugiau nei 700 įrankių integracijų (Datadog, Grafana ir kt.), kad sujungtų stebimumą ir reagavimą (www.pagerduty.com). Panašiai, mūsų platforma pasiūlytų jungtis prie žurnalų (pvz., Splunk), metrikų (Prometheus) ir CI/CD sistemų, kad kiekviena telemetrijos dalis tilptų į esamus prietaisų skydelius ir diagramas.

Tradicinė APM ir agentų telemetrija

Kaip tai lyginama su senesniu Programos veikimo stebėjimo (APM) sprendimu? Trumpai tariant, tradicinė APM (Datadog, New Relic, Dynatrace ir kt.) puikiai tinka infrastruktūros ir kodo lygio metrikoms, tačiau agentus traktuoja kaip juodąsias dėžes. Pavyzdžiui, „Datadog“ gali „automatiškai priimti, analizuoti ir apdoroti žurnalus iš visos jūsų sistemos“, o jos APM modulis „seka užklausas paskirstytose sistemose“ (www.techradar.com). Panašiai, jos tinklo stebėjimas suteikia bendrą serverių, procesoriaus, atminties ir tinklo srautų apžvalgą (www.techradar.com). Šie įrankiai įspės, jei agentas sunaudos per daug procesoriaus arba išmes išimtį. Tačiau visa tai nefiksuoja, ką galvoja agentas. Jie neužregistruos tikrojo raginimo teksto (dėl privatumo taisyklių) ar LLM iškvietimų sekos. Jie nežinos, ar jo pateiktas atsakymas buvo pagrįstas neteisinga atmintimi, ar jis pažeidė verslo taisyklę. Jų požiūriu, „viskas atrodo žalia“, kai tik API iškvietimas grąžina 200 OK (www.stackai.com).

Praktiškai, galima bandyti pritaikyti APM agentams (pvz., žymint kiekvieną pokalbio užklausą ir ieškant žurnaluose). Tačiau be agentams būdingų tarpsnių (spans) lieka spragų. APM numato deterministines darbo eigas: gedimo atveju deriname kodo kelius. Bet su AI agentais gedimai yra tylūs (neteisingas atsakymas) arba semantiniai (politikos pažeidimas), o ne išimtys. „StackAI“ pastebi, kad agentai „pažeidžia daugelį [APM] prielaidų“ – pavyzdžiui, agentas neturi klaidos kodo, kai jis tiesiog haliucinuoja (www.stackai.com). Be to, daugiapakopės agentų grandinės apima daug komponentų (modelius, indeksus, įrankius); jei stebite tik galutinę žiniatinklio užklausą, prarandate visą kontekstą, kaip agentas ten pateko. Galiausiai, APM įrankiai paprastai yra akli AI specifinėms išlaidoms (pvz., žetonų naudojimui) ir kokybės signalams.

Dėl šių priežasčių, įmonės, kuriančios agentų sistemas, vis labiau mato poreikį specializuotai telemetrijai. Kaip pranešė „Dynatrace“, „Stebimumas... yra gyvybiškai svarbi sėkmingos agentų AI strategijos dalis. Komandoms reikia realaus laiko matomumo, kaip AI agentai elgiasi, sąveikauja ir priima sprendimus“ (www.itpro.com). Siūloma platforma suteikia būtent tą daugiasluoksnį vaizdą, kurio negali suteikti APM įrankiai: nuo aukšto lygio sveikatos metrikų iki agento pažintinių žingsnių. Ji iš esmės papildo APM „auksinius signalus“ (vėlavimas, klaida, pralaidumas) agentams būdingomis kokybės metrikomis (pagrįstumas, užbaigimo lygis, haliucinacijų dažnumas) (www.stackai.com) (www.stackai.com).

Kainodaros modelis

Tiesioginis kainodaros modelis yra pagrįstas naudojimu. Vienas požiūris – apmokestinti už agento minutę (laikas, kai agentas aktyviai atlieka užduotis). Pavyzdžiui, paslauga gali kainuoti maždaug 0,05–0,10 USD už agento minutę, panašiai kaip debesis funkcijų atsiskaitymas. Tai padengia sekos/tarpsnio duomenų fiksavimo ir saugojimo, vertinimo patikrinimų vykdymo ir žurnalų saugojimo išlaidas. (Gali būti taikomas bazinis mėnesinis mokestis už prieigą prie platformos plius papildomi mokesčiai už viršijimą.) Papildomas duomenų saugojimas ar žurnalų tūris gali būti apmokestinamas už GB. Didelio tūrio nuolaidos arba įmonių planai galėtų pasiūlyti mažesnius mokesčius už minutę dideliems diegimams. Tai suderina išlaidas su vartojimu: sporadiškai aktyvus robotas patiria minimalius mokesčius, kol jis veikia. Kontekste, daugelis stebėjimo ir be serverių produktų naudoja smulkią naudojimo kainodarą. Mūsų „agento minutės“ metrika yra analogiška – vartotojai tiksliai žino, ką moka už kiekvieną agento veikimo valandą, skatinant efektyvų naudojimą.

Išvada

Autonominiai AI agentai žada didelį produktyvumo augimą, tačiau tik tuo atveju, jei galime matyti ir kontroliuoti jų veiksmus. Besiformuojanti AI stebimumo sritis sprendžia būtent tai: agentų „mąstymo procesų“ padarymą skaidriais ir valdomais. Instrumentuojant įrankių iškvietimus, atminties prieigas ir sprendimų žingsnius kaip sekas, gauname įžvalgų apie neaiškius gedimus ir valdymo spragas. Specialiai sukurta stebėjimo platforma (su politikos įgyvendinimu, simuliacija, atšaukimais ir IR integracija) užtikrina, kad agentai saugiai veiktų gamyboje. Priešingai nei senesni APM įrankiai, agentams būdinga telemetrija traktuoja pačią AI sistemą kaip pirmos klasės pilietį, o ne tik jos serverius.

Kaip perspėja apklausos ir ekspertai, stebimumo trūkumas yra kliūtis, stabdanti agentų AI mastelio didinimą (www.itpro.com) (www.itpro.com). Sukūrus čia aprašytą naują stebėjimo paketą, organizacijos gali „viltį, pagrįstą spėlionėmis“ paversti patikima automatizacija (www.techradar.com). Galiausiai, toks požiūris didina pasitikėjimą, kad agentai elgsis taip, kaip numatyta, ir leidžia drąsiai diegti naujoves. Kai kas nors nutiks ne taip, tai nebebus paslaptingas pažeidimas ar haliucinacija – sekos žurnalai ir valdymo lygmuo tiksliai nurodys gedimo režimą, leidžiantį greitai jį sušvelninti ir išmokti pamokas. Autonominių agentų eroje stebimumas nėra pasirinktinis; tai yra saugaus, mastelio keitimo AI pagrindas.