Randall Newman, CPTO och medgrundare av Satisfi Labs – Intervjuserie

Randall Newman, CPTO och medgrundare av Satisfi Labs, är en teknik- och produktledare med omfattande erfarenhet av att bygga AI‑plattformar, finansiell teknik och högpresterande system. Sedan han medgrundade Satisfi Labs har Newman spelat en central roll i att föreställa sig, designa och skala företagets konversations‑AI‑teknik, samtidigt som han har övervakat produktutveckling, arkitektur, ingenjörsteam och strategiska integrationer. Före Satisfi Labs var han Produktchef på Satisfi Inc. och medgrundade mobilmarknadsföringsföretaget Right On Mobile. Tidigare i sin karriär tillbringade Newman mer än 17 år på CIBC World Markets, där han hade seniora ledarroller som omfattade strategisk risk, högfrekvent handel och aktiearbitrage, och kombinerade kvantitativ handelskompetens med praktisk teknikutveckling.

Satisfi Labs är ett AI‑företag som fokuserar på att distribuera specialiserade AI‑agenter för sport, underhållning, turism, attraktioner och andra verksamheter med live‑upplevelser. Företaget grundades 2016 och har utvecklats från konversations‑AI och dess Answer Engine till en agentbaserad plattform som är avsedd att hjälpa organisationer att automatisera gästsupport, öka biljett‑ och handelskonverteringar samt extrahera insikter från kundsamtal. Dess AI‑agenter kan verka på mer än 50 språk och kopplas till biljett‑, CRM‑, innehållshanterings‑ och andra affärssystem för att utföra åtgärder såsom att sälja biljetter, eskalera samtal till mänsklig personal, samla in kundinformation och leverera personliga svar. Satisfi Labs säger att deras teknik nu är betrodd av mer än 775 varumärken, med integrationer och partnerskap som omfattar företag som Ticketmaster, Simpleview, MappedIn, Ventrata och Vozzi.

Du tillbringade nästan två decennier på finansmarknaderna, inklusive att bygga låglatenshandelssystem och leda högfrekventa handelsstrategier på CIBC, innan du gick över till teknikentreprenörskap och så småningom medgrundade Satisfi Labs. Vilka lärdomar från operativsystem där hastighet, tillförlitlighet och riskhantering var avgörande har mest påverkat hur du idag bygger produktionsklara AI‑agenter?

Handel lärde mig att en bra idé och en bra verksamhet är två olika saker. Du kan identifiera en möjlighet korrekt och ändå förlora pengar eftersom din genomförande är långsam, dina kostnader är för höga eller dina riskantaganden är felaktiga. AI är likadant. Modellens kapacitet är en ingång. Verksamheten beror på om du kan omvandla den kapaciteten till ett repeterbart resultat till en acceptabel kostnad och risk.

Att driva en indexarbitrageportfölj lär dig också att se förbi enskilda beslut. Ett litet fel som upprepas över en portfölj blir en mycket stor exponering. Med AI kan du ha tusentals agenter som fattar individuellt rimliga beslut men som tillsammans skapar ett problem. De är alla beroende av samma dåliga data, eller så försöker de alla igen med samma felaktiga tjänst. Du måste hantera systemet, inte bara det enskilda svaret.

Och hastighet spelar bara roll när den förbättrar resultatet. Inom handel fanns det tillfällen då mikrosekunder var avgörande. Inom AI föredrar jag att spendera en sekund extra för att bekräfta en transaktion snarare än att leverera ett felaktigt resultat omedelbart. Disciplinen är att veta var hastigheten skapar värde och var den bara påskyndar ett misstag.

Den sista lärdomen är den som startade hela verksamheten. Fördelen kommer från att upptäcka en felprissättning innan alla andra gör det. Jag tror att felprissättningen just nu är att de flesta företag ser AI‑agenter som ett sätt att minska supportkostnader. På Satisfi Labs ser vi dem som en intäktskanal. På våra sportarenor handlar cirka 40 % av agenternas konversationer om biljetter. Dessa fans kommer inte för att klaga. De kommer med pengar i handen och frågar var de kan sitta. Hitta det som marknaden har prissatt fel och gå och ta det. Samma instinkt som i arbitrage‑verksamheten.

