Randall Newman, CPTO og medgründer av Satisfi Labs – Intervjuserie

Randall Newman, CPTO og medgründer av Satisfi Labs, er en teknolog- og produktleder med omfattende erfaring med å bygge AI-plattformer, finansteknologi og høyytelsesystemer. Siden han medgrunnla Satisfi Labs, har Newman spilt en sentral rolle i å visualisere, designe og skalere selskapets konversasjons‑AI‑teknologi, samtidig som han har hatt ansvar for produktutvikling, arkitektur, ingeniørteam og strategiske integrasjoner. Før Satisfi Labs var han produktansvarlig i Satisfi Inc. og medgrunnla mobilmarkedsføringsselskapet Right On Mobile. Tidligere i karrieren tilbrakte Newman mer enn 17 år i CIBC World Markets, hvor han hadde seniorlederroller innen strategisk risiko, høyfrekvent handel og aksjearbitrasje, og kombinerte kvantitativ handelskompetanse med praktisk teknologisk utvikling.

Satisfi Labs er et AI‑selskap som fokuserer på å distribuere spesialiserte AI‑agenter for sport, underholdning, turisme, attraksjoner og andre virksomheter med live‑opplevelser. Selskapet ble grunnlagt i 2016, og har utviklet seg fra konversasjons‑AI og sin Answer Engine til en agentbasert plattform designet for å hjelpe organisasjoner med å automatisere gjestesupport, øke billett‑ og handelskonverteringer, og hente innsikt fra kundesamtaler. AI‑agentene kan operere på mer enn 50 språk og koble seg til billett‑, CRM‑, innholdsstyrings‑ og andre forretningssystemer for å utføre handlinger som å selge billetter, eskalere samtaler til menneskelig personale, samle inn kundeinformasjon og levere personlige svar. Satisfi Labs sier at teknologien nå er betrodd av mer enn 775 merkevarer, med integrasjoner og partnerskap som omfatter selskaper som Ticketmaster, Simpleview, MappedIn, Ventrata og Vozzi.

Du tilbrakte nesten to tiår i finansmarkedene, inkludert å bygge lav‑latens handelssystemer og lede høyfrekvente handelsstrategier i CIBC, før du gikk over til teknologientreprenørskap og til slutt medgrunnla Satisfi Labs. Hvilke lærdommer fra operativsystemer der hastighet, pålitelighet og risikostyring var avgjørende, har påvirket hvordan du bygger produksjonsklare AI‑agenter i dag?

Handel lærte meg at en god idé og en god virksomhet er to forskjellige ting. Du kan identifisere en mulighet korrekt og fortsatt tape penger fordi gjennomføringen er treg, kostnadene er for høye, eller risikoforutsetningene er feil. AI er det samme. Modellens kapasitet er én innspill. Virksomheten avhenger av om du kan omgjøre den kapasiteten til et repeterbart resultat til en akseptabel kostnad og risiko.

Å drive en indeks‑arbitrasjebok lærer deg også å se forbi individuelle beslutninger. En liten feil som gjentas over en portefølje blir en svært stor eksponering. Med AI kan du ha tusenvis av agenter som tar individuelt fornuftige beslutninger, men som samlet skaper et problem. De er alle avhengige av de samme dårlige dataene, eller de prøver alle samme mislykkede tjeneste på nytt. Du må håndtere systemet, ikke bare den enkelte responsen.

Også hastighet er kun viktig når den forbedrer resultatet. I handel var det øyeblikk der mikrosekunder betydde noe. I AI foretrekker jeg å bruke ett sekund ekstra på å bekrefte en transaksjon fremfor å levere feil resultat umiddelbart. Disiplinen er å vite hvor hastighet skaper verdi, og hvor den bare akselererer en feil.

Den siste lærdommen er den som startet hele virksomheten. Fordelen kommer fra å oppdage en feilprising før alle andre gjør det. Jeg tror feilprisingen akkurat nå er at de fleste bedrifter ser på AI‑agenter som en måte å kutte supportkostnader på. Hos Satisfi Labs ser vi dem som en inntektskanal. På våre sportsarenaer handler omtrent 40 prosent av agent‑samtalene om billetter. Disse fansene kommer ikke for å klage. De kommer med penger i hånden og spør hvor de kan sitte. Finn det markedet har priset feil, og gå etter det. Samme instinkt som i arbitrage‑virksomheten.

