Randall Newman, CPTO e cofondatore di Satisfi Labs – Serie di interviste

Randall Newman, CPTO e cofondatore di Satisfi Labs, è un leader tecnologico e di prodotto con una vasta esperienza nella costruzione di piattaforme AI, tecnologia finanziaria e sistemi ad alte prestazioni. Da quando ha cofondato Satisfi Labs, Newman ha svolto un ruolo centrale nella concezione, progettazione e scalabilità della tecnologia di AI conversazionale dell’azienda, supervisionando lo sviluppo del prodotto, l’architettura, i team di ingegneria e le integrazioni strategiche. Prima di Satisfi Labs, è stato Head of Product presso Satisfi Inc. e ha cofondato la società di mobile marketing Right On Mobile. Nelle prime fasi della sua carriera, Newman ha trascorso più di 17 anni presso CIBC World Markets, dove ha ricoperto ruoli di senior leadership in ambiti che spaziavano dal rischio strategico al trading ad alta frequenza e all’arbitraggio azionario, combinando competenze di trading quantitativo con lo sviluppo pratico di tecnologie.

Satisfi Labs è un’azienda AI focalizzata sul dispiegamento di agenti AI specializzati per sport, intrattenimento, turismo, attrazioni e altre attività basate su esperienze dal vivo. Fondata nel 2016, l’azienda è passata dall’AI conversazionale e dal suo Answer Engine a una piattaforma agentica progettata per aiutare le organizzazioni ad automatizzare il supporto agli ospiti, aumentare le conversioni di biglietti e commercio, e ricavare insight dalle conversazioni con i clienti. I suoi agenti AI possono operare in più di 50 lingue e connettersi a sistemi di ticketing, CRM, gestione dei contenuti e altri sistemi aziendali per eseguire azioni come la vendita di biglietti, l’escalation delle conversazioni al personale umano, la raccolta di informazioni sui clienti e la fornitura di risposte personalizzate. Satisfi Labs afferma che la sua tecnologia è ora affidata da oltre 775 brand, con integrazioni e partnership che includono aziende come Ticketmaster, Simpleview, MappedIn, Ventrata e Vozzi.

Hai trascorso quasi due decenni nei mercati finanziari, includendo la costruzione di sistemi di trading a bassa latenza e la guida di strategie di trading ad alta frequenza presso CIBC, prima di passare all’imprenditoria tecnologica e infine cofondare Satisfi Labs. Quali lezioni provenienti da sistemi operativi in cui velocità, affidabilità e gestione del rischio erano fondamentali hanno influenzato maggiormente il modo in cui costruisci oggi agenti AI di livello produttivo?

Il trading mi ha insegnato che un’idea valida e un buon business sono due cose diverse. Puoi individuare correttamente un’opportunità e comunque perdere denaro perché la tua esecuzione è lenta, i costi sono troppo alti o le ipotesi di rischio sono errate. L’AI è la stessa. La capacità del modello è un input. Il business dipende dal fatto se riesci a trasformare quella capacità in un risultato ripetibile a un costo e rischio accettabili.

Gestire un libro di arbitraggio su indici insegna anche a guardare oltre le decisioni individuali. Un piccolo errore ripetuto su un portafoglio diventa una esposizione molto ampia. Con l’AI, puoi avere migliaia di agenti che prendono decisioni ragionevoli singolarmente ma che collettivamente creano un problema. Tutti dipendono dagli stessi dati errati, o tutti ritentano lo stesso servizio difettoso. Devi gestire il sistema, non solo la risposta individuale.

E la velocità conta solo quando migliora il risultato. Nel trading ci sono stati momenti in cui i microsecondi erano decisivi. Nell’AI, preferisco spendere un secondo in più a confermare una transazione piuttosto che fornire immediatamente un risultato errato. La disciplina consiste nel sapere dove la velocità genera valore e dove invece accelera semplicemente un errore.

