Andrew Missey, CTO och medgrundare av Convos – Intervjuserie

Andrew Missey, CTO och medgrundare av Convos, är en programvaruutvecklare och produktledare med erfarenhet som spänner över AI-produktutveckling, programvaruarkitektur, nätverk och fullstack-utveckling. Innan han co-founderade Convos hjälpte han till att utveckla och lansera två AI-drivna kreativa och marknadsplattformar på Forum3, som kombinerade hands-on-utveckling med teknisk produktledning. Hans tidigare roller på N-able (NABL ), Autoshop Solutions och Brand IQ involverade byggnad av frontend-applikationer, backend-system, klientdashboards och interna mjukvaruverktyg med tekniker inklusive Svelte, NestJS, Angular och JavaScript. Denna multidisciplinära bakgrund har möjliggjort för honom att kombinera teknisk genomförande med produktstrategi när han leder utvecklingen av Convos AI-drivna kommunikationsplattform.

Convos är en kontrollerad AI-driven textplattform som är utformad för att hjälpa politiska kampanjer och kommunikationsföretag att ersätta enkelriktad massmeddelanden med personliga, tvåvägskonversationer i stor skala. Plattformen konverterar svar till realtidsanalys av sentiment, ämnesklassificering, call-to-action-resultat, engagemangsmått och strukturerad väljarinsikt som kampanjer kan använda för att förbättra sin räckvidd. Dess stängda system AI fungerar inom kampanjgodkända material och meddelandegarder, samtidigt som den tillhandahåller funktioner som kontaktsegmentering, konversationshistorik, länkspårning, dataexport och regelefterlevnadskontroller. Convos kan också komplettera en organisations befintliga textinfrastruktur i stället för att kräva att den ersätter sina nuvarande kommunikationssystem.

Du co-founderade Convos efter att ha observerat hur politisk och organisatorisk texting hade blivit i huvudsak enkelriktad kommunikation. Vad var den ursprungliga insikten som övertygade dig om att det fanns en möjlighet att förvandla mass-textning till AI-drivna konversationer, och vad var de största tekniska utmaningarna du stött på när du byggde plattformen?

Insikten kom från att vara på mottagarsidan av det.

Runt valet 2024 blev jag bombarderad med politiska textmeddelanden, som många andra. Vid något tillfälle började jag svara på dem. Jag ställde en fråga eller svarade, och ingenting kom tillbaka. Meddelandena skickades ut i miljontal, men i samma ögonblick man försökte ha en riktig utbyte, fanns det ingen där.

Det slog mig som en enorm missad möjlighet. Personen på andra sidan var redan engagerad. De ställde en riktig fråga. Men inget svar skulle någonsin skickas tillbaka.

Så idén bakom Convos var enkel. Förvandla sändningen till en riktig konversation, i stor skala, utan att behöva en hel del människor för att bemanna den.

De största tekniska utmaningarna kom ner till tre saker: skala, latens och regelefterlevnad.

Skala är den uppenbara. Du hanterar tusentals konversationer samtidigt, och var och en har sin egen tillstånd och historia. Latens är viktigare än vad människor förväntar sig. Om någon svarar och svaret tar för lång tid, är ögonblicket borta. Textning känns nästan omedelbar, och upplevelsen måste matcha det.

Regelefterlevnad var den svåraste delen, och det var något vi prioriterade från början. Politisk texting är tungt reglerad, och att göra fel är inte ett alternativ. Mycket av vår tidiga utveckling gick till att se till att systemet stannade på meddelandet och respekterade samtycke och avanmälningar på sätt som går långt utöver att bara fånga ordet “STOP”.

Convos fungerar vid skärningspunkten mellan konversations-AI, storskalig meddelandeöverföring och realtidsanalys av sentiment. Vilka lärdomar har du dragit från att distribuera AI-system som måste engagera tusentals människor samtidigt medan de fortfarande känns personliga och äkta?

Den största lärdomen är att “personlig i skala” är något du måste utveckla för. Det händer inte som standard.

När du kör tusentals konversationer samtidigt är frestelsen att behandla dem som en stor batch. Men personen som tar emot texten bryr sig inte om din batch. För dem är det en enskild utbyte, och det måste kännas så. Det betyder att varje konversation måste ha sin egen kontext och historia, så att ett svar faktiskt svarar på vad den specifika personen sa, inte på någon genomsnitt av alla.

Vi lärde oss också att vara uppmärksamma på vad människor verkligen berättar för oss. Ett svar är inte bara ett svar. Det bär sentiment. Någon kan svara med en fråga, med entusiasm, med frustration eller med en tydlig signal om att de vill lämnas ifred. Att läsa dessa nyanser korrekt är vad som gör eller bryter en interaktion.