Satisfi Labs grundades 2017, långt före den nuvarande generativa AI‑boomen, och har utvecklats från kontextuell naturlig språkbehandling och konversations‑AI till en agentbaserad plattform. Vilka var de största arkitektoniska förändringarna som krävdes för att gå från system som främst var designade för att svara på frågor till agenter som kan utföra handlingar på uppdrag av användare?

Vi har spenderat ett decennium med att bygga tusentals AI‑agenter för över 800 företagskunder, inklusive MLB/NFL‑lag, underhållningsarenor och turistorganisationer. Den största förändringen är att du ger systemet befogenhet, inte bara information.

Om en assistent berättar vilka biljetter som är tillgängliga ger den ett svar. Om den byter dina biljetter förändrar den lager, kundregister och eventuellt pengar. Nu måste du veta vem som godkände åtgärden, vad som faktiskt hände och hur du återställer om processen avbryts halvvägs.

Så separerar vi modellens bedömning från befogenheten att verkställa. Modellen kan tolka en begäran och föreslå nästa steg. Systemen under den upprätthåller behörigheter, affärsregler och transaktionsgränser. En övertygande förklaring från modellen kan inte åsidosätta dessa kontroller.

Du behöver också en tydlig åtskillnad mellan “agenten sa att den slutförde uppgiften” och “affärssystemet bekräftade slutförandet”. De är inte samma sak. Om en köpförfrågan får timeout bör du först ta reda på om köpet genomfördes innan du försöker igen.

Och strategiskt sett bör bättre modeller inte tvinga dig att bygga om dina affärskontroller. Jag vill dra nytta av varje förbättring i resonemang utan att omförhandla vad systemet får göra varje gång en ny modell lanseras.

Termen “agentic AI” används nu för ett brett spektrum av produkter. Ur ett ingenjörsperspektiv, var drar du gränsen mellan en avancerad chatbot, en AI‑copilot och en verkligt autonom AI‑agent?

Jag skulle ställa en fråga: vilket ansvar har personen faktiskt delegerat?

En chatbot tillhandahåller information. En copilot hjälper dig att utföra arbete, men du styr fortfarande och godkänner de viktiga stegen. En autonom agent har tillåtelse att fatta vissa av dessa beslut själv medan den strävar efter ett mål.

Gränssnittet visar inte vilken du tittar på. En konversationsprodukt kan ha verklig autonomi bakom sig. Något som marknadsförs som en agent kan fortfarande behöva att en person godkänner varje användbar handling.

För ett företag bör autonomi vara ett specifikt avtal: detta system får utföra dessa åtgärder, för dessa användare, inom dessa gränser, och måste stoppa under dessa villkor. Det är något du faktiskt kan testa och styra.

Jag skulle inte heller göra maximal autonomi till målet. Ibland ställer den bästa produkten en väl tajmad fråga och hanterar resten. Att ta bort den frågan gör demonstrationen mer imponerande men affären mindre säker. Målet är att eliminera onödigt mänskligt arbete, inte nödvändig mänsklig bedömning.

Satisfi Labs lanserade nyligen Satisfi Forward, en framåtriktad ingenjörspraxis. Vilket gap såg du mellan att bygga en kapabel AI‑plattform och att faktiskt få agenter att fungera pålitligt i en kunds verkliga miljö som ledde dig till att skapa denna modell?

Den sista milen började bli flaskhalsen. En plattform kan standardisera mycket, men den kan inte anta att varje kunds verksamhet fungerar på samma sätt. Deras ärendehanteringssystem har vissa begränsningar. Deras godkännandeprocess går genom tre avdelningar. Deras definition av en kvalificerad lead skiljer sig från nästa kunds. Dessa detaljer avgör om implementeringen faktiskt är användbar.

Du kan köpa en färdig plattform och sätta ihop en demo som imponerar på folk. Att kommersialisera den som en robust upplevelse för verkliga användare är något annat. Det är där framåtriktade ingenjörer kommer in. Vårt team på Satisfi Forward har som uppgift att förstå resultatet, ta reda på vad som hindrar det, och bygga arbetsflöden och integrationer ovanpå plattformen som får det att ske.

Men vi sätter tydliga gränser kring varje engagemang. Innan vi bygger kommer vi överens om vad framgång betyder, vem som äger affärsprocessen, vad som beror på kunden och vem som underhåller den efter lansering. Annars blir ett sista‑milprojekt en obegränsad förpliktelse. Och engagemanget är inte avslutat när koden levereras. Det är avslutat när arbetsflödet fungerar i kundens verksamhet och någon är ansvarig för att hålla det igång.

