Randall Newman, CPTO en mede-oprichter van Satisfi Labs – Interviewserie

Randall Newman, CPTO en mede-oprichter van Satisfi Labs, is een technologie‑ en productleider met uitgebreide ervaring in het bouwen van AI‑platformen, financiële technologie en high‑performance systemen. Sinds hij Satisfi Labs mede‑stichtte, heeft Newman een centrale rol gespeeld in het visualiseren, ontwerpen en opschalen van de conversationele AI‑technologie van het bedrijf, terwijl hij toezicht hield op productontwikkeling, architectuur, engineering‑teams en strategische integraties. Voor Satisfi Labs was hij Head of Product bij Satisfi Inc. en mede‑oprichter van het mobiele marketingbedrijf Right On Mobile. Vroeger in zijn carrière bracht Newman meer dan 17 jaar door bij CIBC World Markets, waar hij senior leiderschapsrollen bekleedde op het gebied van strategisch risico, high‑frequency trading en equity arbitrage, en kwantitatieve trading‑expertise combineerde met hands‑on technologische ontwikkeling.

Satisfi Labs is een AI‑bedrijf dat zich richt op het inzetten van gespecialiseerde AI‑agents voor sport, entertainment, toerisme, attracties en andere live‑experience bedrijven. Opgericht in 2016, is het bedrijf geëvolueerd van conversationele AI en zijn Answer Engine naar een agentisch platform dat organisaties helpt gastondersteuning te automatiseren, ticket‑ en handelsconversies te verhogen en inzichten uit klantgesprekken te halen. De AI‑agents kunnen in meer dan 50 talen opereren en verbinden met ticket‑systemen, CRM, content‑management en andere bedrijfssystemen om acties uit te voeren zoals het verkopen van tickets, gesprekken escaleren naar menselijk personeel, klantinformatie verzamelen en gepersonaliseerde antwoorden leveren. Satisfi Labs zegt dat haar technologie nu wordt vertrouwd door meer dan 775 merken, met integraties en partnerschappen die onder meer bedrijven als Ticketmaster, Simpleview, MappedIn, Ventrata en Vozzi omvatten.

U hebt bijna twee decennia in de financiële markten doorgebracht, waaronder het bouwen van low‑latency handelssystemen en het leiden van high‑frequency trading‑strategieën bij CIBC, voordat u overging naar technologie‑ondernemerschap en uiteindelijk Satisfi Labs mede‑stichtte. Welke lessen uit besturingssystemen waar snelheid, betrouwbaarheid en risicobeheer cruciaal waren, hebben uw aanpak bij het bouwen van productie‑grade AI‑agents vandaag het meest beïnvloed?

Handel leerde me dat een goed idee en een goed bedrijf twee verschillende dingen zijn. Je kunt een kans correct identificeren en toch geld verliezen omdat je uitvoering traag is, je kosten te hoog zijn, of je risico‑assumpties onjuist zijn. AI is hetzelfde. Modelcapaciteit is één invoer. Het bedrijf hangt af van of je die capaciteit kunt omzetten in een herhaalbaar resultaat tegen een acceptabele kost en risico.

Het runnen van een index‑arbitrageboek leert je ook om verder te kijken dan individuele beslissingen. Een kleine fout die zich over een portefeuille herhaalt, wordt een zeer grote blootstelling. Met AI kun je duizenden agents hebben die elk redelijk beslissen, maar gezamenlijk een probleem veroorzaken. Ze zijn allemaal afhankelijk van dezelfde slechte data, of ze proberen allemaal dezelfde falende service opnieuw. Je moet het systeem beheren, niet alleen de individuele respons.

En snelheid telt alleen wanneer het de uitkomst verbetert. In de handel waren er momenten waarop microseconden van belang waren. Bij AI besteed ik liever nog een seconde extra aan het bevestigen van een transactie dan het verkeerde resultaat onmiddellijk te leveren. De discipline is weten waar snelheid waarde creëert en waar het slechts een fout versnelt.

