Shane Eleniak, Chief Product Officer i Calix – Intervju-serie

Shane Eleniak er Chief Product Officer i Calix, der han leder den strategiske visjonen og gjennomføringen av selskapets bransjeledende plattform og SaaS-løsninger. Med fokus på å muliggjøre kommunikasjonstjenesteleverandører å forenkle virksomheten og levere eksepsjonelle abonnentopplevelser, overvåker Shane hele produktlivssyklusen – fra konseptualisering til markedsledende utrulling.

Under hans ledelse har Calix konsolidert sin posisjon som en pionér i bredbåndsindustrien, og leverer jevnt innovative verktøy som gir leverandører mulighet til å konkurrere og vinne.

Calix er et amerikansk teknologiselskap som tilbyr sky-, programvare- og managed service-plattformer designet for bredbånds- og kommunikasjonstjenesteleverandører. Deres kjerneutbud sentrerer seg rundt en AI-aktiveret bredbåndsplattform som integrerer sky-infrastruktur, data og nettverkssystemer for å hjelpe leverandører å forenkle driften, forbedre kundeengasjement og levere mer personlige digitale opplevelser. Ved å muliggjøre at disse leverandørene kan gå over fra grunnleggende tilkoblings­tjenester til fullstendige “erfaringstjenesteleverandører”, hjelper Calix dem å øke inntektene, øke abonnentloyaliteten og støtte den digitale transformasjonen av samfunn gjennom mer avanserte og skalerbare bredbåndstjenester.

Din karriere spenner over mer enn tre tiår over ingeniørarbeid, nettverksplattformer, skytjenester og stor­skala produktledelse. Hvordan har disse erfaringene formet din perspektiv på hva det virkelig tar å få AI til å utføre virkelig arbeid innen bedrifter, i stedet for å forbli en side-eksperiment?

Jeg startet i tradisjonell telekommunikasjon og nettverking, der hele spillet var datapunktet og pålitelighet i skala. Hvis du ikke kan levere en ren og pålitelig tjeneste, betyr ingenting du bygger på toppen av det noe. Da var telefonen på kjøkkenveggen, innvendig kabelverk ble aldri flyttet, og så lenge det var en ringetone, var alt i orden.

Bredbånd og Internett sprengte dette. Plutselig var det ikke bare “er det på?” Det var Ethernet og deretter Wi-Fi, barn på spillkonsoller og nettbrett, du på et Zoom-møte som samarbeider på en skytjeneste, og konstant mobilitet – enheter inne i hjemmet, i bakgården, på fotballkampen, på kaffe­baren. Abonnent­opplevelsen ble mye mer komplisert enn en binær på/av-tilstand, og verden for tjenesteleverandører ble svært dynamisk. I den verden er en bakovervendt visning av data – klassiske data­lager og historiske rapporter en måned senere – ikke nok. Du må samle inn data, forstå opplevelsen og generere innsikt i sanntid, fordi abonnenter nå forventer at problemer skal løses proaktivt, ikke på timer eller dager.

Den utviklingen har formet hvordan jeg tenker om AI. De fleste mennesker ønsker å plassere AI “på toppen”, på samme måte de plasserer business intelligence eller SaaS på toppen av eksisterende data­lager. Min erfaring sier at du må tenke mye dypere enn det og designe for sanntids­aksjonerbare innsikt og mulighet til å iverksette aksjoner i tide.

For abonnenter har forventningene ikke endret seg mye de siste 25 årene. De ønsker fortsatt sikker, ledet tilkobling som føles like enkelt som en ringetone – de ønsker at alt skal “bare fungere” uten å tenke på alle lagene og kompleksiteten, og de ønsker det overalt i livene sine. Min karriere i telekommunikasjon og skytjenester har gjort meg svært komfortabel med denne paradokset: du bygger ekstremt komplekse systemer for å kunne abstrahere all denne kompleksiteten og levere en enkel, god opplevelse på kanten. Det er nettopp hvordan jeg tenker om AI som gjør virkelig arbeid innen bedrifter, bredbånd eller annet.

I Calix understreker du ofte at operasjonell AI er bygget, ikke kjøpt. Hva er de vanligste feilene organisasjoner gjør når de prøver å legge til AI uten å tenke om hvordan arbeidsflyten går gjennom bedriften?

