Andrew Missey, teknisk direktør og medgrunnlegger av Convos – Intervju-serie

Andrew Missey, teknisk direktør og medgrunnlegger av Convos, er en programvareingeniør og produktleder med erfaring fra AI-produktutvikling, programvarearkitektur, nettverk og full-stack-utvikling. Før han co-grunnla Convos, hjalp han med å utvikle og lansere to AI-drevne kreative og markedsføringsplattformer på Forum3, kombinert med praktisk ingeniørarbeid og teknisk produktledelse. Hans tidligere roller i N-able (NABL ), Autoshop Solutions og Brand IQ omfattet bygging av frontend-applikasjoner, backend-systemer, kundedashboard og interne programværktøy med teknologier som Svelte, NestJS, Angular og JavaScript. Denne multidisiplinære bakgrunnen har gjort det mulig for ham å kombinere teknisk gjennomføring med produktstrategi når han leder utviklingen av Convos’ AI-drevne kommunikasjonsplattform.

Convos er en kontrollert AI-drevet tekstplattform designet for å hjelpe politiske kampanjer og kommunikasjonsfirmaer med å erstatte enveisk massebeskjeder med personlige, toveisk samtaler i stor skala. Plattformen konverterer svar til sanntids-sentimentanalyse, emnekategorisering, call-to-action-resultater, engasjementsmetrikker og strukturerte velgerinsikt som kampanjene kan bruke til å forbedre sin tilnærming. Dens lukkede system AI opererer innenfor kampanje-godkjente materialer og meldingsvegger, samtidig som den tilbyr funksjoner som kontaktsegmentering, samtalehistorikk, link-sporing, dataeksport og overholdelsesfokuserte revisjonslogger. Convos kan også komplettere en organisasjons eksisterende tekst-infrastruktur i stedet for å kreve at de erstatter sine nåværende kommunikasjonssystemer.

Du co-grunnla Convos etter å ha observert hvordan politisk og organisatorisk teksting hadde blitt hovedsakelig enveisk kommunikasjon. Hva var den opprinnelige innsikten som overbeviste deg om at det var en mulighet til å transformere masse-teksting til AI-drevne samtaler, og hva var de største tekniske utfordringene du møtte under byggingen av plattformen?

Innsikten kom fra å være på mottakerenden av det.

Rundt valget i 2024 ble jeg bombardert med politiske tekster, som mange andre. På et tidspunkt begynte jeg å svare på dem. Jeg stilte et spørsmål eller svarte, og ingenting kom noen gang tilbake. Meldingene gikk ut i millioner, men øyeblikket du prøvde å ha en faktisk utveksling, var det ingen der.

Det slo meg som en enorm mulighet som var gått tapt. Personen på den andre enden var allerede engasjert. De stilte et ekte spørsmål. Men ingen respons ville noen gang bli sendt.

Så ideen bak Convos var enkel. Forvandle kringkastingen til en faktisk samtale, i stor skala, uten å trenge et rom fullt av mennesker for å betjene det.

De største tekniske utfordringene kom ned til tre ting: skala, latency og overholdelse.

Skala er det åpenbare. Du håndterer tusenvis av samtaler samtidig, og hver enkelt har sin egen tilstand og historie. Latency betyr mer enn folk forventer. Hvis noen svarer og svaret tar for lang tid, er øyeblikket borte. Teksting føles nesten umiddelbar, og opplevelsen må matche det.

Overholdelse var den hardeste delen, og det var noe vi prioritet fra begynnelsen. Politisk teksting er tungt regulert, og å gjøre det feil er ikke et alternativ. Mye av vår tidlige ingeniørarbeid gikk inn i å sikre at systemet forble på meldingen og respekterte samtykke og opt-out på måter som går langt utenfor bare å fange ordet “STOP”.

Convos opererer på skjæringspunktet mellom konversasjons-AI, stor skala meldinger og sanntids-sentimentanalyse. Hva lærdommer har du tilegnet deg fra å deploye AI-systemer som må engasjere tusenvis av mennesker samtidig mens de fortsatt føles personlige og autentiske?

Den største lærdommen er at “personlig i stor skala” er noe du må ingeniøre for. Det skjer ikke av seg selv.

Når du kjører tusenvis av samtaler samtidig, er fristelsen å behandle dem som en stor batch. Men personen som mottar teksten bryr seg ikke om din batch. For dem er det en en-til-en utveksling, og det må føles sånn. Det betyr at hver samtale må bære sin egen kontekst og historie, så et svar faktisk svarer på hva den spesifikke personen sa, ikke på noen gjennomsnitt av alle.

Vi lærte også å være meget oppmerksomme på hva folk faktisk forteller oss. Et svar er ikke bare et svar. Det bærer sentiment. Noen kan svare med et spørsmål, med entusiasme, med frustrasjon eller med et klart signal om at de vil bli værende alene. Å lese disse nuansene riktig er det som gjør eller ødelegger en interaksjon.