De laatste les is diegene die het hele bedrijf heeft gestart. Het voordeel komt voort uit het opsporen van een verkeerde prijsstelling voordat anderen dat doen. Ik denk dat de huidige verkeerde prijsstelling is dat de meeste bedrijven AI‑agents zien als een manier om ondersteuningskosten te verlagen. Bij Satisfi Labs zien wij ze als een inkomstenkanaal. In onze sportlocaties gaat ongeveer 40 procent van de agent‑gesprekken over tickets. Deze fans komen niet om te klagen. Ze komen met geld in de hand, vragen waar ze moeten zitten. Zoek het element dat de markt verkeerd heeft geprijsd en ga het veroveren. Hetzelfde instinct als in de arbitrage‑business.

Satisfi Labs werd opgericht in 2017, ruim vóór de huidige generatieve AI‑golf, en is geëvolueerd van contextuele natural language processing en conversationele AI naar een agentisch platform. Wat waren de grootste architecturale veranderingen die nodig waren om van systemen die voornamelijk zijn ontworpen om vragen te beantwoorden, over te gaan naar agents die namens gebruikers acties kunnen uitvoeren?

We hebben een decennium besteed aan het bouwen van duizenden AI‑agents voor meer dan 800 enterprise‑klanten, waaronder MLB/NFL‑teams, entertainmentlocaties en toerisme‑organisaties. De grootste verandering is dat je het systeem autoriteit geeft, niet alleen informatie.

Als een assistent je vertelt welke tickets beschikbaar zijn, geeft hij een antwoord. Als hij je tickets ruilt, verandert hij de voorraad, klantrecords en mogelijk geld. Nu moet je weten wie de actie heeft geautoriseerd, wat er daadwerkelijk is gebeurd, en hoe je kunt herstellen als het proces halverwege stopt.

Daarom scheiden we het oordeel van het model van de autoriteit om uit te voeren. Het model kan een verzoek interpreteren en de volgende stap voorstellen. De onderliggende systemen handhaven permissies, bedrijfsregels en transactielimieten. Een overtuigende uitleg van het model kan die controles niet overrulen.

Je hebt ook een harde scheiding nodig tussen “de agent zei dat hij de taak voltooide” en “het bedrijfssysteem bevestigde de voltooiing”. Dat zijn niet dezelfde zaken. Als een aankoopverzoek time‑out, kun je beter achterhalen of de aankoop heeft plaatsgevonden voordat je het opnieuw probeert.

En strategisch gezien mogen betere modellen je niet dwingen je bedrijfscontroles opnieuw op te bouwen. Ik wil profiteren van elke verbetering in redeneren zonder telkens opnieuw te onderhandelen over wat het systeem mag doen wanneer er een nieuw model wordt uitgebracht.

De term “agentic AI” wordt nu toegepast op een breed scala aan producten. Vanuit een technisch perspectief, waar trek je de grens tussen een geavanceerde chatbot, een AI‑copiloot en een werkelijk autonome AI‑agent?

Ik zou één vraag stellen: welke verantwoordelijkheid heeft de persoon daadwerkelijk gedelegeerd?

Een chatbot levert informatie. Een copiloot helpt je het werk te doen, maar jij blijft de belangrijke stappen sturen en goedkeuren. Een autonome agent heeft toestemming om sommige van die beslissingen zelf te nemen terwijl hij een doel nastreeft.

De interface vertelt je niet welke je bekijkt. Een conversatieproduct kan echte autonomie hebben. Iets dat als een agent wordt gepresenteerd, kan nog steeds een persoon nodig hebben om elke bruikbare actie goed te keuren.

Voor een onderneming moet autonomie een specifieke overeenkomst zijn: dit systeem mag deze acties uitvoeren, voor deze gebruikers, binnen deze grenzen, en moet stoppen onder deze voorwaarden. Dat is iets wat je daadwerkelijk kunt testen en beheersen.

Ik zou ook niet streven naar maximale autonomie. Soms stelt het beste product één goed getimede vraag en regelt de rest. Het wegnemen van die vraag maakt de demo indrukwekkender, maar het bedrijf minder veilig. Het doel is onnodig menselijk werk te elimineren, niet noodzakelijk menselijk oordeel.