Kod har också blivit mycket billigare att producera, vilket gör den här modellen mycket mer praktisk än den var tidigare. Men jag ser inte Satisfi Forward som en servicearm som fästs på en SaaS‑produkt. Varje engagemang lär oss vad nästa produkt bör vara. När tre kunder begär samma arbetsflöde är det inte en supportbörda. Det är själva färdplanen som skrivs, med betalande kunder knutna till den. Den gamla SaaS‑modellen gissade på funktioner och väntade på bevis. På detta sätt får vi bevisen först och intäkterna medan vi samlar in dem. Jag tror att så byggs produktföretag i AI‑eran.

Dina agenter kan ansluta till ärendehanteringssystem, CRM‑plattformar, innehållshanteringssystem och andra källor till realtidsinformation. När agenter får förmågan att genomföra transaktioner och initiera åtgärder, hur balanserar du realtidsdatatillgång och låg latens med förankring, säkerhet och skydd mot felaktiga handlingar?

Först skulle jag aldrig låta hastighet kompensera för ett säkerhetsfel. Vissa krav är begränsningar. Du optimerar inom dem.

Sedan skiljer du mellan olika typer av arbete. Att besvara en parkeringsfråga och att slutföra ett biljettsköp kräver inte samma datafriskhet eller samma kontroller. Du kan cachea stabil information. När pengar byter händer behöver du det auktoritativa transaktionssystemet för att bekräfta pris, tillgänglighet och slutförande.

De farliga fallen är de där systemet inte vet vad som hände. En backend accepterar ett köp, men svaret kommer aldrig fram. Om agenten antar ett fel och försöker igen får du två köp. Det är inte ett språkproblem. Det är ett problem med transaktionsåterhämtning.

Och du mäter upplevelsen under de förhållanden som verkligen spelar roll. Genomsnittlig latens en lugn tisdag säger nästan ingenting. Om ett evenemang blir regnat bort får du plötsligt tusentals personer som frågar vad som händer med deras biljetter, samtidigt. Om du bara planerar kring genomsnittlig trafik per minut missar du den kapacitet du behöver i den här pulsen. Det lärde jag mig direkt från handelssystem.

Det finns också ett kostnadsbeslut här. Inte varje begäran kräver den dyraste modellen eller en kedja av agenter. Använd den enklaste vägen som uppfyller kravet, och lägg den extra tid eller beräkning där det materiellt förbättrar beslutet. Användaren bör få ett ärligt resultat, inklusive ett ärligt uttalande om att något inte kunde bekräftas.

Satisfi Labs beskriver en modell där specialiserade agenter kan arbeta tillsammans som en AI‑arbetsstyrka. Vilka är de svåraste tekniska problemen med att orkestrera flera specialiserade agenter, särskilt kring routning, delad kontext, motstridiga beslut och att avgöra vilken agent som ska agera?

Den svåraste delen är att behålla ansvarigheten när du fördelar arbetet.

Börja med att fråga om du verkligen behöver en ytterligare agent. Ibland behövs en specialist. Ibland räcker det med ett verktygsanrop eller ett enkelt arbetsflöde. Varje agent du lägger till är en ny tolkning av begäran, ett nytt beroende, en ny potentiell felkälla. Och antalet agenter som körs i bakgrunden bör vara osynligt för användaren.

När flera agenter är motiverade vill jag att en agent äger interaktionen. Specialister kan tillhandahålla information eller utföra avgränsat arbete. En biljettagent hanterar lager och byten, en kundtjänstagent hanterar policyer. Men någon måste avstämma resultaten och avgöra om användaren faktiskt fick det de kom för.

Routning är svårt eftersom människor inte ställer frågor i tydliga kategorier. En begäran kan beröra tre agenter. Systemet måste avgöra: kan en hantera den, behöver flera köras i sekvens, eller bör det ställa en ytterligare fråga till användaren innan något görs?

Samma gäller kontext. Du skickar inte allt till varje agent. Det ökar fördröjning, skapar brus och kan avslöja information som en agent inte behöver. Och en agents antagande bör inte bli en fakta bara för att det vidarebefordras till nästa agent.

