Interviuri
Randall Newman, CPTO și co-fondator al Satisfi Labs – Serie de interviuri

Randall Newman, CPTO și co-fondator al Satisfi Labs, este un lider în tehnologie și produse cu experiență vastă în construirea de platforme AI, tehnologie financiară și sisteme de înaltă performanță. De la co-fondarea Satisfi Labs, Newman a jucat un rol central în conceperea, proiectarea și scalarea tehnologiei de AI conversațional a companiei, supraveghind dezvoltarea produselor, arhitectura, echipele de inginerie și integrările strategice. Înainte de Satisfi Labs, a ocupat funcția de șef de produs la Satisfi Inc. și a co-fondat compania de marketing mobil Right On Mobile. În primele etape ale carierei sale, Newman a petrecut peste 17 ani la CIBC World Markets, unde a deținut poziții de conducere senior în domeniile riscului strategic, tranzacționării de mare viteză și arbitrajului de acțiuni, combinând expertiza în tranzacționare cantitativă cu dezvoltarea practică a tehnologiei.
Satisfi Labs este o companie AI concentrată pe implementarea de agenți AI specializați pentru sport, divertisment, turism, atracții și alte afaceri cu experiențe în direct. Fondată în 2016, compania a evoluat de la AI conversațional și motorul său Answer Engine la o platformă agentică concepută pentru a ajuta organizațiile să automatizeze suportul pentru oaspeți, să crească conversiile de bilete și comerț și să extragă informații din conversațiile cu clienții. Agenții săi AI pot funcționa în peste 50 de limbi și se pot conecta la sisteme de ticketing, CRM, gestionare de conținut și alte sisteme de afaceri pentru a efectua acțiuni precum vânzarea de bilete, escaladarea conversațiilor către personalul uman, colectarea informațiilor clienților și furnizarea de răspunsuri personalizate. Satisfi Labs afirmă că tehnologia sa este acum utilizată de peste 775 de branduri, cu integrări și parteneriate ce includ companii precum Ticketmaster, Simpleview, MappedIn, Ventrata și Vozzi.
Ai petrecut aproape două decenii pe piețele financiare, inclusiv construind sisteme de tranzacționare cu latență scăzută și conducând strategii de tranzacționare de mare viteză la CIBC, înainte de a trece la antreprenoriatul tehnologic și, în final, la co-fondarea Satisfi Labs. Ce lecții din sistemele de operare, unde viteza, fiabilitatea și gestionarea riscului erau critice, au influențat cel mai mult modul în care construiești astăzi agenți AI de producție?
Tranzacționarea m-a învățat că o idee bună și o afacere bună sunt două lucruri diferite. Poți identifica corect o oportunitate și totuși să pierzi bani deoarece execuția este lentă, costurile sunt prea mari sau ipotezele de risc sunt greșite. AI este la fel. Capacitatea modelului este un factor. Afacerea depinde de faptul dacă poți transforma acea capacitate într-un rezultat repetabil la un cost și risc acceptabile.
Gestionarea unui portofoliu de arbitraj pe indiciu te învață, de asemenea, să privești dincolo de deciziile individuale. O mică eroare repetată în întregul portofoliu devine o expunere foarte mare. În AI, poți avea mii de agenți care iau decizii individual rezonabile, dar care colectiv generează o problemă. Toți depind de aceleași date incorecte sau toți încearcă din nou același serviciu defectuos. Trebuie să gestionezi sistemul, nu doar răspunsul individual.
Și viteza contează doar atunci când îmbunătățește rezultatul. În tranzacționare au existat momente în care microsecundele erau esențiale. În AI, aș prefera să petrec încă o secundă pentru a confirma o tranzacție decât să livrez instantaneu un rezultat greșit. Disciplina constă în a ști unde viteza creează valoare și unde doar accelerează o greșeală.
Ultima lecție este cea care a pornit întreaga afacere. Avantajul provine din identificarea unei subevaluări înainte ca ceilalți să o facă. Cred că subevaluarea actuală este că majoritatea companiilor văd agenții AI ca pe o modalitate de a reduce costurile de suport. La Satisfi Labs, îi considerăm un canal de venituri. La sălile noastre sportive, aproximativ 40% din conversațiile cu agenții se referă la bilete. Acești fani nu vin să se plângă. Vin cu bani în mână, întrebând unde să stea. Găsește ceea ce piața a evaluat greșit și capturează-l. Același instinct ca în afacerea de arbitraj.
Satisfi Labs a fost fondată în 2017, mult înainte de actualul boom al AI generativ, și a evoluat de la procesarea contextuală a limbajului natural și AI conversațional la o platformă agentică. Care au fost cele mai mari schimbări arhitecturale necesare pentru a trece de la sisteme concepute în principal pentru a răspunde la întrebări la agenți capabili să efectueze acțiuni în numele utilizatorilor?
Am petrecut un deceniu construind mii de agenți AI pentru peste 800 de clienți enterprise, inclusiv echipe MLB/NFL, săli de divertisment și organizații de turism. Cea mai mare schimbare este că oferi sistemului autoritate, nu doar informație.
Dacă un asistent îți spune ce bilete sunt disponibile, oferă un răspuns. Dacă îți schimbă biletele, modifică inventarul, înregistrările clienților și, eventual, banii. Acum trebuie să știi cine a autorizat acțiunea, ce s-a întâmplat cu adevărat și cum să recuperezi situația dacă procesul se oprește la jumătate.
Așadar separăm judecata modelului de autoritatea de a executa. Modelul poate interpreta o cerere și propune următorul pas. Sistemele de dedesubt impun permisiuni, reguli de afaceri și limite de tranzacție. O explicație convingătoare din partea modelului nu poate ocoli aceste controale.
De asemenea, ai nevoie de o distincție clară între “agentul a declarat că a finalizat sarcina” și “sistemul de afaceri a confirmat finalizarea”. Acestea nu sunt același lucru. Dacă o cerere de achiziție expiră, ar fi bine să afli dacă achiziția a avut loc înainte de a încerca din nou.
Și strategic, modelele mai bune nu ar trebui să vă oblige să reconstruiți controalele de afaceri. Vreau să profit de fiecare îmbunătățire a raționamentului fără a renegocia ce este permis sistemului de fiecare dată când apare un model nou.
Termenul „agentic AI” este acum aplicat la o gamă largă de produse. Din perspectiva ingineriei, unde trasaţi linia între un chatbot avansat, un copilot AI și un agent AI cu adevărat autonom?
Aș pune o singură întrebare: ce responsabilitate a delegat efectiv persoana?
Un chatbot furnizează informații. Un copilot vă ajută să finalizaţi munca, dar continuaţi să direcționaţi și să aprobaţi pașii importanți. Un agent autonom are permisiunea să ia unele dintre acele decizii în mod independent în timp ce urmărește un obiectiv.
Interfața nu vă indică care dintre ele este afișată. Un produs conversațional poate avea autonomie reală în spate. Ceva promovat ca agent poate totuși să necesite aprobarea unei persoane pentru fiecare acțiune utilă.
Pentru o întreprindere, autonomia ar trebui să fie un acord specific: acest sistem poate efectua aceste acțiuni, pentru acești utilizatori, în cadrul acestor limite și trebuie să se oprească în aceste condiții. Este ceva ce puteți testa și guverna efectiv.
De asemenea, nu aș pune autonomia maximă ca scop. Uneori, cel mai bun produs pune o singură întrebare bine sincronizată și se ocupă de restul. Eliminarea acelei întrebări face demonstrația mai impresionantă, dar afacerea mai puțin sigură. Obiectivul este să eliminăm munca umană inutilă, nu judecata umană necesară.
Satisfi Labs a lansat recent Satisfi Forward, o practică de inginerie desfășurată în avans. Ce lacună aţi observat între construirea unei platforme AI capabile și punerea în funcţiune a agenţilor în mod fiabil în mediul real al clientului, care v‑a determinat să creaţi acest model?
Ultimul pas devenea blocajul. O platformă poate standardiza multe, dar nu poate presupune că afacerea fiecărui client funcționează în același mod. Sistemul lor de ticketing are anumite limitări. Procesul lor de aprobare trece prin trei departamente. Definiția lor a unui lead calificat diferă de cea a următorului client. Aceste detalii decid dacă implementarea este cu adevărat utilă.
Poţi achiziționa o platformă gata de utilizare și să creezi o demonstrație care impresionează oamenii. Comercializarea ei ca o experiență robustă pentru utilizatori reali este altceva. Aici intervin inginerii desfășurați în avans. Sarcina echipei noastre de la Satisfi Forward este să înțeleagă rezultatul, să identifice ce îl blochează și să construiască fluxurile de lucru și integrările pe platformă care îl realizează.
Totuși, stabilim limite clare pentru fiecare angajament. Înainte de a construi, convenim ce înseamnă succesul, cine deține procesul de afaceri, ce depinde de client și cine îl menține după lansare. În caz contrar, un proiect de ultim pas devine o obligație nelimitată. Și angajamentul nu se încheie când codul este livrat. Se încheie când fluxul de lucru funcționează în operațiunile clientului și cineva este responsabil să îl mențină în funcțiune.
Codul a devenit, de asemenea, mult mai ieftin de produs, ceea ce face acest model mult mai practic decât era înainte. Dar nu văd Satisfi Forward ca pe un braț de servicii atașat unui produs SaaS. Fiecare angajament ne învață ce ar trebui să fie următorul produs. Când trei clienți solicită același flux de lucru, nu este o povară de suport. Este harta de parcurs care se scrie singură, cu clienți plătitori atașați. Vechiul model SaaS ghici caracteristicile și aștepta dovezi. În acest fel obținem dovezile mai întâi și veniturile în timp ce le colectăm. Cred că așa se construiesc companiile de produse în era AI.
Agenții dumneavoastră pot să se conecteze la sisteme de ticketing, platforme de gestionare a relațiilor cu clienții, sisteme de management al conținutului și alte surse de informații în timp real. Pe măsură ce agenții dobândesc capacitatea de a tranzacționa și de a declanșa acțiuni, cum echilibrați accesul la date în timp real și latența scăzută cu fundamentarea, securitatea și măsurile de protecție împotriva acțiunilor incorecte?
În primul rând, nu aș permite niciodată ca viteza să compenseze o deficiență de securitate. Unele cerințe sunt constrângeri. Optimizați în cadrul lor.
Apoi diferențiați tipurile de muncă. Răspunsul la o întrebare despre parcare și finalizarea unei achiziții de bilete nu necesită aceeași actualitate a datelor sau aceleași controale. Puteți memora informațiile stabile în cache. Când banii trec din mână în mână, aveți nevoie de sistemul de tranzacții autoritar pentru a confirma prețul, disponibilitatea și finalizarea.
Cazurile periculoase sunt cele în care sistemul nu știe ce s-a întâmplat. Un backend acceptă o achiziție, dar răspunsul nu ajunge niciodată. Dacă agentul presupune un eșec și încearcă din nou, veți avea două achiziții. Nu este o problemă de limbaj. Este o problemă de recuperare a tranzacțiilor.
Și măsurați experiența în condițiile care contează cu adevărat. Latența medie într-o zi liniștită de marți nu vă spune aproape nimic. Dacă un eveniment este anulat din cauza ploii, veți avea brusc mii de persoane care întreabă ce se întâmplă cu biletele lor, toate în același timp. Dacă planificați doar pe baza traficului mediu pe minut, veți pierde capacitatea necesară în acel vârf. Am învățat asta direct de la sistemele de tranzacționare.
Există și o decizie de cost aici. Nu fiecare cerere necesită cel mai scump model sau un lanț de agenți. Folosiți calea cea mai simplă care îndeplinește cerința și alocați timpul sau calculul suplimentar acolo unde îmbunătățește în mod semnificativ decizia. Utilizatorul ar trebui să primească un rezultat onest, inclusiv o declarație sinceră că ceva nu a putut fi confirmat.
Satisfi Labs descrie un model în care agenții specializați pot opera împreună ca o forță de muncă AI. Care sunt cele mai dificile probleme tehnice implicate în orchestrarea mai multor agenți specializați, în special legate de rutare, context partajat, decizii conflictuale și determinarea agenței care ar trebui să acționeze?
Cea mai grea parte este menținerea responsabilității pe măsură ce distribui munca.
Începeți prin a întreba dacă aveți nevoie de un alt agent. Uneori aveți nevoie de un specialist. Alteori aveți nevoie doar de un apel de instrument sau de un flux de lucru simplu. Fiecare agent pe care îl adăugați reprezintă o altă interpretare a cererii, o altă dependență, un alt loc pentru o eroare. Iar numărul de agenți care rulează în fundal ar trebui să fie invizibil pentru utilizator.
Când mai mulți agenți sunt justificați, vreau ca un singur agent să dețină interacțiunea. Specialiștii pot furniza informații sau pot efectua lucrări delimitate. Un agent de ticketing se ocupă de inventar și schimburi, un agent de servicii clienți se ocupă de politici. Dar cineva trebuie să reconcilieze rezultatele și să decidă dacă utilizatorul a primit cu adevărat ceea ce și-a dorit.
Rutarea este dificilă deoarece oamenii nu pun întrebări în categorii clare. O cerere poate implica trei agenți. Sistemul trebuie să decidă: poate un singur agent să o gestioneze, trebuie să ruleze mai mulți în secvență sau ar trebui să pună utilizatorului încă o întrebare înainte de a face orice.
La fel și cu contextul. Nu trimiteți totul fiecărui agent. Acest lucru adaugă latență, creează zgomot și poate expune informații de care un agent nu are nevoie. Iar presupunerea unui agent nu ar trebui să devină un fapt doar pentru că a fost transmisă agentului următor.
Dacă doi agenți sunt în dezacord, nu vreau să se certe până când unul pare mai convingător. Trebuie să existe un model clar de autoritate. Sistemul de ticketing stabilește disponibilitatea. Afacerea stabilește politica de schimb. Datele în timp real depășesc datele în cache, regulile de business depășesc judecata modelului și, dacă tot nu se poate rezolva, întrebi utilizatorul sau aduci o persoană. Partea dificilă nu este să faci agenții să comunice între ei, ci să poți reconstrui exact ce agent a făcut ce și unde a căzut responsabilitatea.
Satisfi Labs s-a concentrat tot mai mult pe măsurarea agenților în raport cu obiectivele și rezultatele de business, mai degrabă decât cu metrici precum volumul de conversații. Ce ar trebui să măsoare efectiv întreprinderile pentru a determina dacă un agent AI performează bine și cum evaluați fiabilitatea înainte de a permite unui agent o autonomie mai mare?
Începeți cu rezultatul de business, apoi întrebați cât din acel rezultat a fost cauzat efectiv de agent.
Dacă cineva cumpără bilete după ce a vorbit cu un agent, asta nu înseamnă automat că agentul a generat vânzarea. Este posibil să fi cumpărat oricum. Unde puteți, doriți comparații controlate sau o bază de referință credibilă, nu doar credit pentru ultima interacțiune. Pentru un client de ticketing, asta înseamnă să măsurați dacă fanul a obținut locuri, nu dacă agentul a răspuns politicos. Pentru o locație care încearcă să reducă cozile la casa de bilete, înseamnă să măsurați ce a rezolvat agentul înainte ca cineva să fie nevoit să stea la coadă.
Apoi analizați economia unui rezultat de succes: costurile modelului, infrastructura, revizuirea umană, escaladările și costul corectării greșelilor. Un agent care pare ieftin până când numărați persoanele care repară munca lui nu este ieftin.
Fiabilitatea are nevoie de propriul său tabel de scoruri. Finalizare, corectitudine, acțiuni neautorizate, recuperare din eșecuri, calitatea escaladărilor. Nu mediați un incident grav de confidențialitate într-un rată bună de conversie.
Pentru o autonomie sporită, aș cere dovezi privind clasa specifică de acțiune delegată. Testați-o, monitorizați-o sub supraveghere, extindeți-o în limite și păstrați o modalitate de a o opri. Un scor bun de acuratețe generală nu dovedește că sistemul este pregătit pentru fiecare tranzacție. Și fiți atenți la stimulente. Uneori, implicarea unei persoane este rezultatul corect. Dacă recompensați agentul doar pentru evitarea transferurilor, nu fiți surprinși când păstrează problemele pe care ar fi trebuit să le escaladeze.
Recent ați susținut că AI-ul vocal trebuie conceput în jurul rezultatelor măsurabile, nu tratat ca o altă interfață pentru un chatbot existent. Ce inovații tehnice sunt încă necesare înainte ca agenții vocali să poată deveni o interfață principală pentru interacțiuni complexe, în timp real, în special în medii precum stadioane, atracții și evenimente live?
Mulți clienți întreabă dacă pot lua aplicația de chat și să adauge vocea în ea. Putem. Dar asta nu înseamnă că va fi o experiență bună. Următoarea îmbunătățire reală nu este o voce care să sune mai uman. Este o interacțiune care supraviețuiește condițiilor în care oamenii o folosesc efectiv.
Într-un stadion, cineva vorbește peste zgomotul mulțimii, folosește un nume de jucător necunoscut, își schimbă opinia la jumătatea unei fraze și încearcă să finalizeze o achiziție înainte ca porțile să se deschidă. Sistemul trebuie să gestioneze întreruperile, incertitudinea și întârzierile din backend fără a pierde sarcina.
Acordați o atenție deosebită detaliilor critice. A înțelege greșit o expresie casuală este un lucru. A înțelege greșit numărul de bilete sau data evenimentului este altceva. Agentul trebuie să confirme detaliile care schimbă consecința acțiunii fără a face întreaga conversație plictisitoare.
Și vocea nu ar trebui forțată să facă totul. Compararea a douăzeci de opțiuni de locuri este mai bine pe un ecran. Cineva ar putea începe să tasteze, să intre în mașină și să vrea să continue aceeași conversație vorbind. Sistemul ar trebui să păstreze acel context și să folosească vocea, textul și elementele vizuale în funcție de ce se potrivește cel mai bine în acel moment.
Unele dintre acestea necesită modele mai bune. Multe dintre ele au nevoie de o integrare și un design de interacțiune mai bune. Așteptarea unui progres brusc nu va rezolva un flux de lucru conceput în jurul textului și apoi citit cu voce tare. Aș evalua progresul astfel: oamenii finalizează sarcina cu acuratețe, cu mai puțin efort, în condiții reale?
Pe măsură ce agenții trec de la furnizarea de informații la vânzarea de bilete, colectarea de date ale clienților, personalizarea experiențelor și interacțiunea cu sistemele operaționale, cum ar trebui companiile să determine ce decizii poate lua un agent autonom și care ar trebui să necesite întotdeauna supraveghere umană?
Este vorba de gestionarea riscurilor. Dacă lucrurile merg prost, ce pagube poate provoca? Deschide agentul o ușă pe care nu o poate închide?
Reversibilitatea este un prim test util, dar trebuie să se ia în considerare și expunerea totală. O rambursare poate fi mică și reversibilă. Zece mii de rambursări incorecte înainte ca cineva să observe reprezintă o problemă diferită. Aveți nevoie de limite pentru acțiunile individuale și pentru activitatea cumulativă a sistemului.
Dacă acțiunea este cu risc scăzut și reversibilă, oferiți-i mai multă autonomie: actualizați o preferință, verificați o comandă, rețineți un articol. Pe măsură ce consecințele cresc, adăugați confirmare sau aprobare. O achiziție ar putea necesita ca clientul să confirme prețul. O rambursare mare ar putea necesita aprobarea unui angajat. O amenințare de siguranță este escaladată imediat. Și unele decizii ar trebui să rămână exclusiv la o persoană, punct.
Consimțământul clientului și aprobarea companiei sunt lucruri diferite, apropo. Un client care confirmă o achiziție nu autorizează agentul să încalce politica companiei. Un angajat care aprobă o excepție nu înseamnă că clientul a fost de acord cu o taxă.
Limitele trebuie impuse de sistemele care execută acțiunea, nu doar descrise într-un prompt. Nu îi oferiți unui agent acces larg și apoi vă bazați pe un prompt care îi spune să fie precaut. Și când este necesară o persoană, oferiți-i suficient context pentru a lua o decizie reală. Dacă oferiți cuiva sute de aprobări fără informații, ați creat un timbru de cauciuc, nu supraveghere. Direcționați atenția umană acolo unde reduce riscuri semnificative. Nu o dispersați la fiecare interacțiune.
Privind spre viitor, așteptați ca tehnologii precum Model Context Protocol și comunicarea agent‑la‑agent să schimbe fundamental modul în care sunt construite sistemele AI enterprise, trecând de la agenți izolați la ecosisteme în care agenții pot descoperi instrumente, schimba context și coordona acțiuni între companii și platforme?
Cred că protocoalele sunt un mijloc spre un scop. MCP oferă aplicațiilor AI o modalitate comună de a accesa instrumente și context. Protocoalele agent‑la‑agent gestionează cooperarea între agenți. Este valoros. Nu ar trebui să fie nevoie să construiți o integrare personalizată de fiecare dată când un agent are nevoie de un instrument. Este similar cu ceea ce au făcut API‑urile pentru integrările software.
Însă un format comun nu înseamnă că două afaceri sunt de acord asupra semnificației unei acțiuni, cine o poate autoriza sau ce se întâmplă când eșuează. Doar pentru că un agent poate descoperi un instrument nu înseamnă că ar trebui să îl poată folosi. Trebuie totuși să rezolvați identitatea, permisiunile, încrederea, responsabilitatea. Dacă un agent cere altuia să facă ceva și rezultatul este greșit, cine deține acea decizie?
Iată ce cred eu că se schimbă cu adevărat. Astăzi, un loc are un site web și o aplicație. În câțiva ani, va avea un agent cu care alți agenți negociază. Asistentul personal al unui fan solicită agentului locației două locuri la un anumit preț, plus un permis de parcare, iar întreaga tranzacție are loc între cei doi agenți. Găsirea capabilităților potrivite este pasul ușor. Cunoașterea autorității de cheltuieli a clientului, confirmarea prețului combinat și gestionarea cazului în care biletele sunt confirmate, dar parcarea eșuează, acestea sunt problemele reale.
Și nu cred că operarea unui agent conferă automat relația cu clientul. Aceasta trebuie câștigată. Dar nu cred nici că locațiile vor preda aceste tranzacții unei companii de căutare sau unei piețe de bilete. Scopul nostru la Satisfi Labs este să fim agentul care reprezintă locația în acea economie, cel suficient de de încredere încât o afacere să își pună numele pe el. Tot ce am construit în jurul fiabilității, permisiunilor și responsabilității este ceea ce ne asigură acest loc.
Vă mulțumim pentru interviul excelent, cititorii care doresc să afle mai multe ar trebui să viziteze Satisfi Labs.