Satisfi Labs heeft onlangs Satisfi Forward gelanceerd, een forward‑deployed engineering practice. Welke kloof zag je tussen het bouwen van een capabel AI‑platform en het daadwerkelijk laten werken van agents betrouwbaar in de real‑world omgeving van een klant, die je ertoe bracht dit model te creëren?

De laatste stap werd de knelpunt. Een platform kan veel standaardiseren, maar het kan niet aannemen dat elk klantbedrijf op dezelfde manier werkt. Hun ticketsysteem heeft bepaalde beperkingen. Hun goedkeuringsproces loopt via drie afdelingen. Hun definitie van een gekwalificeerde lead verschilt van die van de volgende klant. Die details bepalen of de implementatie daadwerkelijk nuttig is.

Je kunt een kant‑en‑klaar platform kopen en een demo in elkaar zetten die mensen onder de indruk maakt. Het commercialiseren ervan als een robuuste ervaring voor echte gebruikers is iets anders. Daar komen forward‑deployed engineers om de hoek kijken. Het werk van ons team bij Satisfi Forward is het resultaat te begrijpen, te achterhalen wat het blokkeert, en de workflows en integraties bovenop het platform te bouwen die het mogelijk maken.

Maar we stellen duidelijke grenzen rond elke samenwerking. Voordat we bouwen, komen we overeen wat succes betekent, wie de bedrijfsprocessen bezit, wat afhankelijk is van de klant, en wie het na de lancering onderhoudt. Anders wordt een last‑mile project een onbeperkte verplichting. En de samenwerking is niet afgerond wanneer de code wordt geleverd. Hij is afgerond wanneer de workflow werkt in de operatie van de klant en iemand verantwoordelijk is voor het draaiende houden ervan.

Code is ook veel goedkoper geworden om te produceren, waardoor dit model veel praktischer is dan voorheen. Maar ik zie Satisfi Forward niet als een service‑tak die op een SaaS‑product is aangebracht. Elke samenwerking leert ons wat het volgende product moet zijn. Wanneer drie klanten om dezelfde workflow vragen, is dat geen ondersteuningslast. Dat is de roadmap die zichzelf schrijft, met betalende klanten eraan gekoppeld. Het oude SaaS‑model gokte met functies en wachtte op bewijs. Op deze manier krijgen we eerst het bewijs, en de omzet terwijl we het verzamelen. Ik denk dat zo productbedrijven worden opgebouwd in het AI‑tijdperk.

Je agents kunnen verbinding maken met ticketsystemen, klantrelatie‑managementplatformen, content‑managementsystemen en andere bronnen van realtime informatie. Naarmate agents de mogelijkheid krijgen om transacties uit te voeren en acties te activeren, hoe balanceer je realtime data‑toegang en lage latentie met onderbouwing, beveiliging en waarborgen tegen onjuiste acties?

Eerst zou ik nooit snelheid laten compenseren voor een beveiligingsfout. Sommige eisen zijn beperkingen. Je optimaliseert binnen die grenzen.

Vervolgens onderscheid je tussen soorten werk. Het beantwoorden van een parkeer‑vraag en het voltooien van een ticket‑aankoop vereisen niet dezelfde datavernieuwing of dezelfde controles. Je kunt stabiele informatie cachen. Wanneer geld van de hand wisselt, heb je het autoritatieve transactiesysteem nodig om prijs, beschikbaarheid en voltooiing te bevestigen.

De gevaarlijke gevallen zijn die waarbij het systeem niet weet wat er is gebeurd. Een backend accepteert een aankoop, maar de respons komt nooit aan. Als de agent een fout aanneemt en opnieuw probeert, krijg je twee aankopen. Dat is geen taalprobleem. Dat is een transactie‑herstelprobleem.

En je meet de ervaring onder de omstandigheden die er echt toe doen. Gemiddelde latentie op een rustige dinsdag vertelt je bijna niets. Als een evenement wordt afgelast door regen, krijg je plotseling duizenden mensen die tegelijk vragen wat er met hun tickets gebeurt. Als je alleen plant op basis van gemiddeld verkeer per minuut, mis je de capaciteit die je nodig hebt tijdens die piek. Dat heb ik rechtstreeks geleerd van handelssystemen.