Til slutt kommer autentisitet fra å lytte, ikke fra å lyde klokke. Utvekslingen som føles mest menneskelig er den som svarer på det faktiske spørsmålet og respekterer personens tid.

Du har argumentert for at mange organisasjoner fokuserer for mye på modell-benchmarks mens de overseer personlighet og kommunikasjonsstil. Hvorfor tror du personlighet blir en kritisk faktor i bedrifts-AI-utvikling, og hvordan bør organisasjoner evaluere det?

Benchmarks måler evne. De måler ikke passform.

En modell kan score ekstremt godt på resonnering eller kode og likevel være feil valg for en samtale med en velger. Måten den formulerer ting, hvor varm eller hvor formell den lyder, om den vet når den skal være kort, allt dette betyr enormt en gang en ekte person er på den andre enden.

I vår verden løser modellen ikke et matematisk problem. Den representerer en kampanje i en tekstmelding. Hver kampanje har sin egen stemme, og modellen må matche den i stedet for å påtvinge sin egen. Hvis tonen er feil, betyr det ikke hvor smart den underliggende modellen er. Interaksjonen feiler.

Det er også en evne-side til dette som benchmarks overseer. En kampanje kan gi agenten detaljert veiledning om hva den skal si, hva den skal unngå og hvordan den skal håndtere bestemte emner. Modellen må følge alle disse instruksjonene konsekvent, over en lang samtale. Noen modeller er mye bedre enn andre til å holde på komplekse instruksjoner uten å glide halvveis gjennom samtalen. Denne evnen er også en del av personlighet, fordi en modell som lyder fantastisk men stopper å følge sine instruksjoner, er ikke en du kan sette foran ekte mennesker.

Det er derfor personlighet blir en reell faktor i bedrifts-utvikling. Etterhvert som modellene blir mer kapable, smalner gapet mellom dem. Hva som er igjen er karakter. Hvordan de kommuniserer, og om de holder seg innenfor linjene du setter.

Måten å evaluere det på er ikke på en leaderboard. Det er å teste modellene på din faktiske brukstilfelle, med din faktiske innhold, og lese utdataene slik din sluttbruker ville. Vi setter modellene gjennom eksakt samme type utvekslinger de vil håndtere i produksjon og dømmer dem på om samtalen føles riktig. Det forteller deg langt mer enn en benchmark-score noen gang vil.

Ditt team har testet flere ledende modeller og observert betydelige forskjeller i hvordan de utfører seg over oppgaver. Hva har du lært om styrkene og svakhetene til dagens største LLM-er, og hvorfor er noen bedre egnet for konversasjonsarbeid enn andre?

Hva vi har lært er at det ikke finnes en enkelt best modell. Det finnes bare den beste modellen for en gitt jobb.

Noen modeller er utmerkede til å følge instruksjoner nøyaktig, noe som betyr når systemet må holde seg innenfor strenge grenser. Noen er sterkere på naturlig, konversasjons-tone. Noen er raskere, noe som er sin egen styrke når latency er en del av opplevelsen. Andre er bedre til å resonere gjennom et komplisert forespørsel, men føles stive eller tar for lang tid til å svare i en uformell utveksling.

For konversasjonsarbeid spesifikt, er det kvalitetene som betyr noe, ikke alltid de som får overskrifter. Fart betyr noe. Konsistens betyr noe. Å vite når å være kort betyr noe. En modell som skriver en vakker tre-paragraphers svar er ofte feil valg når det riktige svaret er en setning.

Ingen av dette vises på en leaderboard. Du kan bare lære det ved å sette modellene foran det faktiske arbeidet og være oppmerksom på hvordan de håndterer det.

Mange selskaper adopterer stadig fler-modell-strategier i stedet for å være avhengig av en enkelt AI-leverandør. Hva er fordelene med å bygge systemer som kan skifte mellom modeller, og hva er de arkitektoniske overvegelsene som kreves for å gjøre det mulig?

Den største fordelen er at du ikke er låst.

Hvis du bygger alt rundt en leverandør, arver du alle deres begrensninger. Deres prising, deres ratelimit, deres latency, deres nedtider og deres utgivelsesplan blir dine. En fler-modell-tilnærming lar deg sende hver oppgave til hvilken som helst modell som håndterer det best, og det gir deg et sted å gå når en leverandør har en dårlig dag.

Det lar deg også matche kostnaden til jobben. Ikke hver enkelt interaksjon trenger din mest powerful og dyreste modell. Å kunne sende det enkle arbeidet til en lettere modell og reservere den tunge modellen for de harde sakene gjør en reell forskjell i stor skala.