Till slut kommer äkthet från att lyssna, inte från att låta klyftig. Utbytet som känns mest mänskligt är det som svarar på den faktiska frågan och respekterar personens tid.

Du har hävdat att många organisationer fokuserar för mycket på modellbenchmarks och försummar personlighet och kommunikationsstil. Varför tror du att personlighet blir en kritisk faktor i företags AI-distribution, och hur bör organisationer utvärdera den?

Benchmarks mäter förmåga. De mäter inte passform.

En modell kan prestera extremt bra på resonemang eller kodning och fortfarande vara fel valet för en konversation med en väljare. Sättet det uttrycker sig, hur varmt eller formellt det låter, om det vet när det ska vara kort, allt detta är enormt viktigt när en riktig person är på andra sidan.

I vår värld löser modellen inte ett matematiskt problem. Det representerar en kampanj i ett textmeddelande. Varje kampanj har sin egen röst, och modellen måste matcha den snarare än påtvinga sin egen. Om tonen är fel, spelar det ingen roll hur smart den underliggande modellen är. Interaktionen misslyckas.

Det finns också en förmågeaspekt som benchmarks missar. En kampanj kan ge agenten detaljerad vägledning om vad den ska säga, vad den ska undvika och hur den ska hantera specifika ämnen. Modellen måste följa allt detta konsekvent, över en lång konversation. Vissa modeller är betydligt bättre än andra på att hålla fast vid komplexa instruktioner utan att glida halvvägs genom konversationen. Den förmågan är också en del av personlighet, eftersom en modell som låter bra men slutar följa sina instruktioner inte är en du kan sätta framför riktiga människor.

Därför blir personlighet en verklig faktor i företagsdistribution. När modeller blir mer kapabla överlag, minskar det råa förmågegapet mellan dem. Vad som är kvar är karaktär. Hur de kommunicerar, och om de stannar inom de ramar du sätter.

Sättet att utvärdera det är inte på en leaderboard. Det är att testa modeller på din faktiska användningsfall, med din faktiska innehåll, och läsa utdata som din slutanvändare skulle. Vi sätter modeller genom exakt samma typer av utbyten som de kommer att hantera i produktion och bedömer dem baserat på om konversationen känns rätt. Det berättar mycket mer än en benchmark-poäng någonsin kommer att göra.

Ditt team har testat flera ledande modeller och observerat betydande skillnader i hur de presterar över uppgifter. Vad har du lärt dig om styrkorna och svagheterna hos dagens stora LLM:er, och varför är vissa bättre lämpade för konversationsarbete än andra?

Vad vi har lärt oss är att det inte finns en enda bästa modell. Det finns bara den bästa modellen för ett visst jobb.

Vissa modeller är utmärkta på att följa instruktioner exakt, vilket är viktigt när systemet måste stanna inom strikta gränser. Vissa är starkare på naturlig, konversationsliknande ton. Vissa är snabbare, vilket är sin egen styrka när latens är en del av upplevelsen. Andra är bättre på att resonera genom en komplicerad begäran men känns stela eller tar för lång tid att svara i en avslappnad konversation.

För konversationsarbete specifikt är de egenskaper som är viktiga inte alltid de som får rubriker. Hastighet är viktigt. Konsekvens är viktigt. Att veta när man ska vara kort är viktigt. En modell som skriver ett vackert treparagrafsvar är ofta fel valet när rätt svaret är en mening.

Inget av detta syns på en leaderboard. Du lär dig det bara genom att sätta modeller framför det faktiska arbetet och vara uppmärksam på hur de hanterar det.

Många företag antar alltmer multi-modellstrategier snarare än att förlita sig på en enda AI-leverantör. Vilka är fördelarna med att bygga system som kan växla mellan modeller, och vilka arkitekturöverväganden krävs för att göra det möjligt?

Den främsta fördelen är att du inte är låst.

Om du bygger allt runt en leverantör, ärver du alla deras begränsningar. Deras prissättning, deras tak, deras latens, deras driftstopp och deras release-schema blir dina. En multi-modellapproach låter dig dirigera varje uppgift till vilken modell som hanterar den bäst, och det ger dig någonstans att gå när en leverantör har en dålig dag.

Det låter dig också matcha kostnaden till jobbet. Inte varje interaktion behöver din kraftfullaste och dyraste modell. Att kunna skicka det enkla arbetet till en lättare modell och reservera den tunga modellen för de hårda fallen gör en verklig skillnad i skala.