Er zit hier ook een kostbeslissing bij. Niet elke aanvraag heeft het duurste model of een keten van agenten nodig. Gebruik het eenvoudigste pad dat aan de eis voldoet, en besteed de extra tijd of rekencapaciteit daar waar het de beslissing wezenlijk verbetert. De gebruiker moet een eerlijk resultaat krijgen, inclusief een eerlijke vermelding dat iets niet kon worden bevestigd.

Satisfi Labs beschrijft een model waarin gespecialiseerde agenten samen kunnen opereren als een AI-werkkracht. Wat zijn de moeilijkste technische problemen bij het orkestreren van meerdere gespecialiseerde agenten, met name rond routing, gedeelde context, conflicterende beslissingen en het bepalen welke agent moet handelen?

Het moeilijkste is de verantwoordelijkheid behouden terwijl je het werk verdeelt.

Begin met de vraag of je überhaupt een extra agent nodig hebt. Soms heb je een specialist nodig. Soms heb je alleen een tool‑aanroep of een eenvoudige workflow nodig. Elke agent die je toevoegt is een nieuwe interpretatie van het verzoek, een extra afhankelijkheid, een extra mogelijke fout. En het aantal agenten dat op de achtergrond draait, moet onzichtbaar blijven voor de gebruiker.

Wanneer meerdere agenten gerechtvaardigd zijn, wil ik dat één agent de interactie bezit. Specialisten kunnen informatie leveren of beperkt werk uitvoeren. Een ticket‑agent behandelt voorraad en uitwisselingen, een klantenservice‑agent behandelt beleid. Maar iemand moet de resultaten afstemmen en bepalen of de gebruiker daadwerkelijk kreeg wat hij of zij zocht.

Routing is moeilijk omdat mensen geen vragen stellen in nette categorieën. Eén verzoek kan drie agenten raken. Het systeem moet beslissen: kan één agent het afhandelen, moeten er meerdere in volgorde worden uitgevoerd, of moet er de gebruiker nog een vraag stellen voordat er iets gebeurt?

Hetzelfde geldt voor context. Je stuurt niet alles naar elke agent. Dat veroorzaakt latentie, creëert ruis en kan informatie blootleggen die een agent niet nodig heeft. En de veronderstelling van een agent mag geen feit worden alleen omdat deze is doorgegeven aan de volgende agent.

Als twee agenten het niet eens zijn, wil ik niet dat ze blijven discussiëren totdat één overtuigender klinkt. Er moet een duidelijk autoriteitsmodel zijn. Het ticketsysteem bepaalt de beschikbaarheid. Het bedrijf bepaalt het uitwisselingsbeleid. Real‑time data wint van gecachte data, bedrijfsregels winnen van modelbeoordelingen, en als het nog steeds niet kan worden opgelost, vraag je de gebruiker of schakel je een persoon in. Het moeilijke deel is niet dat agenten met elkaar praten, maar dat je precies kunt reconstrueren welke agent wat deed en waar de verantwoordelijkheid lag.

Satisfi Labs richt zich steeds meer op het meten van agenten aan de hand van doelstellingen en bedrijfsresultaten in plaats van metrics zoals gesprekvolume. Wat zouden bedrijven daadwerkelijk moeten meten om te bepalen of een AI‑agent goed presteert, en hoe evalueer je betrouwbaarheid voordat je een agent meer autonomie geeft?

Begin met het bedrijfsresultaat en vraag vervolgens hoeveel van dat resultaat de agent daadwerkelijk heeft veroorzaakt.

Als iemand tickets koopt na een gesprek met een agent, betekent dat niet automatisch dat de agent de verkoop heeft veroorzaakt. Ze kunnen toch hebben gekocht. Waar mogelijk wil je gecontroleerde vergelijkingen of een geloofwaardig referentiepunt, niet alleen de credit voor de laatste interactie. Voor een ticket‑klant betekent dat meten of de fan uiteindelijk een stoel heeft gekregen, niet of de agent beleefd heeft geantwoord. Voor een locatie die de rijen bij de kassa wil verkorten, betekent het meten wat de agent heeft opgelost voordat iemand in de rij hoefde te staan.