Arkitekturen er det som gjør dette mulig, og den viktigste avgjørelsen er å bygge en abstraksjonslag mellom din applikasjon og en spesifikk modell. Din system skal ikke snakke direkte til en leverandørs API gjennom hele kodebasen. Den skal snakke til din egen interne grensesnitt, og det grensesnittet bestemmer hvilken modell som faktisk håndterer forespørselen.

En gang du har det, kan du legge til ruting-logikk, fallback når en leverandør feiler, og evnen til å bytte modeller uten å omskrive din applikasjon. Du må også ha konsekvent håndtering av promter og utdata over modeller, fordi hver enkelt oppfører seg litt annerledes, og din system må glatte over disse forskjellene.

Det er mer arbeid oppover. Men det kjøper deg fleksibilitet som er svært vanskelig å legge til senere.

Du har nylig fremhevet hvordan raskt AI-modeller utvikler seg, med nye utgivelser som noen ganger endrer ytelsesegenskaper på uventede måter. Hvordan bør bedrifter balansere ønsket om å adoptere de siste modellene med behovet for stabilitet, pålitelighet og forutsigbar ytelse?

Det ærlige svaret er at en ny modell ikke er en oppgradering før du har bevist at det er en.

Hver utgivelse er spennende, og det er virkelig press for å adoptere det siste med en gang. Men vi har sett nye modeller endre atferd på måter vi ikke forventet. Noe som fungerte pålitelig begynte å svare litt annerledes, og i et produksjonssystem adderer disse små endringene seg opp.

Måten vi håndterer det på er enkel. Ingen modell går inn i vår pipeline før vi har håndtestet den selv. Når en ny utgivelse kommer ut, tar vi ikke benchmarkene eller annonseringen på deres ord. Vi setter oss ned og kjører den gjennom dens plass i de eksakte typene samtaler den ville håndtere i produksjon, og vi leser utdataene selv.

Denne hånd-testede steg er ikke valgfri for oss. En modell kan se bedre ut på papir og likevel håndtere en ekte utveksling på en måte vi ikke er komfortable med å sette foran velgere. Den eneste måten å vite er å sette den gjennom de samme situasjonene vårt system håndterer hver dag og se hvordan den faktisk svarer.

Dette er et annet sted hvor abstraksjonslaget tjener sin del. Fordi vår applikasjon ikke er avhengig av en spesifikk modell, kan vi ta inn en ny utgivelse, teste den mot samtaler vi faktisk håndterer, og sammenligne den ærlig mot det vi allerede kjører. Hvis den klarer å nå målet, bytte vi. Hvis den ikke gjør det, venter vi.

Hallusinasjoner forblir en av de største hindringene for bedrifts-AI-adoptsjon, spesielt når modeller arbeider med store datasett og kompleks informasjon. Hva praktiske tekniker har vist seg å være mest effektive i å redusere hallusinasjoner i produksjonsmiljøer?

Den mest effektive tekniken vi har funnet er å begrense hva modellen er tillatt å vite.

Mye av hallusinasjonen kommer fra å be en modell om å svare fra sin egen generelle kunnskap, hvor den vil glad fill gaps med noe som lyder riktig. Vi gjør det motsatte. Vår AI arbeider strengt fra informasjonen kampanjen har gitt. Den har ikke tilgang til åpen internett, og den trekker ikke på noen vagt minne om verden.

Hvis svaret ikke er i materialet det ble gitt, er den riktige responsen å si at det ikke har den informasjonen. Denne enkle grensen fjerner en enorm mengde risiko.

Vi stopper ikke der, likevel. Vi har flere sjekker på plass for å sikre at et svar matcher hva kampanjen har gitt. Selv etter at modellen genererer et svar, blir svaret sjekket mot kampanjens informasjon før det går noen sted. Hvis noe ikke stemmer, blir det ikke sendt.

Utenfor dette er de praktiske teknikkene om å grunne og vegger. Gi modellen den spesifikke, relevante konteksten den trenger for oppgaven foran den, i stedet for en stor, udiffensiert haug med data. Jo mer fokusert informasjonen er, desto mindre rom er det til å drive.

Vi legger også klare grenser for hva systemet er tillatt å gjøre og si, og vi overvåker ekte samtaler i stedet for å anta at alt er i orden. Du fanger ikke problemer ved å stole på modellen. Du fanger dem ved å se på utdataene.

I en regulert rom som politisk teksting, er et oppdiktet svar en ansvar, så vi designet systemet til å foretrekke åpenhet over å gjette.

Da organisasjoner deployer AI-agenter over kundesupport, kommunikasjon, markedsføring og operasjoner, hva feil ser du team gjenta når de flytter fra pilotprosjekt til produksjons-skalering?

Feilen jeg ser mest er at team test om deres agent fungerer, men ikke om den kan brytes.

