Andrew Missey, CTO en mede-oprichter van Convos – Interviewreeks

Andrew Missey, CTO en mede-oprichter van Convos, is een software-ingenieur en productleider met ervaring op het gebied van AI-productontwikkeling, software-architectuur, netwerken en full-stack-engineering. Voordat hij Convos mede-oprichtte, hielp hij bij de ontwikkeling en lancering van twee AI-gebaseerde creatieve en marketingplatforms bij Forum3, waarbij hij hands-on-engineering combineerde met technisch productbeheer. Zijn eerdere rollen bij N-able (NABL ) , Autoshop Solutions en Brand IQ omvatten het bouwen van frontend-toepassingen, backend-systemen, clientdashboards en interne softwaretools met behulp van technologieën zoals Svelte, NestJS, Angular en JavaScript. Deze multidisciplinaire achtergrond heeft het hem mogelijk gemaakt om technische uitvoering te combineren met productstrategie terwijl hij de ontwikkeling van Convos’ AI-gedreven communicatieplatform leidt.

Convos is een gecontroleerd AI-gebaseerd tekstberichtensysteem dat is ontworpen om politieke campagnes en communicatiebureaus te helpen éénrichtingsmassaberichten te vervangen door persoonlijke, tweerichtingsgesprekken met kiezers op grote schaal. Het platform zet antwoorden om in real-time sentimentanalyse, onderwerpklassificaties, call-to-actionresultaten, betrokkenheidsmetrieken en gestructureerde kiezersinformatie die campagnes kunnen gebruiken om hun benadering te verfijnen. De gesloten systeem-AI werkt binnen campagne-goedgekeurde materialen en berichtengrenzen, terwijl het functies biedt zoals contactsegmentatie, conversatiegeschiedenis, linkvolging, gegevensexport en compliance-gerichte audittrails. Convos kan ook een organisatie’s bestaande tekstberichtensysteem aanvullen in plaats van te vereisen dat het de huidige communicatiesystemen vervangt.

U hebt Convos mede-opgericht nadat u had gezien hoe politieke en organisatorische tekstberichten grotendeels éénrichtingscommunicatie waren geworden. Wat was de oorspronkelijke inzicht die u ervan overtuigde dat er een mogelijkheid was om massatekstberichten te transformeren in AI-gedreven gesprekken, en wat waren de grootste technische uitdagingen die u tegenkwam bij de bouw van het platform?

Het inzicht kwam vanuit het feit dat ik aan de ontvangende kant ervan stond.

Rond de verkiezingen van 2024 kreeg ik een overvloed aan politieke teksten, net als veel andere mensen. Op een gegeven moment begon ik te reageren op die teksten. Ik stelde een vraag of reageerde, en nooit kwam er een reactie. De berichten gingen uit in het miljoenen, maar op het moment dat je probeerde een echte uitwisseling te hebben, was er niemand aan de andere kant.

Het trof me als een enorme gemiste kans. De persoon aan de andere kant was al betrokken. Ze stelden een echte vraag. Maar nooit zou er een reactie worden gestuurd.

Dus het idee achter Convos was eenvoudig. Verander de uitzending in een echt gesprek, op grote schaal, zonder dat je een kamer vol mensen nodig hebt om het te bemannen.

De grootste technische uitdagingen kwamen neer op drie dingen: schaal, latentie en compliance.

Schaal is de meest voor de hand liggende. Je bent duizenden gesprekken tegelijk aan het beheren, en elk gesprek heeft zijn eigen staat en geschiedenis. Latentie is belangrijker dan mensen verwachten. Als iemand terugschrijft en het antwoord te lang duurt, is het moment voorbij. Tekstberichten voelen bijna onmiddellijk, en de ervaring moet daarbij aansluiten.

Compliance was het moeilijkste deel, en dat was iets waar we vanaf het begin prioriteit aan gaven. Politieke tekstberichten zijn zwaar gereglementeerd, en het verkeerd doen is geen optie. Een groot deel van onze vroege engineeringsinspanningen ging naar het zorgen dat het systeem binnen de boodschap bleef en toestemming en opt-outs respecteerde op manieren die verder gaan dan alleen het woord “STOP” te vangen.