Arkitekturen är vad som gör detta möjligt, och den viktigaste beslutet är att bygga ett abstraktionslager mellan din applikation och en specifik modell. Ditt system bör inte prata direkt till en leverantörs API genom hela kodbasen. Det bör prata med ditt eget interna gränssnitt, och det gränssnittet bestämmer vilken modell som faktiskt hanterar begäran.

När du har det kan du lägga till dirigering, fallback när en leverantör misslyckas och förmågan att byta modeller utan att skriva om din applikation. Du behöver också konsekvent hantering av prompter och utdata över modeller, eftersom var och en beter sig lite annorlunda, och ditt system måste jämna ut dessa skillnader.

Det är mer arbete från början. Men det köper dig flexibilitet som är mycket svår att lägga till senare.

Du har nyligen betonat hur snabbt AI-modeller utvecklas, med nya releaser som ibland ändrar prestandaegenskaper på oväntade sätt. Hur bör företag balansera önskan att anta de senaste modellerna med behovet av stabilitet, tillförlitlighet och förutsägbar prestanda?

Det ärliga svaret är att en ny modell inte är en uppgradering tills du har bevisat att det är en.

Varje release är spännande, och det finns ett verkligt tryck på att anta det senaste direkt. Men vi har sett nya modeller ändra beteende på sätt som vi inte förväntade oss. Något som fungerade tillförlitligt börjar svara lite annorlunda, och i ett produktionsystem adderar dessa små förändringar upp sig.

Sättet vi hanterar det är enkelt. Inga modeller går in i vår pipeline förrän vi har testat dem själva. När en ny release kommer ut, tar vi inte benchmarkerna eller tillkännagivandet på deras ord. Vi sätter oss ner och kör det genom dess takt på exakt samma typer av konversationer som det skulle hantera i produktion, och vi läser utdata själva.

Detta hands-on-steg är inte valfritt för oss. En modell kan se bättre ut på papper och fortfarande hantera en riktig konversation på ett sätt som vi inte är bekväma med att sätta framför väljare. Det enda sättet att veta är att sätta det genom samma situationer som vårt system hanterar varje dag och se hur det faktiskt svarar.

Detta är ett annat ställe där abstraktionslagret tjänar sitt syfte. Eftersom vår applikation inte är beroende av en specifik modell, kan vi ta in en ny release, testa den mot de konversationer vi faktiskt hanterar och jämföra den ärligt mot vad vi redan kör. Om den klarar provet, byter vi. Om den inte gör det, väntar vi.

Hallucinationer förblir en av de största hindren för företags AI-antagande, särskilt när modeller arbetar med stora datamängder och komplex information. Vilka praktiska tekniker har visat sig vara mest effektiva för att minska hallucinationer i produktionsmiljöer?

Den mest effektiva tekniken vi har funnit är att begränsa vad modellen är tillåten att veta.

Mycket av hallucinationen kommer från att be en modell att svara från sin egen allmänna kunskap, där den kommer att fylla i luckor med något som låter rätt. Vi gör tvärtom. Vår AI arbetar strikt från den information som kampanjen har tillhandahållit. Den har inte tillgång till den öppna internet, och den drar inte på något vagt minne av världen.

Om svaret inte finns i materialet som det fick, är det korrekta svaret att säga att det inte har den informationen. Den enskilda gränsen tar bort en enorm mängd risk.

Vi slutar inte där, dock. Vi har flera kontroller på plats för att se till att ett svar matchar vad kampanjen tillhandahållit. Även efter att modellen genererar ett svar, kontrolleras svaret mot kampanjens information innan det skickas någonstans. Om något inte stämmer, skickas det inte.

Utöver det är de praktiska teknikerna om att förankra och gardera. Ge modellen den specifika, relevanta kontexten den behöver för uppgiften framför den, snarare än en jättestor, odifferentierad hög med data. Ju mer fokuserad informationen är, desto mindre utrymme finns det att driva.

Vi sätter också tydliga gränser för vad systemet är tillåtet att göra och säga, och vi övervakar riktiga konversationer snarare än att anta att allt är bra. Du fångar inte problem genom att lita på modellen. Du fångar dem genom att titta på utdata.

I en reglerad miljö som politisk texting är ett påhittat svar en skuld, så vi utformade systemet för att föredra transparens framför gissning.

Som organisationer distribuerar AI-agenter över kundsupport, kommunikation, marknadsföring och drift, vilka misstag ser du att team upprepar när de flyttar från pilotprojekt till produktionsdistributioner?

Misstaget jag ser mest är att team testar om deras agent fungerar, men inte om den kan brytas.