L’ultima lezione è quella che ha avviato l’intera attività. Il vantaggio deriva dal rilevare una sottoquotazione prima di chiunque altro. Credo che la sottoquotazione attuale sia che la maggior parte delle aziende consideri gli agenti AI come un modo per ridurre i costi di supporto. In Satisfi Labs, li vediamo come un canale di fatturato. Nei nostri impianti sportivi, circa il 40 % delle conversazioni degli agenti riguarda i biglietti. Questi fan non vengono a lamentarsi. Arrivano con i soldi in mano, chiedendo dove sedersi. Trova ciò che il mercato ha valutato in modo errato e catturalo. È lo stesso istinto del business dell’arbitraggio.

Satisfi Labs è stata fondata nel 2017, molto prima dell’attuale boom dell’AI generativa, ed è passata dall’elaborazione contestuale del linguaggio naturale e dall’AI conversazionale a una piattaforma agentica. Quali sono stati i più grandi cambiamenti architettonici necessari per passare da sistemi progettati principalmente per rispondere a domande a agenti capaci di compiere azioni per conto degli utenti?

Abbiamo trascorso un decennio a costruire migliaia di agenti AI per oltre 800 clienti enterprise, inclusi team MLB/NFL, sedi di intrattenimento e organizzazioni turistiche. Il cambiamento più importante è che stai conferendo al sistema l’autorità, non solo l’informazione.

Se un assistente ti indica quali biglietti sono disponibili, sta fornendo una risposta. Se scambia i tuoi biglietti, sta modificando l’inventario, i record dei clienti e potenzialmente il denaro. Ora devi sapere chi ha autorizzato l’azione, cosa è realmente accaduto e come recuperare se il processo si interrompe a metà.

Quindi separiamo il giudizio del modello dall’autorità di eseguire. Il modello può interpretare una richiesta e proporre il passo successivo. I sistemi sottostanti applicano permessi, regole di business e limiti di transazione. Una spiegazione persuasiva del modello non può sovrascrivere tali controlli.

Hai inoltre bisogno di una netta distinzione tra “l’agente ha detto di aver completato il compito” e “il sistema aziendale ha confermato il completamento”. Non sono la stessa cosa. Se una richiesta di acquisto scade, è meglio verificare se l’acquisto è avvenuto prima di riprovare.

E strategicamente, i modelli migliori non dovrebbero costringerti a ricostruire i controlli aziendali. Voglio sfruttare ogni miglioramento nel ragionamento senza rinegoziare cosa il sistema è autorizzato a fare ogni volta che viene rilasciato un nuovo modello.

Il termine “agentic AI” è ora applicato a una vasta gamma di prodotti. Da un punto di vista ingegneristico, dove tracci la linea tra un chatbot avanzato, un copilota AI e un vero agente AI autonomo?

Farei una sola domanda: quale responsabilità ha effettivamente delegato la persona?

Un chatbot fornisce informazioni. Un copilota ti aiuta a svolgere il lavoro, ma sei ancora tu a dirigere e approvare i passaggi importanti. Un agente autonomo ha il permesso di prendere alcune di quelle decisioni da solo mentre persegue un obiettivo.

L’interfaccia non ti dice quale dei tre stai osservando. Un prodotto conversazionale può avere una reale autonomia dietro di sé. Qualcosa commercializzato come agente può comunque richiedere che una persona approvi ogni azione utile.

Per un’azienda, l’autonomia dovrebbe essere un accordo specifico: questo sistema può eseguire queste azioni, per questi utenti, entro questi limiti, e deve fermarsi in queste condizioni. È qualcosa che puoi effettivamente testare e governare.

Io non renderei nemmeno la massima autonomia l’obiettivo. A volte il miglior prodotto pone una domanda ben cronometrata e gestisce il resto. Rimuovere quella domanda rende la demo più impressionante e l’azienda meno sicura. L’obiettivo è eliminare il lavoro umano non necessario, non il giudizio umano necessario.