Convos werkt op het snijvlak van conversational AI, grootschalige berichtgeving en real-time sentimentanalyse. Wat zijn de lessen die u heeft geleerd van het inzetten van AI-systemen die duizenden mensen tegelijk moeten betrekken en toch persoonlijk en authentiek moeten aanvoelen?

De belangrijkste les is dat “persoonlijk op grote schaal” iets is waar je voor moet engineereren. Het gebeurt niet vanzelf.

Wanneer je duizenden gesprekken tegelijk uitvoert, is de verleiding groot om ze als één grote batch te behandelen. Maar de persoon die de tekst ontvangt, maalt niet om uw batch. Voor hen is het een één-op-één-uitwisseling, en het moet zo aanvoelen. Dat betekent dat elk gesprek zijn eigen context en geschiedenis moet hebben, zodat een reactie daadwerkelijk reageert op wat die specifieke persoon zei, en niet op een gemiddelde van iedereen.

We hebben ook geleerd om goed te letten op wat mensen ons echt vertellen. Een reactie is niet alleen een reactie. Het draagt sentiment. Iemand kan reageren met een vraag, met enthousiasme, met frustratie of met een duidelijk signaal dat ze met rust gelaten willen worden. Die nuances correct lezen is wat een interactie maakt of breekt.

Uiteindelijk komt authenticiteit voort uit luisteren, niet uit slim klinken. De uitwisseling die het meest menselijk aanvoelt, is degene die het echte antwoord geeft en de tijd van de persoon respecteert.

U hebt betoogd dat veel organisaties te veel focus leggen op modelbenchmarks en de persoonlijkheid en communicatiestijl van de agent over het hoofd zien. Waarom denkt u dat persoonlijkheid een kritische factor wordt in de inzet van enterprise AI, en hoe moeten organisaties deze evalueren?

Benchmarks meten capaciteit. Ze meten geen fit.

Een model kan extreem goed scoren op redeneren of coderen en nog steeds de verkeerde keuze zijn voor een gesprek met een kiezer. De manier waarop het dingen formuleert, hoe warm of formeel het klinkt, of het weet wanneer het kort moet zijn, dat alles is enorm belangrijk zodra een echte persoon aan de andere kant zit.

In onze wereld lost het model geen wiskundig probleem op. Het vertegenwoordigt een campagne in een tekstbericht. Elke campagne heeft zijn eigen stem, en het model moet die stem overnemen in plaats van zijn eigen stem op te dringen. Als de toon verkeerd is, maakt het niet uit hoe slim het onderliggende model is. De interactie faalt.

Er is ook een capaciteitskant aan dit verhaal die benchmarks missen. Een campagne kan de agent gedetailleerde instructies geven over wat te zeggen, wat te vermijden en hoe specifieke onderwerpen aan te pakken. Het model moet al die instructies volgen, consistent, gedurende een langdurig gesprek. Sommige modellen zijn veel beter dan andere in het vasthouden van complexe instructies zonder af te dwalen halverwege het gesprek. Die capaciteit is ook onderdeel van persoonlijkheid, omdat een model dat goed klinkt maar stopt met het volgen van zijn instructies, geen model is dat je voor echte mensen kunt zetten.

Dat is waarom persoonlijkheid een echte factor wordt in enterprise-inzet. Naarmate modellen over het algemeen capabeler worden, neemt de capaciteitskloof tussen hen af. Wat overblijft, is karakter. Hoe ze communiceren en of ze binnen de lijnen blijven die je voor hen hebt getrokken.

De manier om dit te evalueren is niet op een leaderboard. Het is om modellen te testen op uw eigen gebruikscase, met uw eigen inhoud, en de uitvoer te lezen zoals uw eindgebruiker dat zou doen. We zetten modellen door exact het soort uitwisselingen die ze in productie zullen afhandelen en beoordelen ze op of het gesprek goed aanvoelt. Dat vertelt je veel meer dan een benchmarkscore ooit zal doen.

Uw team heeft meerdere toonaangevende modellen getest en aanzienlijke verschillen gezien in hoe ze presteren over taken. Wat heeft u geleerd over de sterke en zwakke punten van de huidige grote LLM’s, en waarom zijn sommige beter geschikt voor conversational work dan anderen?