Satisfi Labs ble grunnlagt i 2017, godt før den nåværende generative AI‑bølgen, og har utviklet seg fra kontekstuell naturlig språkbehandling og konversasjons‑AI til en agentbasert plattform. Hva var de største arkitektoniske endringene som var nødvendige for å gå fra systemer som primært var designet for å svare på spørsmål, til agenter som kan utføre handlinger på vegne av brukere?

Vi brukte et tiår på å bygge tusenvis av AI‑agenter for over 800 bedriftskunder, inkludert MLB/NFL‑lag, underholdningsarenaer og turistorganisasjoner. Den største endringen er at du gir systemet autoritet, ikke bare informasjon.

Hvis en assistent forteller deg hvilke billetter som er tilgjengelige, gir den et svar. Hvis den bytter billetter for deg, endrer den lager, kunderegistre og potensielt penger. Nå må du vite hvem som autoriserte handlingen, hva som faktisk skjedde, og hvordan du kan gjenopprette dersom prosessen stopper halvveis.

Derfor skiller vi modellens vurdering fra autoriteten til å utføre. Modellen kan tolke en forespørsel og foreslå neste steg. Systemene under den håndhever tillatelser, forretningsregler og transaksjonsgrenser. En overbevisende forklaring fra modellen kan ikke overstyre disse kontrollene.

Du trenger også en klar skillelinje mellom “agenten sa at den fullførte oppgaven” og “forretningssystemet bekreftet fullføring”. De er ikke det samme. Hvis en kjøpsforespørsel får tidsavbrudd, bør du finne ut om kjøpet ble gjennomført før du prøver igjen.

Strategisk sett bør ikke bedre modeller tvinge deg til å bygge om forretningskontrollene dine. Jeg vil dra nytte av hver forbedring i resonnering uten å måtte reforhandle hva systemet får lov til å gjøre hver gang en ny modell lanseres.

Begrepet “agentic AI” brukes nå på et bredt spekter av produkter. Fra et ingeniørperspektiv, hvor trekker du grensen mellom en avansert chatbot, en AI copilot og en virkelig autonom AI-agent?

Jeg ville stille ett spørsmål: hvilket ansvar har personen faktisk delegert?

En chatbot gir informasjon. En copilot hjelper deg med å få arbeidet gjort, men du styrer fortsatt og godkjenner de viktige trinnene. En autonom agent har tillatelse til å ta noen av disse beslutningene selv mens den forfølger et mål.

Grensesnittet forteller deg ikke hvilken du ser på. Et samtalebasert produkt kan ha reell autonomi bak seg. Noe som markedsføres som en agent, kan fortsatt trenge at en person godkjenner hver nyttig handling.

For en bedrift bør autonomi være en spesifikk avtale: dette systemet kan utføre disse handlingene, for disse brukerne, innenfor disse grensene, og må stoppe under disse betingelsene. Det er noe du faktisk kan teste og styre.

Jeg ville heller ikke gjøre maksimal autonomi til målet. Noen ganger stiller det beste produktet ett godt timet spørsmål og håndterer resten. Å fjerne det spørsmålet gjør demonstrasjonen mer imponerende, men virksomheten mindre sikker. Målet er å fjerne unødvendig menneskelig arbeid, ikke nødvendig menneskelig skjønn.

Satisfi Labs lanserte nylig Satisfi Forward, en fremover-disponert ingeniørpraksis. Hvilket gap så dere mellom å bygge en kapabel AI-plattform og faktisk få agenter til å fungere pålitelig i en kundes virkelige miljø, som førte til at dere skapte denne modellen?

Den siste delen ble flaskehalsen. En plattform kan standardisere mye, men den kan ikke anta at hver kundes virksomhet fungerer på samme måte. Deres billettsystem har visse begrensninger. Deres godkjenningsprosess går gjennom tre avdelinger. Deres definisjon av en kvalifisert lead er forskjellig fra den neste kundens. Disse detaljene avgjør om implementeringen faktisk er nyttig.

Du kan kjøpe en ferdig plattform og sette sammen en demo som imponerer folk. Å kommersialisere den som en robust opplevelse for ekte brukere er noe annet. Det er her fremover-disponerte ingeniører kommer inn. Oppgaven til teamet vårt i Satisfi Forward er å forstå resultatet, finne ut hva som hindrer det, og bygge arbeidsflyter og integrasjoner på toppen av plattformen som får det til å skje.

Men vi setter klare grenser rundt hvert engasjement. Før vi bygger, blir vi enige om hva suksess betyr, hvem som eier forretningsprosessen, hva som avhenger av kunden, og hvem som vedlikeholder den etter lansering. Ellers blir et siste-mile-prosjekt en ubegrenset forpliktelse. Og engasjementet er ikke fullført når koden leveres. Det er fullført når arbeidsflyten fungerer i kundens drift, og noen er ansvarlige for å holde den i gang.