Jag kan inte räkna hur många gånger ett företag har släppt en AI-chatbot, och inom en dag har någon online “jailbreakat” den till att säga något den aldrig var tänkt att säga. Det blir lurat ur instruktionerna, trickat till att gå utanför manuset eller manipulerat till att representera varumärket på ett sätt som slutar som en skärmdump som alla delar.

Det händer för att i en pilot är alla väluppförda. Du testar agenten med rimliga människor som ställer rimliga frågor, och det ser bra ut. Produktion är motsatsen. I samma ögonblick något är offentligt, försöker en del av människor som pratar med det aktivt att trippa upp det.

Om du inte har testat för det adversativa fallet, har du inte verkligen testat det. Du måste försöka bryta ditt eget system innan någon annan gör det. Driv det, mata det med de underliga och fientliga inmatningarna, och se om det håller sina gränser när någon aktivt arbetar mot det.

Det upprepade misstaget är att anta att en demo som fungerar är ett system som fungerar. En pilot är en handfull övervakade konversationer på den lyckliga vägen. Produktion är tusentals människor vid alla tider som beter sig på sätt som du inte förväntade dig, och de kanterna du viftade bort blir dagliga händelser i skala.

Mitt råd är att spendera mindre tid på att förbättra demon och mer tid på att försöka bryta saken själv. Om den inte kan överleva att du attackerar den, kommer den inte att överleva att vara offentlig.

AI-agenter blir alltmer kapabla att hantera konversationer som tidigare krävde mänsklig personal. Var ser du balansen mellan automatisering och mänsklig övervakning under de kommande fem åren, och vilka arbetsflöden tror du alltid bör ha en människa i slingan?

Detta är ett svårt ett, och jag tror inte att någon verkligen vet exakt var linjen landar om fem år. Sättet jag tänker på det är att den verkliga värdet av AI är som en multiplikator. Den låter en liten grupp människor göra mycket mer än de någonsin kunde ensamma.

Teamen som får ut mest av dessa verktyg använder dem exakt så. AI hanterar volymen och repetitionen, och människorna tillbringar sin tid på bedömning, strategi och situationer som verkligen behöver en människa. Det är ett mycket annorlunda mål än att försöka ta bort människor från bilden.

När målet är rent ersättning, tenderar du att driva teknologin förbi vad den faktiskt är bra på, och den misslyckas på sätt som är synliga och dyra. När målet är att multiplicera dina människor, låter du AI göra vad den gör bra och håller människor där de lägger till mest värde. Den andra approachen fungerar bättre, och den är mer ärlig om var teknologin verkligen är idag.

Under de kommande fem åren förväntar jag mig att agenter kommer att ta på sig mer och mer av den rutinmässiga konversationsbördan, och de borde. Det arbetet behöver inte en person som tittar på varje ord.

Arbetsflödena som alltid bör ha en människa involverad är de där insatserna är höga eller situationen är genuint ny. Allt som rör samtycke, regelefterlevnad eller ett beslut som skulle vara svårt att gå tillbaka från. En person bör äga riktningen, och AI bör hjälpa dem att täcka mycket mer mark än de annars kunde.

Om du tittar framåt, vilka utvecklingar inom konversations-AI är du mest spänd på, och hur ser du att plattformar som Convos utvecklas när modeller blir mer kapabla, multimodala och autonoma?

Vad som sporrar mig mest är att konversationerna kommer att fortsätta förbättras.

När modeller förbättras, blir utbytena vår plattform hanterar mer naturliga och mer användbara utan att vi behöver bygga om grunden varje gång. Eftersom vi utformade systemet för att flytta mellan modeller, kan vi ta med oss förbättringarna när de anländer.

Multimodal är utvecklingen jag följer mest. Just nu är konversationen text. När modeller hanterar bilder och andra format mer kapabelt, finns det en verklig möjlighet att göra dessa utbyten rikare samtidigt som man behåller den omedelbarhet som gör att textning fungerar.

När det gäller autonomi är jag optimistisk men försiktig. Mer kapabla agenter släpps ut månadsvis, och de kommer att kunna hantera en hel del på egen hand. Men i en reglerad miljö, måste mer autonomi komma med mer disciplin, inte mindre. Gränserna är viktigare när kapaciteten växer.

Jag gick in i detta för att jag var personen som skickade textmeddelanden till tomma intet och inte fick något tillbaka. Det är fortfarande problemet jag bryr mig mest om. Oavsett hur kapabla modellerna blir, är måttet jag fortsätter att komma tillbaka till enkelt. Känner personen på andra sidan att de hörts?

Tack för den underbara intervjun, läsare som vill lära sig mer bör besöka Convos.