Om två agenter är oense vill jag inte att de argumenterar tills den ena låter mer övertygande. Det måste finnas en tydlig auktoritetsmodell. Biljettssystemet fastställer tillgänglighet. Företaget fastställer bytespolicy. Realtidsdata slår cachad data, affärsregler slår modellbedömning, och om det fortfarande inte kan lösas, frågar du användaren eller tar in en person. Den svåra delen är inte att få agenterna att prata med varandra. Det är att kunna återkonstruera exakt vilken agent som gjorde vad och var ansvaret låg.

Satisfi Labs har i allt högre grad fokuserat på att mäta agenter mot mål och affärsresultat snarare än metrik som samtalsvolym. Vad bör företag faktiskt mäta för att avgöra om en AI‑agent presterar väl, och hur utvärderar du tillförlitlighet innan du ger en agent större autonomi?

Börja med affärsresultatet, och fråga sedan hur stor del av det resultatet som agenten faktiskt orsakade.

Om någon köper biljetter efter att ha pratat med en agent betyder det inte automatiskt att agenten skapade köpet. De kan ha köpt ändå. Där du kan, vill du ha kontrollerade jämförelser eller en trovärdig baslinje, inte bara ge kredit till den senaste interaktionen. För en biljettkund innebär det att mäta om fanen fick platser, inte om agenten svarade artigt. För en arena som försöker minska köerna i biljettkassan betyder det att mäta vad agenten löste innan någon behövde stå i kö.

Titta sedan på ekonomin bakom ett lyckat resultat: modellkostnader, infrastruktur, mänsklig granskning, eskaleringar och kostnaden för att rätta till misstag. En agent som verkar billig tills du räknar de personer som reparerar dess arbete är inte billig.

Tillförlitlighet behöver ett eget poängkort. Slutförande, korrekthet, obehöriga åtgärder, återhämtning från fel, eskaleringskvalitet. Du kan inte räkna in ett allvarligt integritetsincident i en god konverteringsgrad.

För mer autonomi skulle jag kräva bevis på den specifika handlingstyp som delegeras. Testa den, observera den under övervakning, expandera inom gränser och behåll en möjlighet att stoppa den. Ett bra övergripande noggrannhetspoäng bevisar inte att systemet är redo för varje transaktion. Och var försiktig med incitament. Ibland är det rätta resultatet att ta in en människa. Om du belönar agenten bara för att undvika överlämningar, bli inte förvånad när den behåller problem som den borde ha eskalerat.

Du hävdade nyligen att röst‑AI måste utformas kring mätbara resultat snarare än att behandlas som ett ytterligare gränssnitt för en befintlig chatbot. Vilka tekniska genombrott behövs fortfarande innan röstagenter kan bli ett primärt gränssnitt för komplexa, realtidsinteraktioner, särskilt i miljöer som arenor, attraktioner och live‑evenemang?

Många kunder frågar om du bara kan ta chattapplikationen och koppla in röst. Det kan vi. Men det betyder inte att det blir en bra upplevelse. Den nästa verkliga förbättringen är inte en mer människolik röst. Det är en interaktion som klarar de förhållanden som folk faktiskt använder den i.

I en arena pratar någon över publikens brus, använder ett okänt spelar‑namn, ändrar sig mitt i en mening och försöker slutföra ett köp innan grindarna öppnas. Systemet måste hantera avbrott, osäkerhet och backend‑fördröjningar utan att förlora uppgiften.

Var särskilt uppmärksam på kritiska detaljer. Att missförstå en vardaglig fras är en sak. Att missförstå antalet biljetter eller evenemangets datum är en annan. Agenten måste bekräfta de detaljer som förändrar handlingens konsekvens utan att göra hela samtalet besvärligt.

Och röst bör inte tvingas göra allt. Att jämföra tjugo sittalternativ är bättre på en skärm. Någon kan börja med att skriva, gå in i bilen och vilja fortsätta samma konversation genom att tala. Systemet bör bevara den kontexten och använda röst, text och visuella element på det sätt som passar bäst i stunden.

Vissa delar av detta behöver bättre modeller. Mycket av det kräver bättre integration och interaktionsdesign. Att vänta på ett genombrott kommer inte att lösa ett arbetsflöde som är designat kring text och sedan läses högt. Jag skulle bedöma framsteg på ett sätt: klarar människor av att slutföra uppgiften korrekt, med mindre ansträngning, under verkliga förhållanden?