Koden har også blitt mye billigere å produsere, noe som gjør denne modellen langt mer praktisk enn den var tidligere. Men jeg ser ikke på Satisfi Forward som en tjenesteavdeling festet på et SaaS-produkt. Hvert engasjement lærer oss hva neste produkt bør være. Når tre kunder ber om den samme arbeidsflyten, er det ikke en støttebyrde. Det er selve veikartet som skrives, med betalende kunder knyttet til det. Den gamle SaaS-modellen gjettet på funksjoner og ventet på bevis. På denne måten får vi bevisene først, og inntektene mens vi samler dem. Jeg tror det er slik produktbedrifter bygges i AI-æraen.

Agentene dine kan koble seg til billettsystemer, CRM-plattformer, innholdsstyringssystemer og andre kilder til sanntidsinformasjon. Etter hvert som agenter får muligheten til å gjennomføre transaksjoner og utløse handlinger, hvordan balanserer du sanntidsdatatilgang og lav latens med forankring, sikkerhet og beskyttelse mot feil handlinger?

Først ville jeg aldri la hastighet kompensere for en sikkerhetsfeil. Noen krav er begrensninger. Du optimaliserer innenfor dem.

Deretter skiller du mellom typer arbeid. Å svare på et parkeringsspørsmål og å fullføre et billettkjøp krever ikke samme datafriskhet eller samme kontroller. Du kan cache stabil informasjon. Når penger skifter hender, trenger du det autoritative transaksjonssystemet for å bekrefte pris, tilgjengelighet og fullføring.

De farlige tilfellene er de hvor systemet ikke vet hva som skjedde. En backend godtar et kjøp, men svaret kommer aldri. Hvis agenten antar feil og prøver igjen, får du to kjøp. Det er ikke et språkproblem. Det er et transaksjons-gjenopprettingsproblem.

Og du måler opplevelsen under de forholdene som faktisk betyr noe. Gjennomsnittlig latens på en rolig tirsdag forteller deg nesten ingenting. Hvis et arrangement blir avlyst på grunn av regn, får du plutselig tusenvis av folk som spør hva som skjer med billettene deres, alle på en gang. Hvis du bare planlegger rundt gjennomsnittlig trafikk per minutt, vil du gå glipp av kapasiteten du trenger i den bølgen. Det lærte jeg direkte fra handelssystemer.

Det er også en kostnadsbeslutning her. Ikke hver forespørsel krever den dyreste modellen eller en kjede av agenter. Bruk den enkleste veien som oppfyller kravet, og bruk ekstra tid eller beregning der det faktisk forbedrer beslutningen. Brukeren bør få et ærlig resultat, inkludert en ærlig uttalelse om at noe ikke kunne bekreftes.

Satisfi Labs beskriver en modell der spesialiserte agenter kan operere sammen som en AI-arbeidsstyrke. Hva er de vanskeligste tekniske problemene knyttet til å orkestrere flere spesialiserte agenter, spesielt når det gjelder ruting, delt kontekst, motstridende beslutninger og å bestemme hvilken agent som skal handle?

Den vanskeligste delen er å opprettholde ansvarlighet når du distribuerer arbeidet.

Begynn med å spørre om du i det hele tatt trenger en annen agent. Noen ganger trenger du en spesialist. Noen ganger trenger du bare et verktøykall eller en enkel arbeidsflyt. Hver agent du legger til er en ny tolkning av forespørselen, en ny avhengighet, et nytt potensielt feilpunkt. Og antallet agenter som kjører i bakgrunnen skal være usynlig for brukeren.

Når flere agenter er berettiget, ønsker jeg at én agent skal eie interaksjonen. Spesialister kan gi informasjon eller utføre avgrenset arbeid. En billettagent håndterer lager og bytter, en kundeservice‑agent håndterer retningslinjer. Men noen må avstemme resultatene og avgjøre om brukeren faktisk fikk det de kom for.

Ruting er vanskelig fordi folk ikke stiller spørsmål i ryddige kategorier. En forespørsel kan berøre tre agenter. Systemet må avgjøre: kan én håndtere den, trenger flere å kjøre i rekkefølge, eller bør det stille brukeren ett ekstra spørsmål før noe gjøres?

Det samme gjelder kontekst. Du sender ikke alt til hver agent. Det øker latens, skaper støy, og kan avsløre informasjon en agent ikke trenger. Og en agents antakelse bør ikke bli en fakta bare fordi den ble videreført til neste agent.