Kijk vervolgens naar de economie van een succesvol resultaat: modelkosten, infrastructuur, menselijke controle, escalaties en de kosten van het herstellen van fouten. Een agent die goedkoop lijkt totdat je de mensen meetelt die zijn werk repareren, is niet goedkoop.

Betrouwbaarheid heeft een eigen scorekaart nodig. Voltooiing, juistheid, ongeautoriseerde handelingen, herstel na fouten, kwaliteit van escalaties. Je mag een ernstig privacy‑incident niet middelen tot een goede conversieratio.

Voor meer autonomie zou ik bewijs eisen over de specifieke klasse van handeling die wordt gedelegeerd. Test het, observeer het onder toezicht, breid het binnen grenzen uit en zorg voor een manier om het te stoppen. Een goede algehele nauwkeurigheidsscore bewijst niet dat het systeem klaar is voor elke transactie. En wees voorzichtig met incentives. Soms is het inschakelen van een persoon de juiste uitkomst. Als je de agent alleen beloont voor het vermijden van overdrachten, wees dan niet verbaasd als hij problemen vasthoudt die hij had moeten escaleren.

Je stelde onlangs dat voice‑AI moet worden ontworpen rond meetbare resultaten in plaats van te worden behandeld als een extra interface voor een bestaande chatbot. Welke technische doorbraken zijn nog nodig voordat voice‑agenten een primaire interface kunnen worden voor complexe, realtime interacties, met name in omgevingen zoals stadions, attracties en live‑evenementen?

Veel klanten vragen: kun je gewoon de chat‑applicatie nemen en er voice in pluggen? Dat kunnen we. Maar dat betekent niet dat het een goede ervaring wordt. De volgende echte verbetering is niet een menselijker klinkende stem. Het is een interactie die de omstandigheden waarin mensen het daadwerkelijk gebruiken, overleeft.

In een stadion praat iemand over het geluid van de menigte, gebruikt een onbekende spelersnaam, verandert halverwege een zin van gedachten en probeert een aankoop af te ronden voordat de poorten opengaan. Het systeem moet onderbrekingen, onzekerheid en backend‑vertragingen afhandelen zonder de taak te verliezen.

Let vooral veel aandacht aan kritieke details. Een informele uitdrukking verkeerd horen is één ding. Het aantal tickets of de datum van het evenement verkeerd horen is iets anders. De agent moet de details bevestigen die de consequentie van de actie veranderen, zonder het hele gesprek saai te maken.

En stem mag niet gedwongen worden om alles te doen. Het vergelijken van twintig zitopties is beter op een scherm. Iemand kan beginnen met typen, in de auto stappen en dezelfde conversatie willen voortzetten door te spreken. Het systeem moet die context behouden en stem, tekst en beeld gebruiken op de manier die het moment het beste past.

Een deel hiervan heeft betere modellen nodig. Een groot deel heeft betere integratie en interactieontwerp nodig. Wachten op een doorbraak zal een workflow die rond tekst is ontworpen en vervolgens hardop wordt voorgelezen, niet oplossen. Ik zou vooruitgang op één manier beoordelen: voltooien mensen de taak nauwkeurig, met minder inspanning, onder realistische omstandigheden?

Naarmate agenten evolueren van het verstrekken van informatie naar het verkopen van tickets, het verzamelen van klantgegevens, het personaliseren van ervaringen en het interactief werken met operationele systemen, hoe moeten bedrijven bepalen welke beslissingen een agent autonoom kan nemen en welke altijd menselijke supervisie vereisen?

Het is risicobeheer. Als dit misloopt, welke schade kan het veroorzaken? Opent de agent een deur die hij niet kan sluiten?

Omkeerbaarheid is een nuttige eerste test, maar kijk ook naar de totale blootstelling. Eén terugbetaling kan klein en omkeerbaar zijn. Tienduizend onjuiste terugbetalingen voordat iemand het opmerkt, is een ander probleem. Je hebt limieten nodig voor individuele acties en voor de cumulatieve activiteit van het systeem.