Satisfi Labs ha recentemente lanciato Satisfi Forward, una pratica di ingegneria forward-deployed. Quale lacuna vedevate tra la costruzione di una piattaforma AI capace e il far funzionare gli agenti in modo affidabile nell’ambiente reale di un cliente, che vi ha spinto a creare questo modello?

L’ultimo miglio stava diventando il collo di bottiglia. Una piattaforma può standardizzare molto, ma non può presumere che il business di ogni cliente funzioni allo stesso modo. Il loro sistema di ticketing ha certe limitazioni. Il loro processo di approvazione passa attraverso tre dipartimenti. La loro definizione di lead qualificato è diversa da quella del cliente successivo. Quei dettagli decidono se il deployment è realmente utile.

Puoi acquistare una piattaforma pronta all’uso e assemblare una demo che impressiona le persone. Commercializzarla come un’esperienza robusta per utenti reali è un’altra cosa. È qui che entrano in gioco gli ingegneri forward-deployed. Il nostro team di Satisfi Forward ha il compito di capire il risultato desiderato, individuare cosa lo blocca e costruire i flussi di lavoro e le integrazioni sulla piattaforma che lo rendono possibile.

Ma poniamo limiti chiari attorno a ogni impegno. Prima di costruire, concordiamo cosa significhi il successo, chi possiede il processo aziendale, cosa dipende dal cliente e chi lo mantiene dopo il lancio. Altrimenti un progetto di ultimo miglio diventa un obbligo illimitato. E l’impegno non termina quando il codice viene consegnato. Termina quando il flusso di lavoro funziona nell’operazione del cliente e qualcuno è responsabile di mantenerlo attivo.

Il codice è diventato molto più economico da produrre, il che rende questo modello molto più pratico rispetto al passato. Però non considero Satisfi Forward come un braccio di servizi agganciato a un prodotto SaaS. Ogni impegno ci insegna quale dovrebbe essere il prossimo prodotto. Quando tre clienti chiedono lo stesso flusso di lavoro, non è un onere di supporto. È la roadmap che si scrive da sé, con clienti paganti allegati. Il vecchio modello SaaS indovinava le funzionalità e aspettava le evidenze. In questo modo otteniamo prima le evidenze e il fatturato mentre le raccogliamo. Credo che sia così che le aziende di prodotto si costruiscano nell’era dell’AI.

I vostri agenti possono connettersi a sistemi di ticketing, piattaforme di gestione delle relazioni con i clienti, sistemi di gestione dei contenuti e altre fonti di informazioni in tempo reale. Man mano che gli agenti acquisiscono la capacità di effettuare transazioni e attivare azioni, come bilanciate l’accesso ai dati in tempo reale e la bassa latenza con il grounding, la sicurezza e le salvaguardie contro azioni errate?

Prima di tutto, non lascerei mai che la velocità compensi un fallimento di sicurezza. Alcuni requisiti sono vincoli. Ottimizzi all’interno di essi.

Poi distingui tra i tipi di lavoro. Rispondere a una domanda sul parcheggio e completare l’acquisto di un biglietto non richiedono la stessa freschezza dei dati né gli stessi controlli. Puoi memorizzare nella cache informazioni stabili. Quando cambiano le mani dei soldi, hai bisogno del sistema di transazione autoritario per confermare prezzo, disponibilità e completamento.

I casi pericolosi sono quelli in cui il sistema non sa cosa è successo. Un backend accetta un acquisto, ma la risposta non arriva mai. Se l’agente presume un fallimento e riprova, hai due acquisti. Non è un problema di linguaggio. È un problema di recupero della transazione.