For meg handler det mindre om “bygget versus kjøpt” og mer om om du har trått tilbake og sett på hele teknologistaken. Mange selskaper bestemmer seg for at AI bare er å bruke noen API-er for å få tilgang til en LLM, kobler det til sin teknologistakk med en wrapper og kjøper tokens – så har du en AI-strategi. Det er ikke slik det fungerer.

For mange av oss blir vi for fascinerte av teknologien i stedet for resultatet. Vi har sett denne filmen før. Når PC-er dukket opp, ønsket alle å diskutere om de hadde en 286 eller en 386, hvor mye minne de hadde og hvilken DOS de kjørte. I dag kan ingen fortelle deg spesifikasjonene på sin bærbare datamaskin eller mobiltelefon, og ingen bryr seg før det stopper å gjøre det de trenger det til å gjøre. Hva som betyr noe er: gjør dette meg mer effektiv i jobben min? Det er det samme med AI. Hvis du ikke kan knytte det til virkelig arbeidsflyt, virkelig verdi og virkelig ROI, er teknologispesifikasjonene bare støy.

En annen stor feil er å prøve å montere AI på det du allerede har uten å spørre hva det gjør med din arkitektur, sikkerhetsmodell og kostnader. AI er grunnleggende teknologi, ikke en inkrementell funksjonsoppgradering. Når du behandler det som inkrementelt, ender du opp med dårlig data, sikkerhetsproblemer, hallusinasjoner, løpske kostnader eller mye aktivitet som ikke løser et problem for noen.

Til slutt kan du ikke ignorere kontekst og viktigheten av vertikal ekspertise. Handling er all om kontekst, og den konteksten varierer over telekommunikasjon, finansteknologi og helsevesen. I Calix startet vi med dypt erfaring i én bransje og bygde en vertikal plattform rundt det. Vi forstod allerede data, innsikt, arbeidsflyt og kontekst, så staken kunne reflektere den virkeligheten. De fleste selskaper kjenner sin vertikale bransje inne og ut. Muligheten er å kode den kunnskapen inn i en vertikal teknologistakk i stedet for å stole på en tynn horisontal lag og en generisk AI-modell, og deretter prøve å sy sammen alt.

Du har skissert en fem-lags arkitektur for operasjonell AI som inkluderer data, kunnskap, orkestrering, tillit og handling. Hvorfor er det viktig å eksplisitt skille disse lagene, og hvilket lag underskattes eller utelates oftest av bedrifter?

I lang tid har staken vært ganske enkel: data, innsikt, dashboards, arbeidsflyt, mennesker. Du bygde data­lager, la BI på toppen, skapte arbeidsflyt-motorer og overlot det harde arbeidet til mennesker. I en agensverden holder det ikke. Du trenger data, kunnskap, orkestrering, tillit og handling fordi hvert lag utfører en distinkt funksjon.

Den synlige delen alle ønsker å diskutere er handling­slaget – agentene. Det er toppen av isfjellet. Hva avgjør om du noen gang kan la agentene berøre virkelige systemer, er all “kjedelig” sak under vannlinjen: data­pipeliner og ren data, kunnskaps­laget som gir deg kontekst, orkestreringen som koordinerer dynamiske arbeidsflyter og tillits­modellen som bestemmer hva som skal tillates fra først av. Når Titanic sank, var det ikke den lille delen du kunne se som sank den; det var den store massen av is under vannlinjen. Operasjonell AI er det samme. Rørene under overflaten er det som gjør eller ødelegger deg.

Historisk sett har vi ikke behandlet orkestrering og tillit som separate lag fordi mennesker gjorde det meste av det arbeidet. Orkestrering betydde ledere og billetter; tillit betydde brukernavn og passord. Nå må du stole på enheter – agenter – til å gjøre ting, og du må koordinere flere agenter i sanntid rundt dynamisk data. Det er et helt annet design­problem, og det er derfor disse lagene må være eksplisitte.

Laget de fleste underskatter er tillit. Mange organisasjoner tror de håndterer tillit fordi de har tilgangskontroll – hvem kan logge inn på hvilket system. Men virkelig tillit i en agensverden er ikke “har denne brukeren tilgang?” Det er “er denne handlingen passende for denne personen eller denne agenten på dette tidspunktet?” Det er en styrings­spørsmål, ikke et tilgangs­kontroll­spørsmål. Hvis du ikke gjør dette laget eksplisitt, havner du fast i demo­land, fordi du aldri kommer til å være komfortabel med å la agenter gjøre virkelig arbeid i produksjon.