Wat we hebben geleerd, is dat er geen enkel beste model is. Er is alleen het beste model voor een bepaalde taak.

Sommige modellen zijn uitstekend in het precies volgen van instructies, wat ertoe doet wanneer het systeem binnen strikte grenzen moet blijven. Sommige zijn sterker in natuurlijke, conversational toon. Sommige zijn sneller, wat op zich een kracht is wanneer latentie deel is van de ervaring. Andere zijn beter in redeneren door een ingewikkeld verzoek, maar voelen stijf of nemen te lang om te reageren in een informele uitwisseling.

Voor conversational work specifiek zijn de kwaliteiten die ertoe doen niet altijd degenen die de headlines halen. Snelheid is belangrijk. Consistentie is belangrijk. Wetende wanneer je kort moet zijn, is belangrijk. Een model dat een prachtig drie-aline antwoord schrijft, is vaak de verkeerde keuze wanneer het juiste antwoord één zin is.

Niets van dit alles komt op een leaderboard te staan. Je leert het alleen door modellen voor het echte werk te zetten en te letten op hoe ze het aanpakken.

Veel bedrijven gaan steeds meer een multi-modelstrategie hanteren in plaats van afhankelijk te zijn van één AI-aanbieder. Wat zijn de voordelen van het bouwen van systemen die tussen modellen kunnen schakelen, en welke architectonische overwegingen zijn nodig om dit mogelijk te maken?

Het belangrijkste voordeel is dat je niet vastzit.

Als je alles rond één aanbieder bouwt, erf je al hun beperkingen. Hun prijzen, hun limieten, hun latentie, hun uitval en hun releasedatum worden de jouwe. Een multi-modelbenadering laat je elke taak naar het model sturen dat het het beste afhandelt, en het geeft je ergens om naartoe te gaan wanneer één aanbieder een slechte dag heeft.

Het laat je ook toe om de kosten aan de taak aan te passen. Niet elke interactie heeft je meest krachtige en duurste model nodig. In staat zijn om het eenvoudige werk naar een lichter model te sturen en het zware model te reserveren voor de moeilijke gevallen, maakt een groot verschil op grote schaal.

De architectuur is wat dit mogelijk maakt, en de sleutelbeslissing is om een abstractielaag te bouwen tussen uw toepassing en een specifiek model. Uw systeem moet niet rechtstreeks met de API van één aanbieder praten door de hele codebase heen. Het moet met uw eigen interne interface praten, en die interface beslist welk model de aanvraag daadwerkelijk afhandelt.

Zodra je dat hebt, kun je routeringslogica toevoegen, fallbacks wanneer een aanbieder faalt, en de mogelijkheid om modellen te wisselen zonder uw toepassing opnieuw te schrijven. Je hebt ook consistent afhandelen van prompts en uitvoer over modellen heen nodig, omdat elk model een beetje anders gedraagt, en uw systeem moet die verschillen gladstrijken.

Het is meer werk van tevoren. Maar het koopt je flexibiliteit die heel moeilijk later toe te voegen is.

U hebt onlangs benadrukt hoe snel AI-modellen evolueren, met nieuwe releases die soms de prestatiekenmerken op onverwachte manieren veranderen. Hoe moeten bedrijven de wens om de laatste modellen te adopteren in evenwicht brengen met de behoefte aan stabiliteit, betrouwbaarheid en voorspelbare prestaties?

Het eerlijke antwoord is dat een nieuwe model geen upgrade is totdat je hebt bewezen dat het een upgrade is.

Elke release is spannend, en er is echte druk om de laatste versie meteen te adopteren. Maar we hebben gezien dat nieuwe modellen zich op manieren gedragen die we niet verwachtten. Iets dat betrouwbaar werkte, begon plotseling anders te reageren, en in een productiesysteem tellen die kleine veranderingen op.

De manier waarop we dit aanpakken is eenvoudig. Geen enkel model gaat in onze pipeline totdat we het zelf handmatig hebben getest. Wanneer een nieuwe release uitkomt, nemen we de benchmarks of de aankondiging niet voor waar aan. We gaan zitten en voeren het door zijn paces op het exacte type conversaties dat het in productie zou afhandelen, en we lezen de uitvoer zelf.