E misuri l’esperienza nelle condizioni che contano davvero. La latenza media in un tranquillo martedì ti dice quasi nulla. Se un evento viene annullato per pioggia, improvvisamente migliaia di persone chiedono cosa succede ai loro biglietti, tutte insieme. Se pianifichi solo in base al traffico medio per minuto, perderai la capacità necessaria in quel picco. L’ho imparato direttamente dai sistemi di trading.

C’è anche una decisione di costo. Non tutte le richieste necessitano del modello più costoso o di una catena di agenti. Usa il percorso più semplice che soddisfi il requisito e impiega tempo o calcolo aggiuntivo solo dove ciò migliori materialmente la decisione. L’utente dovrebbe ottenere un risultato onesto, includendo una dichiarazione onesta che qualcosa non possa essere confermato.

Satisfi Labs descrive un modello in cui agenti specializzati possono operare insieme come una forza lavoro AI. Quali sono i problemi tecnici più difficili coinvolti nell’orchestrare più agenti specializzati, in particolare per quanto riguarda il routing, il contesto condiviso, le decisioni conflittuali e la determinazione di quale agente dovrebbe agire?

La parte più difficile è mantenere la responsabilità mentre distribuisci il lavoro.

Inizia chiedendoti se ti serve davvero un altro agente. A volte hai bisogno di uno specialista. A volte ti basta una chiamata a uno strumento o un semplice flusso di lavoro. Ogni agente che aggiungi è un’ulteriore interpretazione della richiesta, un’ulteriore dipendenza, un ulteriore punto di errore. E il numero di agenti che operano dietro le quinte dovrebbe essere invisibile all’utente.

Quando più agenti sono giustificati, desidero che un solo agente gestisca l’interazione. Gli specialisti possono fornire informazioni o svolgere lavori limitati. Un agente di biglietteria gestisce l’inventario e gli scambi, un agente di assistenza clienti gestisce le politiche. Ma qualcuno deve riconciliare i risultati e decidere se l’utente ha effettivamente ottenuto ciò per cui è venuto.

Il routing è difficile perché le persone non pongono domande in categorie nette. Una richiesta può coinvolgere tre agenti. Il sistema deve decidere: può gestirla un solo agente, ne servono diversi in sequenza, o dovrebbe chiedere all’utente un’ulteriore domanda prima di procedere?

Lo stesso vale per il contesto. Non invii tutto a tutti gli agenti. Questo aggiunge latenza, crea rumore e può esporre informazioni di cui un agente non ha bisogno. Inoltre, l’ipotesi di un agente non dovrebbe diventare un fatto solo perché è stata trasmessa al successivo agente.

Se due agenti sono in disaccordo, non voglio che litigino finché uno non sembra più convincente. Deve esserci un modello di autorità chiaro. Il sistema di biglietteria stabilisce la disponibilità. L’azienda stabilisce la politica di scambio. I dati in tempo reale superano i dati memorizzati, le regole aziendali superano il giudizio del modello, e se ancora non si può risolvere, si chiede all’utente o si coinvolge una persona. La parte difficile non è far parlare gli agenti tra loro. È essere in grado di ricostruire esattamente quale agente ha fatto cosa e dove ricadeva la responsabilità.

Satisfi Labs si è sempre più concentrata sulla misurazione degli agenti rispetto a obiettivi e risultati aziendali piuttosto che a metriche come il volume delle conversazioni. Cosa dovrebbero effettivamente misurare le imprese per determinare se un agente AI sta funzionando bene e come valutare l’affidabilità prima di concedere a un agente maggiore autonomia?

Inizia dal risultato aziendale, poi chiediti quanto di quel risultato sia stato effettivamente generato dall’agente.

Se qualcuno acquista biglietti dopo aver parlato con un agente, ciò non significa automaticamente che l’agente abbia generato la vendita. Potrebbero aver acquistato comunque. Dove possibile, è preferibile avere confronti controllati o una baseline credibile, non solo attribuire il merito all’ultima interazione. Per un cliente di biglietteria, ciò significa misurare se il fan ha effettivamente ottenuto i posti, non se l’agente ha risposto in modo cortese. Per una sede che cerca di ridurre le code alla biglietteria, significa misurare ciò che l’agente ha risolto prima che qualcuno dovesse mettersi in fila.