När agenter går från att tillhandahålla information till att sälja biljetter, samla in kunddata, skräddarsy upplevelser och interagera med operativa system, hur bör företag avgöra vilka beslut en agent kan fatta autonomt och vilka som alltid bör kräva mänsklig tillsyn?

Det handlar om riskhantering. Om detta går fel, vilken skada kan det orsaka? Öppnar agenten en dörr som den inte kan stänga?

Återhämtningsförmåga är ett användbart första test, men man bör också se på den totala exponeringen. En återbetalning kan vara liten och återkallelig. Tiotusen felaktiga återbetalningar innan någon märker det är ett annat problem. Man behöver begränsningar för enskilda åtgärder och för systemets kumulativa aktivitet.

Om åtgärden är lågrisk och återkallelig, ge den mer autonomi: uppdatera en preferens, kontrollera en beställning, hålla ett föremål. Allteftersom konsekvenserna ökar, lägg till bekräftelse eller godkännande. Ett köp kan kräva att kunden bekräftar priset. En stor återbetalning kan behöva en anställds godkännande. Ett säkerhetshot eskaleras omedelbart. Och vissa beslut bör helt enkelt ligga kvar hos en person, punkt.

Kundens samtycke och företagets godkännande är olika saker, förresten. Att en kund bekräftar ett köp ger inte agenten rätt att kringgå företagets policy. Att en anställd godkänner ett undantag betyder inte att kunden godkänt en avgift.

Begränsningarna måste verkställas av de system som utför åtgärden, inte bara beskrivas i en prompt. Man ger inte en agent bred åtkomst och förlitar sig sedan på en prompt som säger att den ska vara försiktig. Och när en person krävs, ge dem tillräckligt med kontext för att fatta ett riktigt beslut. Ge någon hundratals godkännanden utan någon information, så har du byggt en gummistämpel, inte tillsyn. Placera mänsklig uppmärksamhet där den minskar meningsfull risk. Sprid den inte tunt över varje interaktion.

Ser du fram emot att teknologier som Model Context Protocol och agent‑till‑agent‑kommunikation fundamentalt förändrar hur företags‑AI‑system byggs, och för oss från isolerade agenter till ekosystem där agenter kan upptäcka verktyg, utbyta kontext och samordna åtgärder över företag och plattformar?

Jag tror att protokollen är ett medel för ett mål. MCP ger AI‑applikationer ett gemensamt sätt att komma åt verktyg och kontext. Agent‑till‑agent‑protokoll hanterar samarbete mellan agenter. Det är värdefullt. Man bör inte behöva bygga en anpassad integration varje gång en agent behöver ett verktyg. Det liknar vad API:er gjorde för programvaruintegrationer.

Men ett gemensamt format betyder inte att två företag är överens om vad en åtgärd innebär, vem som kan godkänna den eller vad som händer när den misslyckas. Att en agent kan upptäcka ett verktyg betyder inte att den får använda det. Man måste fortfarande reda ut identitet, behörigheter, förtroende och ansvar. Om en agent ber en annan att göra något och det går fel, vem äger det beslutet?

Det här är vad jag tror faktiskt förändras. Idag har en plats en webbplats och en app. Om några år kommer den att ha en agent som andra agenter förhandlar med. En fans personliga assistent frågar platsens agent om två biljetter till ett visst pris, plus ett parkeringspass, och hela transaktionen sker mellan de två agenterna. Att hitta rätt funktioner är det enkla steget. Att känna till kundens spenderingsbehörighet, bekräfta det sammansatta priset och hantera fallet där biljetterna lyckas men parkeringen misslyckas, är de verkliga problemen.

Och jag tror inte att driften av en agent automatiskt ger dig kundrelationen. Det måste förtjänas. Men jag tror inte heller att arenor kommer att överlämna dessa transaktioner till ett sökföretag eller en biljettmarknad. Vårt mål på Satisfi Labs är att vara den agent som representerar arenan i den ekonomin, den som är tillräckligt pålitlig för att ett företag sätter sitt namn på den. Allt vi har byggt kring pålitlighet, behörigheter och ansvar är det som förtjänar den platsen.

Tack för den fantastiska intervjun, läsare som vill lära sig mer bör besöka Satisfi Labs.