Så, tillit er åpenbart en grunnleggende del av din AI-strategi. Hvordan designer du systemer så automatiserte beslutninger forblir observerbare, auditable og omvendelige samtidig som de flytter raskt nok til å levere forretningsverdi?

Du må starte med en null-tillit-holdning. Det første spørsmålet er ikke “kan denne agenten teknisk gjøre dette?” Det første spørsmålet er “bør denne agenten, på vegne av denne personen, prøve å gjøre dette overhodet?” Hvis svaret er nei, så gå ikke videre.

Hvis svaret er ja, går du over til retningslinjer: auditerbarhet, sporing og behov for en menneskelig i løkken. Vår modell avhenger av et tillitslag som fungerer litt som en trafikkpoliti ved starten av hver interaksjon: hvem er du, hva gjør du, og hvorfor gjør du dette? Det eliminerer mange av sikkerhetsproblemer, fordi du ikke lar agenter løpe av med å gjøre ting og så håpe du legger merke til det etterpå.

Alternativet er å slippe løs agentene og deretter varsle hvis de løper av med å gjøre noe dårlig. Du antar at du kan se det, finne det ut, identifisere det og stoppe det i sanntid, i den hastigheten og skalaen disse systemene opererer. Det er et svært vanskelig problem, og det er derfor så mange mennesker sliter – de prøver å lete etter dårlige aktører i sanntid i stedet for å forhindre dårlige handlinger fra først av.

På toppen av det har vi lagt til lagdelte porter. Selv om en agent handler på vegne av riktig person, ser vi på sesjonen og innholdet – prøver de å forgifte en modell, misbruke en API eller presse noe utenfor politikk? Alt dette er innpakket i fullstendig observerbarhet, så du kan auditere hva som skjedde og rulle det tilbake hvis du trenger det. Det er hvordan du flytter raskt og sover godt om natten.

Mange selskaper lykkes med å generere AI-innsikt, men sliter med å oversette dem til handling. Hva var design­beslutningene som gjorde det mulig for Calix å skyve AI direkte inn i dag-til-dag-arbeidsflyter over markedsføring, operasjoner og kunde­støtte?

Lenge før AI var stjernen i showet, var vi allerede besatt av ett spørsmål i Calix: hva gjør et innsikt virkelig aksjonerbart for en virkelig person i en virkelig jobb? Siden 2018 har vi arbeidet med tjenesteleverandører for å forstå hvordan forskjellige personer arbeider – hva en markedsfører gjør på en tirsdag morgen, hva et operasjonsteam gjør når en alarm utløses, hva støtte­team gjør når en abonnent ringer inn frustrert. Det tvang oss til å bli svært klare om hvilke innsikt som betyr noe for hvem, i hvilken kontekst og hva “god handling” ligner.

Så, når agens­basert AI dukket opp, var vi ikke startet fra scratch. Vi hadde allerede sanntids­systemer som genererte aksjonerbare innsikt knyttet til bestemte personer og arbeidsflyter. Design­spørsmålet ble: gitt en annen verktøy­sammensetning og en annen teknologistakk, hvordan ville du om­designe de samme arbeidsflytene i en agens­basert AI-verden, i stedet for å prøve å finne det ut fra scratch?

Når du parer denne dypte person­kunnskapen med agens­basert AI, kan du bygge dynamiske arbeidsflyter over dynamisk data. Agenter kan finne ut, i sanntid, hvilke skritt og hvilke personer som må være involvert basert på hva som skjer, i stedet for å tvinge deg til å hard­kode hundrevis av stive arbeidsflyter i mikro­tjenester. For de fleste selskaper er det harde problemet nå å prøve å gjøre sanntids­beslutninger basert på kontekst og deretter designe riktig arbeidsflyt rundt det. For oss var det partiet allerede på plass; vi hadde vært sanntids­, person­basert, aksjonerbart innsikt i årevis. Agens­basert AI er bare et nytt verktøy­sammensetning på toppen av den grunn­strukturen.

Din plattform­visjon inkluderer agent-til-agent (A2A) samarbeid og fødererte AI-systemer. Hvordan endrer denne tilnærmingen måten bedriftsverktøy samarbeider sammenlignet med tradisjonelle punkt-integreringer?

Hvis du ser på de siste 20 årene, har standard­mønsteret vært “kjøp en haug med SaaS-verktøy og kobler dem sammen rundt et data­lager”. Hvert nytt system betydde en ny punkt-integrering, en ny data­pipeline og en ny plass å rekonsiliere sannheten. I en agensverden skalerer det ikke. Du ønsker at data skal forbli der det hører hjemme, og at agenter snakker med hverandre over godt definerte grensesnitt.