Poi esamina l’economia di un risultato positivo: costi del modello, infrastruttura, revisione umana, escalation e il costo di correggere gli errori. Un agente che sembra economico finché non si contano le persone che riparano il suo lavoro non è economico.

L’affidabilità necessita di una propria scheda di valutazione. Completamento, correttezza, azioni non autorizzate, recupero da guasti, qualità delle escalation. Non si può mediare un grave incidente sulla privacy in un buon tasso di conversione.

Per una maggiore autonomia, richiederei prove sulla specifica classe di azione delegata. Testala, osservala sotto supervisione, espandila entro limiti e mantieni un modo per fermarla. Un buon punteggio di accuratezza complessiva non dimostra che il sistema sia pronto per ogni transazione. E fai attenzione agli incentivi. A volte coinvolgere una persona è l’esito corretto. Se premi l’agente solo per evitare i passaggi, non sorprenderti se trattiene problemi che avrebbe dovuto escalare.

Hai recentemente sostenuto che l’IA vocale deve essere progettata attorno a risultati misurabili piuttosto che trattata come un’ulteriore interfaccia per un chatbot esistente. Quali innovazioni tecniche sono ancora necessarie prima che gli agenti vocali possano diventare un’interfaccia primaria per interazioni complesse e in tempo reale, in particolare in ambienti come stadi, attrazioni e eventi dal vivo?

Molti clienti chiedono: è possibile prendere l’applicazione di chat e collegarvi la voce? Possiamo farlo. Ma ciò non significa che l’esperienza sarà buona. Il prossimo vero miglioramento non è una voce più simile a quella umana. È un’interazione che sopravvive alle condizioni in cui le persone la usano realmente.

In uno stadio, qualcuno parla sopra il rumore della folla, usa un nome di giocatore sconosciuto, cambia idea a metà frase e cerca di completare un acquisto prima che i cancelli si aprano. Il sistema deve gestire interruzioni, incertezze e ritardi del backend senza perdere il compito.

Prestate particolare attenzione ai dettagli critici. Capire male una frase informale è una cosa. Capire male il numero di biglietti o la data dell’evento è un’altra. L’agente deve confermare i dettagli che modificano la conseguenza dell’azione senza rendere l’intera conversazione noiosa.

E la voce non dovrebbe essere costretta a fare tutto. Confrontare venti opzioni di posti a sedere è più efficace su uno schermo. Qualcuno potrebbe iniziare digitando, entrare in macchina e voler continuare la stessa conversazione parlando. Il sistema dovrebbe preservare quel contesto e utilizzare voce, testo e elementi visivi in base a ciò che meglio si adatta al momento.

Alcune di queste cose hanno bisogno di modelli migliori. Molte richiedono una migliore integrazione e progettazione dell’interazione. Aspettare una svolta non risolverà un flusso di lavoro progettato attorno al testo e poi letto ad alta voce. Valuterei i progressi in questo modo: le persone completano il compito in modo accurato, con meno sforzo, in condizioni reali?

Man mano che gli agenti passano dal fornire informazioni alla vendita di biglietti, alla raccolta dei dati dei clienti, alla personalizzazione delle esperienze e all’interazione con i sistemi operativi, come dovrebbero le aziende determinare quali decisioni un agente può prendere autonomamente e quali dovrebbero sempre richiedere la supervisione umana?

È gestione del rischio. Se ciò va storto, che danni può provocare? L’agente apre una porta che non può chiudere?

La reversibilità è un utile primo test, ma bisogna considerare anche l’esposizione totale. Un rimborso può essere piccolo e reversibile. Diecimila rimborsi errati prima che qualcuno se ne accorga è un problema diverso. Servono limiti sulle azioni individuali e sull’attività cumulativa del sistema.