Hvis to agenter er uenige, vil jeg ikke at de skal krangle til den ene virker mer overbevisende. Det må finnes en klar autoritetsmodell. Billettsystemet fastsetter tilgjengelighet. Bedriften fastsetter byttepolicy. Sanntidsdata slår cache‑data, forretningsregler slår modellvurdering, og hvis det fortsatt ikke kan løses, spør du brukeren eller involverer en person. Den vanskelige delen er ikke å få agentene til å snakke med hverandre. Det er å kunne rekonstruere nøyaktig hvilken agent som gjorde hva og hvor ansvaret lå.

Satisfi Labs har i økende grad fokusert på å måle agenter mot mål og forretningsresultater i stedet for metrikker som samtalevolum. Hva bør bedrifter faktisk måle for å fastslå om en AI‑agent presterer bra, og hvordan evaluerer du pålitelighet før du gir en agent større autonomi?

Begynn med forretningsresultatet, og spør deretter hvor mye av det resultatet agenten faktisk forårsaket.

Hvis noen kjøper billetter etter å ha snakket med en agent, betyr det ikke automatisk at agenten skapte salget. De kan ha kjøpt uansett. Der det er mulig, ønsker du kontrollerte sammenligninger eller en troverdig referanse, ikke bare kreditt til den siste interaksjonen. For en billettkunde betyr det å måle om fanen endte opp med seter, ikke om agenten svarte høflig. For en arena som prøver å redusere køene i billettluken, betyr det å måle hva agenten løste før noen måtte stå i kø.

Se deretter på økonomien bak et vellykket resultat: modellkostnader, infrastruktur, menneskelig gjennomgang, eskaleringer og kostnaden ved å rette feil. En agent som virker billig før du teller personene som reparerer arbeidet, er ikke billig.

Pålitelighet trenger sin egen poengtabell. Fullføring, korrekthet, uautoriserte handlinger, gjenoppretting etter feil, kvalitet på eskaleringer. Du kan ikke inkludere en alvorlig personvern‑hendelse i en god konverteringsrate.

For mer autonomi vil jeg kreve bevis på den spesifikke handlingstypen som delegers. Test den, observer den under tilsyn, utvid innenfor grenser, og ha en måte å stoppe den på. En god samlet nøyaktighets‑score beviser ikke at systemet er klart for hver transaksjon. Vær også forsiktig med insentiver. Noen ganger er det riktige resultatet å involvere en person. Hvis du belønner agenten kun for å unngå overleveringer, bli ikke overrasket når den beholder problemer den burde ha eskalert.

Du argumenterte nylig for at stemme‑AI må designes rundt målbare resultater i stedet for å behandles som et annet grensesnitt for en eksisterende chatbot. Hvilke tekniske gjennombrudd er fortsatt nødvendige før stemmeagenter kan bli et primært grensesnitt for komplekse, sanntidsinteraksjoner, spesielt i miljøer som stadioner, attraksjoner og live‑arrangementer?

Mange kunder spør om du bare kan ta chatte‑applikasjonen og koble inn stemme? Det kan vi. Men det betyr ikke at det blir en god opplevelse. Den neste virkelige forbedringen er ikke en mer menneskelig lydende stemme. Det er en interaksjon som overlever de forholdene folk faktisk bruker den i.

På en stadion snakker noen over publikumsstøy, bruker et ukjent spiller‑navn, endrer mening halvveis i en setning, og prøver å fullføre et kjøp før portene åpnes. Systemet må håndtere avbrytelse, usikkerhet og backend‑forsinkelser uten å miste oppgaven.

Vær spesielt oppmerksom på kritiske detaljer. Å misforstå en uformell frase er én ting. Å misforstå antall billetter eller arrangementsdatoen er en annen. Agenten må bekrefte detaljene som påvirker konsekvensen av handlingen uten at hele samtalen blir tung.

Og stemmen bør ikke tvinges til å gjøre alt. Å sammenligne tjue sittealternativer er bedre på en skjerm. Noen kan begynne med å skrive, sette seg i bilen, og ønsker å fortsette den samme samtalen ved å snakke. Systemet bør bevare den konteksten og bruke stemme, tekst og visuelle elementer på den måten som passer best i øyeblikket.

Noe av dette trenger bedre modeller. Mye av det trenger bedre integrasjon og interaksjonsdesign. Å vente på et gjennombrudd vil ikke løse en arbeidsflyt som er designet rundt tekst og deretter lest høyt. Jeg vil vurdere fremgang på én måte: fullfører folk oppgaven nøyaktig, med mindre innsats, under reelle forhold?