Det er derfor vi snakker om å berøre systemet på to lag: MCP på kunnskaps­laget, og A2A på orkestrerings- og tillits­lagene. MCP er hvordan agenter oppdager og bruker verktøy og data uten en ny tilpasset integrering hver gang. A2A er hvordan agenter koordinerer arbeid med hverandre under klare retningslinjer.

Når du har det, stopper samarbeidet å se ut som en haug med skjøre koblinger og begynner å se ut som et nettverk av spesialister som kan dynamisk samarbeide rundt virkelig arbeid. Her kommer Eisenhower-matrise-analogien inn. Ikke alt er like urgent og like viktig. Noen arbeid er virkelig tid-kritisk, noen er viktig, men kan planlegges, noen må bare gjøres, og noen er støy. Med agent-til-agent-koordinering på toppen av et tillits- og orkestreringslag, kan du behandle disse kategoriene forskjellig i skala: agenter kan swarme de ur­gent-og-viktige problemene, kø eller planlegge det viktige, men ikke ur­gent, og holde det lav­verdi­arbeidet borte fra alt annet.

Det er en helt annen verden enn “la oss legge til en ny kobling og håpe køen tømmes”. Du ser effektivt på tillitsfulle, nøye orkestrerte, dynamiske arbeidsflyter rundt dynamisk hendelser og data, i stedet for en rot av enkelt-integreringer hvor alt roper med samme prioritet.

Når AI-agenter er tillatt å handle autonomt, blir styring raskt en utfordring. Hvordan balanserer du hastighet, ansvar og menneskelig tilsyn når AI-systemer tar eller iverksetter beslutninger i skala?

Feilen jeg ser er at mennesker tror de kan montere agens­basert AI på det de allerede har og deretter prøve å “balansere” hastighet, ansvar og menneskelig tilsyn etterpå. Du kan ikke. Du må starte med å anerkjenne at dette er et vertikal teknologistakk-problem og deretter bygge en tillits­lag og et orkestrerings­lag. Uten disse to lagene, blir det et fritt-for-all – alt er først-til-mål, eller hvem som roper høyest.

Igjen er det Eisenhower-matrisen: ikke all arbeid er skapt like. Tillit og orkestrering er hvordan du operasjonaliserer det i en agensverden. Du ønsker ikke at hver agent behandler hver oppgave som en brann­alarm; du ønsker at systemet skal vite hva som virkelig er tid-kritisk, hva som kan planlegges og hva som bør håndteres stille i bakgrunnen.

Og deretter er det “smal over tykk” -delen. De fleste selskaper tar feil av større innvirkning fra AI med å forbli bred. Du er mye bedre tjent med å velge en smal vertikal skive – ett konkrekt brukstilfelle, ett sett arbeidsflyter – og bygge tillit og orkestrering du trenger der først. Få tynnere i den vertikale, få det rett, hold mennesker i løkken på kantene og deretter utvide. Det er hvordan du flytter raskt, holder deg ansvarlig og unngår å lage en rot du ikke kan rulle tilbake senere.

Fra din erfaring med å lede store globale produkt- og ingeniør­team, hva organisatoriske eller kulturelle endringer er nødvendige for at AI skal bli en varig bedrifts­evne i stedet for en samling løsrevne piloter?

De fleste bedrifter har ikke et “AI-problem”; de har et kunnskaps- og arbeidsflyt-problem. Den første endringen er å stoppe å leke med punkt-løsninger og flytte fra data­lager til et føderert kunnskaps­lager som alle kan se og handle på. Så lenge kunnskap bor i siloer og AI er en kirsebær på toppen av hver silo, får du piloter, ikke transformasjon.

Deretter må du være villig til å gå etter de harde problemene i en bestemt rekkefølge. Første trinn er å skille hype fra realitet og adoptere hva som fungerer, ikke hva som er høyest i din feed. Andre trinn er å om­designe kunnskaps­laget så du kan omdanne data til delt, føderert kontekst i stedet for enda en rapport gravlagt i et system. Tredje trinn er å tenke om arbeidsflyt rundt den kunnskapen og en virkelig tillits­modell – de fleste arbeid i dag er organisert rundt mennesker, ferdigheter og lokale kunnskaps­siloer. Hvis du ikke endrer det, vil agenter bare være et verktøy som kretser rundt de samme gamle flaskenakker.