Se l’azione è a basso rischio e reversibile, concedile più autonomia: aggiornare una preferenza, verificare un ordine, trattenere un articolo. Man mano che le conseguenze aumentano, aggiungi una conferma o un’approvazione. Un acquisto potrebbe richiedere che il cliente confermi il prezzo. Un grande rimborso potrebbe necessitare l’approvazione di un dipendente. Una minaccia alla sicurezza viene segnalata immediatamente. E alcune decisioni dovrebbero rimanere esclusivamente a carico di una persona, punto.

Il consenso del cliente e l’approvazione dell’azienda sono cose diverse, tra l’altro. Un cliente che conferma un acquisto non autorizza l’agente a aggirare la politica aziendale. Un dipendente che approva un’eccezione non significa che il cliente abbia accettato una spesa.

I limiti devono essere applicati dai sistemi che eseguono l’azione, non solo descritti in un prompt. Non si concede a un agente un accesso ampio per poi affidarsi a un prompt che gli dice di stare attento. E quando è necessaria una persona, fornisci a questa abbastanza contesto per prendere una decisione reale. Dare a qualcuno centinaia di approvazioni senza informazioni significa creare un timbro di gomma, non una supervisione. Concentrate l’attenzione umana dove riduce rischi significativi. Non disperdetela su ogni interazione.

Guardando al futuro, ti aspetti che tecnologie come il Model Context Protocol e la comunicazione agente‑a‑agente cambino radicalmente il modo in cui i sistemi di IA aziendali vengono costruiti, spostandoci da agenti isolati verso ecosistemi in cui gli agenti possono scoprire strumenti, scambiare contesto e coordinare azioni tra aziende e piattaforme?

Credo che i protocolli siano un mezzo per raggiungere un fine. MCP fornisce alle applicazioni di IA un modo comune per accedere a strumenti e contesto. I protocolli agente‑a‑agente gestiscono la cooperazione tra agenti. È prezioso. Non dovresti dover costruire un’integrazione personalizzata ogni volta che un agente ha bisogno di uno strumento. È simile a ciò che le API hanno fatto per le integrazioni software.

Ma un formato comune non significa che due aziende concordino su cosa significhi un’azione, chi possa autorizzarla o cosa accada in caso di fallimento. Solo perché un agente può scoprire uno strumento non significa che debba essere autorizzato a usarlo. Devi comunque definire identità, permessi, fiducia e responsabilità. Se un agente chiede a un altro di fare qualcosa e qualcosa va storto, chi è responsabile di quella decisione?

Ecco quello che penso cambi davvero. Oggi, un locale ha un sito web e un’app. Tra qualche anno avrà un agente con cui altri agenti negozieranno. L’assistente personale di un fan chiede all’agente del locale due posti a un certo prezzo, più un pass per il parcheggio, e l’intera transazione avviene tra i due agenti. Trovare le capacità giuste è la parte facile. Conoscere l’autorità di spesa del cliente, confermare il prezzo complessivo e gestire il caso in cui i biglietti vengano confermati ma il parcheggio fallisca, sono i veri problemi.

E non credo che gestire un agente ti consegni automaticamente la relazione con il cliente. Questo deve essere guadagnato. Ma non credo nemmeno che i locali consegneranno queste transazioni a una società di ricerca o a un marketplace di biglietti. Il nostro obiettivo in Satisfi Labs è essere l’agente che rappresenta il locale in quell’economia, quello sufficientemente affidabile da far sì che un’azienda ne metta il nome. Tutto ciò che abbiamo costruito attorno all’affidabilità, ai permessi e alla responsabilità è ciò che ci guadagna quel posto.

Grazie per la grande intervista, i lettori che desiderano saperne di più dovrebbero visitare Satisfi Labs.