Når agenter går fra å gi informasjon til å selge billetter, samle kundedata, tilpasse opplevelser og samhandle med operative systemer, hvordan skal selskaper bestemme hvilke beslutninger en agent kan ta autonomt og hvilke som alltid bør kreve menneskelig tilsyn?

Det er risikostyring. Hvis dette går galt, hvilken skade kan det forårsake? Åpner agenten en dør den ikke kan lukke?

Omvendbarhet er en nyttig første test, men se også på total eksponering. En refusjon kan være liten og omvendbar. Ti tusen feilaktige refusjoner før noen legger merke til det er et annet problem. Du trenger grenser for individuelle handlinger og for systemets samlede aktivitet.

Hvis handlingen er lavrisiko og omvendbar, gi den mer autonomi: oppdatere en preferanse, sjekke en bestilling, holde et element. Etter hvert som konsekvensene øker, legg til bekreftelse eller godkjenning. Et kjøp kan kreve at kunden bekrefter prisen. En stor refusjon kan kreve en ansatts godkjenning. En sikkerhetstrussel eskaleres umiddelbart. Og noen beslutninger bør bare forbli hos en person, punkt.

Kundens samtykke og selskapets godkjenning er forskjellige ting, for øvrig. At en kunde bekrefter et kjøp gir ikke agenten tillatelse til å omgå selskapets retningslinjer. At en ansatt godkjenner et unntak betyr ikke at kunden har samtykket til en belastning.

Grenser må håndheves av systemene som utfører handlingen, ikke bare beskrives i en prompt. Du gir ikke en agent bred tilgang og deretter stoler på at en prompt forteller den å være forsiktig. Og når en person er nødvendig, gi vedkommende nok kontekst til å ta en reell beslutning. Gi noen hundre godkjenninger uten informasjon, så har du laget en gummistempel, ikke tilsyn. Plasser menneskelig oppmerksomhet der den reduserer meningsfull risiko. Ikke spre den tynt over hver eneste interaksjon.

Når vi ser fremover, forventer du at teknologier som Model Context Protocol og agent‑til‑agent‑kommunikasjon vil endre hvordan bedrifts‑AI‑systemer bygges i grunnleggende grad, og flytte oss fra isolerte agenter til økosystemer hvor agenter kan oppdage verktøy, utveksle kontekst og koordinere handlinger på tvers av selskaper og plattformer?

Jeg tror protokollene er et middel til et mål. MCP gir AI‑applikasjoner en felles måte å få tilgang til verktøy og kontekst på. Agent‑til‑agent‑protokoller håndterer samarbeid mellom agenter. Det er verdifullt. Du bør ikke måtte bygge en tilpasset integrasjon hver eneste gang en agent trenger et verktøy. Det er likt det API‑ene gjorde for programvareintegrasjoner.

Men et felles format betyr ikke at to virksomheter er enige om hva en handling betyr, hvem som kan autorisere den, eller hva som skjer når den mislykkes. Bare fordi en agent kan oppdage et verktøy, betyr det ikke at den skal få bruke det. Du må fortsatt avklare identitet, tillatelser, tillit og ansvarlighet. Hvis en agent ber en annen om å gjøre noe og det går galt, hvem eier den beslutningen?

Dette er det jeg mener faktisk endrer seg. I dag har en arena en nettside og en app. Om noen år vil den ha en agent som andre agenter kan forhandle med. En fans personlige assistent ber arenaens agent om to billetter til en viss pris, pluss en parkeringspass, og hele transaksjonen skjer mellom de to agentene. Å finne de rette funksjonene er det enkle steget. Å kjenne kundens kjøpsmyndighet, bekrefte den samlede prisen, og håndtere tilfeller der billettene går gjennom men parkeringen mislykkes, er de reelle utfordringene.

Og jeg tror ikke at det å drive en agent automatisk gir deg kundeforholdet. Det må fortjenes. Men jeg tror heller ikke at arenaer vil overlate disse transaksjonene til et søkefirma eller en billettmarkedplass. Målet vårt i Satisfi Labs er å være agenten som representerer arenaen i den økonomien, den som er pålitelig nok til at en virksomhet setter sitt navn på den. Alt vi har bygget rundt pålitelighet, tillatelser og ansvarlighet er det som gir oss den plassen.

Takk for det flotte intervjuet, lesere som ønsker å lære mer bør besøke Satisfi Labs.