Die handmatige stap is niet optioneel voor ons. Een model kan er op papier beter uitzien en nog steeds een echte uitwisseling op een manier afhandelen die we niet comfortabel zijn om voor kiezers te zetten. De enige manier om het te weten is om het door dezelfde situaties te voeren die ons systeem elke dag tegenkomt en te zien hoe het daadwerkelijk reageert.

Dit is nog een plek waar de abstractielaag zijn waarde verdient. Omdat onze toepassing niet afhankelijk is van een specifiek model, kunnen we een nieuwe release binnenhalen, deze testen tegen de conversaties die we daadwerkelijk afhandelen, en het eerlijk vergelijken met wat we al draaien. Als het de lat haalt, schakelen we over. Als het niet haalt, wachten we.

Hallucinaties blijven een van de grootste barrières voor de adoptie van enterprise AI, vooral wanneer modellen werken met grote datasets en complexe informatie. Wat zijn de praktische technieken die het meest effectief zijn gebleken in het reduceren van hallucinaties in productieomgevingen?

De meest effectieve techniek die we hebben gevonden is om te beperken wat het model mag weten.

Veel hallucinaties komen voort uit het vragen van een model om te antwoorden vanuit zijn eigen algemene kennis, waar het graag gaten zal opvullen met iets dat goed klinkt. We doen het tegenovergestelde. Onze AI werkt strikt vanuit de informatie die de campagne heeft verstrekt. Het heeft geen toegang tot het open internet, en het put niet uit een vaag geheugen van de wereld.

Als het antwoord niet in het materiaal zit dat het is gegeven, is de juiste reactie om te zeggen dat het die informatie niet heeft. Die enkele grens verwijdert een enorm risico.

We stoppen daar niet mee. We hebben meerdere controles in plaats om ervoor te zorgen dat een reactie overeenkomt met wat de campagne heeft verstrekt. Zelfs nadat het model een reactie heeft gegenereerd, wordt die reactie nog steeds gecontroleerd op de informatie van de campagne voordat het ergens naartoe gaat. Als iets niet in de lijn ligt, wordt het niet verstuurd.

Verder zijn de praktische technieken over het gronden en het stellen van grenzen. Geef het model de specifieke, relevante context die het nodig heeft voor de taak die voorligt, in plaats van een grote, ongedifferentieerde berg data. Hoe gefocuster de informatie, hoe minder ruimte er is om af te dwalen.

We stellen ook duidelijke limieten aan wat het systeem mag doen en zeggen, en we monitoren echte conversaties in plaats van aan te nemen dat alles in orde is. Je vangt problemen niet door het model te vertrouwen. Je vangt ze door naar de uitvoer te kijken.

In een gereguleerde ruimte als politieke tekstberichten is een verzonnen antwoord een aansprakelijkheid, dus hebben we het systeem ontworpen om transparantie te bevorchten boven gokken.

Als organisaties AI-agents inzetten over klantenservice, communicatie, marketing en operaties, welke fouten ziet u teams herhaaldelijk maken bij het overgaan van pilotprojecten naar productie-uitrol?

De fout die ik het meest zie, is dat teams testen of hun agent werkt, maar niet of het kan worden gebroken.

Ik kan niet tellen hoe vaak een bedrijf een AI-chatbot heeft uitgebracht, en binnen een dag heeft iemand online het gebroken en het zover gekregen dat het iets zei wat het nooit had moeten zeggen. Het wordt uit zijn instructies getrokken, in de war gebracht, of gemanipuleerd om de merknaam op een manier te vertegenwoordigen die uiteindelijk als screenshot wordt doorgegeven.

Dat gebeurt omdat in een pilot iedereen zich goed gedraagt. Je test de agent met redelijke mensen die redelijke vragen stellen, en het ziet er geweldig uit. Productie is het tegenovergestelde. Het moment dat iets openbaar is, probeert een deel van de mensen die er mee praten het te breken.

Als je niet getest hebt op die tegenovergestelde casus, heb je het niet echt getest. Je moet proberen je eigen systeem te breken voordat iemand anders dat doet. Duw het, voer het rare en vijandige invoer in, en zie of het zijn grenzen in acht neemt wanneer iemand er actief tegen werkt.