Jeg kan ikke telle hvor mange ganger et selskap har lansert en AI-chatbot, og innen en dag har noen på nettet jailbreaket den til å si noe den aldri var ment å si. Det blir talt ut av sine instruksjoner, lurt til å gå utenfor manuset eller manipulert til å representere merket på en måte som ender opp som et skjermbilde alle deler.

Det skjer fordi i en pilot, alle er veloppdragne. Du tester agenten med rimelige mennesker som stiller rimelige spørsmål, og det ser ut som det fungerer. Produksjon er motsatt. Øyeblikket noe er offentlig, er en del av menneskene som snakker med det aktivt forsøker å trikke det opp.

Hvis du ikke har testet for det adversative tilfellet, har du ikke faktisk testet det. Du må prøve å bryte ditt eget system før noen andre gjør det. Trykk det, mata det med de merkelige og fiendtlige inndata, og se om det holder sine grenser når noen bevisst prøver å jobbe mot det.

Den andre gjentakende feilen er å anta at en demo som fungerer er et system som fungerer. En pilot er en håndfull overvåkede samtaler på den lykkelige vei. Produksjon er tusenvis av mennesker på alle tider som oppfører seg på måter du ikke forventet, og de edge-tilfellene du viftet bort blir daglige hendelser i stor skala.

Min råd er å bruke mindre tid på å perfeksjonere demoen og mer tid på å prøve å bryte ting selv. Hvis det ikke kan overleve deg som angriper det, kommer det ikke til å overleve å være offentlig.

AI-agenter blir stadig mer kapable til å håndtere samtaler som tidligere krevde menneskelig personale. Hvor ser du balansen mellom automatisering og menneskelig tilsyn over de neste fem årene, og hvilke arbeidsflyter tror du alltid bør holde et menneske i løkken?

Dette er et hardt spørsmål, og jeg tror ikke noen virkelig vet hvor linjen lander om fem år. Måten jeg tenker på det, er den virkelige verdien av AI som en multiplikator. Den lar en liten gruppe mennesker gjøre langt mer enn de noen gang kunne alene.

Teamene som får mest ut av disse verktøyene, bruker dem nettopp sånn. AI-en tar volumet og repetisjonen, og menneskene bruker sin tid på dømmekraft, strategi og situasjonene som virkelig trenger et menneske. Det er et helt annet mål enn å prøve å fjerne mennesker fra bildet.

Når målet er ren erstattning, tenderer du til å skyve teknologien forbi hva den faktisk er god til, og den feiler på måter som er synlige og dyre. Når målet er å multiplisere dine mennesker, lar du AI-en gjøre hva den er god til, og holder menneskene der de adderer mest verdi. Den andre tilnærmingen fungerer bedre, og den er mer ærlig om hvor teknologien faktisk er i dag.

Over de neste fem årene forventer jeg at agenter tar på seg mer og mer av den rutinemessige samtale-byrden, og de bør. Denne arbeid trenger ikke et menneske som ser på hver enkelt ord.

Arbeidsflytene som alltid bør holde et menneske i løkken, er de hvor stakes er høye eller situasjonen er genuint ny. Alt som berører samtykke, overholdelse eller en beslutning som ville være vanskelig å gå tilbake fra. Et menneske bør eie retningen, og AI-en bør hjelpe dem til å dekke langt mer ground enn de ellers kunne.

Ser fremover, hva utviklinger i konversasjons-AI er du mest spennende over, og hvordan forestiller du deg at plattformer som Convos vil utvikle seg når modeller blir mer kapable, multimodale og autonome?

Hva som spenner meg mest, er at samtaler kommer til å bli bedre.

Etterhvert som modellene forbedres, blir utvekslingene vår plattform håndterer mer naturlige og mer nyttige uten at vi må bygge om grunnmuren hver gang. Fordi vi designet systemet til å flytte mellom modeller, får vi med de forbedringene når de kommer.

Multimodal er utviklingen jeg følger mest nøye. Nå er samtalen tekst. Etterhvert som modeller håndterer bilder og andre formater bedre, er det en reell mulighet til å gjøre disse utvekslingene rikere samtidig som de holder på umiddelbarheten som gjør teksting fungere.

På autonomi er jeg optimistisk, men forsiktig. Mer kapable agenter lanseres månedlig, og de vil kunne håndtere en stor del på egen hånd. Men i en regulert rom, må mer autonomi komme med mer disiplin, ikke mindre. Grensene betyr mer når evnen vokser.

Jeg kom inn i dette fordi jeg var personen som tekstet inn i tomrommet og ikke fikk noen respons. Det er fortsatt problemet jeg bryr meg mest om. Uansett hvor kapable modellene blir, er målet jeg kommer tilbake til enkelt er: Føler personen på den andre enden seg hørt?

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