Als de actie laag risico en omkeerbaar is, geef dan meer autonomie: een voorkeur bijwerken, een bestelling controleren, een artikel reserveren. Naarmate de consequenties toenemen, voeg bevestiging of goedkeuring toe. Een aankoop kan vereisen dat de klant de prijs bevestigt. Een grote terugbetaling kan een handtekening van een medewerker nodig hebben. Een veiligheidsdreiging wordt onmiddellijk geëscaleerd. En sommige beslissingen moeten gewoon bij een persoon blijven, punt.

Klanteninstemming en bedrijfsgoedkeuring zijn verschillende zaken, trouwens. Een klant die een aankoop bevestigt, machtigt de agent niet om het bedrijfsbeleid te omzeilen. Een medewerker die een uitzondering goedkeurt, betekent niet dat de klant akkoord gaat met een kostenpost.

De limieten moeten worden afgedwongen door de systemen die de actie uitvoeren, niet alleen beschreven in een prompt. Je geeft een agent geen brede toegang en vertrouwt vervolgens op een prompt die hem voorzichtig moet laten handelen. En wanneer een persoon nodig is, geef die dan voldoende context om een echte beslissing te nemen. Geef iemand honderden goedkeuringen zonder informatie, en je hebt een rubberstempel gebouwd, geen toezicht. Richt menselijke aandacht op plaatsen waar het een betekenisvol risico vermindert. Verspreid het niet dun over elke interactie.

Kijkend naar de toekomst, verwacht je dat technologieën zoals het Model Context Protocol en agent-naar-agent communicatie fundamenteel zullen veranderen hoe enterprise‑AI‑systemen worden gebouwd, en ons verplaatsen van geïsoleerde agenten naar ecosystemen waarin agenten tools kunnen ontdekken, context kunnen uitwisselen en acties kunnen coördineren over bedrijven en platformen heen?

Ik denk dat de protocollen een middel tot een doel zijn. MCP biedt AI‑toepassingen een gemeenschappelijke manier om toegang te krijgen tot tools en context. Agent‑naar‑agent protocollen regelen samenwerking tussen agenten. Dat is waardevol. Je zou niet elke keer een aangepaste integratie moeten bouwen wanneer een agent een tool nodig heeft. Het is vergelijkbaar met wat API’s deden voor software‑integraties.

Maar een gemeenschappelijk formaat betekent niet dat twee bedrijven het eens zijn over wat een actie betekent, wie het kan autoriseren, of wat er gebeurt als het mislukt. Alleen omdat een agent een tool kan ontdekken, betekent niet dat hij deze mag gebruiken. Je moet nog steeds identiteit, permissies, vertrouwen en verantwoordelijkheid uitzoeken. Als een agent een andere vraagt iets te doen en het gaat mis, wie draagt dan de verantwoordelijkheid?

Dit is wat ik denk dat daadwerkelijk verandert. Vandaag heeft een locatie een website en een app. Over een paar jaar zal ze een agent hebben waar andere agenten mee onderhandelen. De persoonlijke assistent van een fan vraagt de agent van de locatie om twee plaatsen onder een bepaalde prijs, plus een parkeerticket, en de hele transactie gebeurt tussen de twee agenten. Het vinden van de juiste mogelijkheden is de gemakkelijke stap. Het kennen van de bestedingsautoriteit van de klant, het bevestigen van de gecombineerde prijs, en het afhandelen van het geval waarin de tickets wel lukken maar het parkeren mislukt, dat zijn de echte problemen.

En ik geloof niet dat het exploiteren van een agent automatisch de klantrelatie aan jou overdraagt. Dat moet verdiend worden. Maar ik geloof ook niet dat locaties deze transacties gaan overdragen aan een zoekbedrijf of een ticketmarktplaats. Ons doel bij Satisfi Labs is om de agent te zijn die de locatie vertegenwoordigt in die economie, de enige die betrouwbaar genoeg is zodat een bedrijf er zijn naam op zet. Alles wat we hebben opgebouwd rond betrouwbaarheid, permissies en verantwoordelijkheid is wat die positie verdient.

Bedankt voor het geweldige interview, lezers die meer willen weten, kunnen terecht bij Satisfi Labs.