De andere herhaalde fout is aan te nemen dat een demo die werkt een systeem is dat werkt. Een pilot is een handvol gecontroleerde conversaties op het happy path. Productie is duizenden mensen op alle uren die zich op manieren gedragen die je niet had voorzien, en de edge cases die je wegwuifde worden dagelijkse gebeurtenissen op grote schaal.

Mijn advies is om minder tijd te besteden aan het perfectioneren van de demo en meer tijd te besteden aan het proberen te breken van de dingen zelf. Als het niet kan overleven dat je het aanvalt, zal het niet overleven om openbaar te zijn.

AI-agents worden steeds capabeler om gesprekken te hanteren die eerder menselijke medewerkers vereisten. Waar ziet u de balans tussen automatisering en menselijke toezicht over de komende vijf jaar, en welke workflows moeten altijd een mens in de lus houden?

Dit is een moeilijke vraag, en ik denk niet dat iemand echt weet waar de lijn in vijf jaar zal liggen. De manier waarop ik erover nadenk, is dat de echte waarde van AI als een vermenigvuldigingsfactor werkt. Het laat een kleine groep mensen veel meer doen dan ze ooit alleen zouden kunnen.

De teams die het meest uit deze tools halen, gebruiken ze precies zo. De AI neemt het volume en de herhaling voor zijn rekening, en de mensen besteden hun tijd aan oordeel, strategie en situaties die echt een mens nodig hebben. Dat is een heel andere doelstelling dan proberen mensen uit het plaatje te verwijderen.

Wanneer het doel pure vervanging is, duw je de technologie voorbij wat het echt goed is, en faalt het op manieren die zichtbaar en duur zijn. Wanneer het doel is om je mensen te vermenigvuldigen, laat je de AI doen wat het goed doet en houd je mensen waar ze de meeste waarde toevoegen. De tweede aanpak werkt beter, en het is eerlijker over waar de technologie nu echt is.

Over de komende vijf jaar verwacht ik dat agents meer en meer van de routineconversatielast overnemen, en dat zouden ze moeten doen. Dat werk heeft geen mens nodig die elke zin in de gaten houdt.

De workflows die altijd een mens in de lus moeten houden, zijn die waarbij de inzet hoog is of de situatie echt nieuw is. Alles wat te maken heeft met toestemming, compliance of een beslissing die moeilijk terug te draaien is. Een persoon moet de richting bepalen, en de AI moet helpen om veel meer terrein te bestrijken dan ze anders zouden kunnen.

Kijkend naar de toekomst, welke ontwikkelingen in conversational AI zijn u het meest enthousiast over, en hoe ziet u platforms als Convos evolueren naarmate modellen capabeler, multimodaal en autonoom worden?

Wat me het meest enthousiast maakt, is dat de conversaties steeds beter zullen worden.

Naarmate modellen verbeteren, worden de uitwisselingen die ons platform afhandelt, natuurlijker en nuttiger zonder dat we de basis elke keer opnieuw hoeven op te bouwen. Omdat we het systeem hebben ontworpen om tussen modellen te schakelen, kunnen we die verbeteringen binnenhalen zodra ze beschikbaar komen.

Multimodaal is de ontwikkeling die ik het meest in de gaten houd. Op dit moment is de conversatie tekst. Naarmate modellen beter omgaan met afbeeldingen en andere formaten, is er een echte kans om deze uitwisselingen rijker te maken terwijl de onmiddellijkheid die tekstberichten zo goed maakt, behouden blijft.

Over autonomie ben ik optimistisch maar voorzichtig. Krachtigere agents worden maandelijks uitgebracht, en ze zullen in staat zijn om veel zelf te doen. Maar in een gereguleerde ruimte moet meer autonomie samengaan met meer discipline, niet minder. De grenzen zijn belangrijker naarmate de capaciteit groeit.

Ik ben in dit vak gestapt omdat ik de persoon was die in de leegte tekstberichtjes stuurde en nooit antwoord kreeg. Dat is nog steeds het probleem waar ik het meest om geef. Hoe capabel deze modellen ook worden, de maatstaf waar ik steeds weer naar terugkeer, is eenvoudig. Voelt de persoon aan de andere kant gehoord?

Bedankt voor het geweldige interview, lezers die meer willen leren, moeten Convos bezoeken.