Kun deretter kommer den kulturelle endringen, som ofte er den hardeste. Du trenger en kultur hvor mennesker ikke primært er bekymret for å tape jobben, verktøyene eller identiteten, men er genuint begeistret for å arbeide med nye evner. Det er en endrings­ledelses­problematikk, ikke et teknologi­problematikk. Det ligner mye på distribuert ledelse: mennesker på spissen av spydet forstår arbeidsflytene, føler seg trygge med å navngi friksjonen og er begeistret for å sette agenter i arbeid på det.

Seende beyond bredbånd og telekommunikasjon, hvilke bransjer tror du er best posisjonert til å adoptere operasjonell, agent-drevet AI neste, og hva betingelser gjør dem klare?

Jeg tenker ikke på det som å velge vinnere etter bransje-etikett; jeg tenker i mønster. Nesten hver vertikal har den samme underliggende utfordringen: de har bygget data-siloer og funksjons­siloer i stedet for én visning på tre livssykluser – kunde, ansatt og produkt. De som er klare er de som er villige til å se det, innrømme at de ikke har en virkelig kunnskaps­lag og fikse det.

Deretter ser betingelsene ganske like ut, uavhengig av om du er i helsevesen, finansteknologi, detaljhandel eller kritisk infrastruktur. Du trenger komplekse arbeidsflyter hvor mennesker er strekket, virkelig friksjons­punkter du kan navngi og nok høy­kvalitets­data til å gi agenter kontekst. Hvis du kan kartlegge nåværende arbeidsflyter, se hvor arbeidet bremser eller hopper opp, forstå hvilke overleveringer skaper forsinkelser og deretter bak det med et føderert kunnskaps­lager, blir agens­basert AI et fantastisk verktøy­sammensetning.

I den verden er “bransje-klarhet” en ledelses­spørsmål. Er en bedrifts ledere villige til å gå beyond markedsførings­verktøy og tynne horisontale dashboards, og i stedet investere i en vertikal teknologistakk – omdanne data til kunnskap, fødere den kunnskapen, sette orkestrerings- og tillits­rammer på plass og ha ærlige samtaler om hvor den virkelige avkastningen er? Ethvert selskap i noen bransje som gjør det arbeidet, er godt posisjonert for operasjonell, agent-drevet AI; de som ikke gjør det, vil bli fanget i å legge til et nytt verktøy til en allerede støy­full haug.

Etterhvert som bedrifts-AI utvikler seg mot multi-agent og multi-sky-miljøer, hva ser god AI-arkitektur ut som om fem år, og hva prinsipper bør ledere forplikte seg til i dag for å unngå å bygge om systemene sine senere?

Om fem år vil den interessante delen av AI ikke være de enkelte agentene eller modellene; det vil være de agens­baserte arbeidsflytene de muliggjør og den forretnings­verdien disse arbeidsflytene leverer. Agentene selv vil komme og gå. Lagene under dem – data, kunnskap, orkestrering, tillit og handling – vil fortsette å utvikle seg, men behovet for dem er ikke på vei bort.

Det er derfor jeg fokuserer mer på arkitektur enn på noen bestemt verktøy. Vi flytter fra data­lager til fødererte kunnskaps­lager, fra skjøre punkt-integreringer til åpne, lagdelte staker. I den verden vil du ha agenter som kjører i forskjellige skyer, berører forskjellige kunnskaps­kilder og koordinerer over godt definerte grensesnitt – MCP på kunnskaps­laget, agent-til-agent-protokoller på orkestrerings- og tillits­lagene. Når teknologien forbedres, ønsker du å kunne bytte bedre deler inn i disse lagene uten å bygge hele ting igjen hver gang.

Så, prinsippene for ledere er enkle. Bygg ikke monolittisk. Design for lag så data, kunnskap, orkestrering, tillit og handling kan hver utvikle seg uavhengig. Design for flyter, ikke funksjoner, så du er klar over hvilke arbeidsflyter som betyr noe og hva “god” ligner i kunde-, ansatt- og produkt­livssykluser. Og design for styring på agent­nivå: anta null-tillit som standard, definer klare “agent-kort” og bruk orkestrering til å bestemme hva som er urgent, hva som er viktig og hva som bare må gjøres. Hvis du gjør det, kan du la teknologien endre seg – som den alltid gjør – uten å være konstant bekymret for å bygge om.

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