Shane Eleniak, Chief Product Officer at 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 at kommunikasjonstjenesteleverandører kan forenkle sin forretning og levere unike abonnentopplevelser, overvåker Shane hele produktlivssyklusen – fra konseptualisering til markedsledende distribusjon.

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

Calix er et amerikansk teknologiselskap som tilbyr sky-, programvare- og managed service-plattformer designet for bredbånd og kommunikasjonstjenesteleverandører. Deres kjerneutbud sentrerer seg rundt en AI-aktivert bredbåndsplattform som integrerer sky-infrastruktur, data og nettverkssystemer for å hjelpe leverandørene å forenkle drift, 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 abonnent­loyaliteten og støtte den digitale transformasjonen av samfunnet gjennom mer avanserte, skalerbare bredbåndstjenester.

Din karriere omfatter mer enn tre tiår over ingeniørarbeid, nettverk, skyplattformer og stor­skalautvikling av produkter. Hvordan har disse erfaringene formet din perspektiv på hva det virkelig tar for å få AI til å utføre virkelig arbeid i bedrifter, i stedet for å forbli en side­eksperiment?

Jeg startet i tradisjonell telekommunikasjon og nettverk, der hele spillet var datapath og pålitelighet i stor skala. Hvis du ikke kan levere en ren, pålitelig tjeneste, betyr ingenting du bygger på toppen av det noe. Da var telefonen på kjøkkenveggen, innvendig ledning flyttet aldri, og så lenge det var en lyd­signal, 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å spill­konsoller og nettbrett, du på et Zoom-møte samarbeider på en sky­regneark og konstant mobilitet – enheter innendørs, i bakgården, på fotballkampen, på kaffebaren. Abonnent­opplevelsen ble mye mer kompleks enn en binær på/av-tilstand, og verden for tjenesteleverandører ble svært dynamisk. I den verden er en tilbake­vendt 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 løses proaktivt, ikke på timer eller dager.

Den utviklingen har formet hvordan jeg tenker om AI. De fleste mennesker vil plassere AI “på toppen”, på samme måte som 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­innsikt og mulighet til å iverksette handlinger i sanntid.

For abonnenter har forventningene ikke endret seg mye de siste 25 årene. De vil fortsatt bare ha sikker, administrert tilkobling som føles like enkelt som lyd­signal – de vil at alt skal “bare fungere” uten å tenke på alle lagene og kompleksiteten, og de vil ha det overalt i livene sine. Min karriere i telekommunikasjon og sky har gjort meg svært komfortabel med denne paradokset: du bygger ekstremt komplekse systemer så du kan abstrahere all denne kompleksiteten og levere en enkel, god opplevelse på kanten. Det er akkurat slik jeg tenker om AI som gjør virkelig arbeid i noen bedrift, bredbånd eller ikke.

Hos Calix understreker du ofte at operasjonell AI er bygget, ikke kjøpt. Hva er de vanligste feilene organisasjonene 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 bestemte seg for at AI bare var å bruke noen API-er for å få tilgang til en LLM, koblet det inn i staken med en wrapper og kjøpte tokens – så hadde du en AI-strategi. Det er ikke slik det fungerer.

For mange av oss blir teknologien for fasinert med 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 det hadde og hvilken DOS det kjørte. I dag kan ingen fortelle deg spesifikasjonene på bærbaren eller telefonen, og ingen bryr seg før det stopper å gjøre hva de trenger det til å gjøre. Hva som betyr noe, er: gjør dette meg mer effektiv i jobben min? Det samme gjelder for AI. Hvis du ikke kan knytte det til virkelige arbeidsflyter, virkelig verdi og virkelig avkastning, er teknologispesifikasjonene bare støy.

En annen stor feil er å prøve å skru AI på det du allerede har uten å spørre hva det gjør med arkitekturen, sikkerhetsmodellen og kostnadene. 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 noen problemer for noen.

Til slutt kan du ikke ignorere kontekst og viktigheten av vertikal ekspertise. Handling handler om kontekst, og den konteksten varierer over telekommunikasjon, finansteknologi og helsevesen. Hos Calix startet vi med dyptgående erfaring i én bransje og bygget 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 inn og ut. Muligheten er å kode den kunnskapen inn i en vertikal teknologistack i stedet for å stole på et tynnt, horisontalt lag og en generisk AI-modell, og så prøve å sy sammen alt.

Bedrifter handler om resultater, ikke modeller. Det virkelige spørsmålet er hvordan denne teknologien hjelper deg å levere disse resultatene på måten din arbeidsflyt fungerer.

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 undervurderer eller hopper over bedriftene oftest?

I lang tid var staken ganske enkel: data, innsikt, dashboards, arbeidsflyt og mennesker. Du bygget data­lager, la til BI på toppen, skapte arbeidsflyt­motorer og overlot det harde arbeidet til mennesker. I en agens­verden 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­laget – agentene. Det er bare 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 enorme massen av is under. Operasjonell AI er det samme. Rørene under overflaten er det som gjør eller ødelegger deg.

Historisk sett har vi aldri behandlet orkestrering og tillit som separate lag fordi mennesker gjorde mest 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­problematikk, som er hvorfor disse lagene må være eksplisitte.

Laget de fleste mennesker undervurderer 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 agens­verden er ikke “har denne brukeren tilgang?” Det er “er denne spesifikke handlingen passende for denne personen eller denne agenten på dette tidspunktet?” Det er et styrings­spørsmål, ikke et tilgangskontroll­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, granskbare og omgjørbar mens du likevel flytter deg 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 sett 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 i retningslinjer: granskbare, sporbarhet 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åper du merker det etterpå.

Alternativet er å slippe løs agentene og så reise en alarm hvis de går av og gjør noe dårlig. Du antar at du kan se det, finne ut av det, 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 hvorfor så mange mennesker sliter – de prøver å se etter dårlige aktører i sanntid i stedet for å forhindre dårlige handlinger på forhånd.

I tillegg 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 pushe noe utenfor politikk? All dette er innpakket i full granskbare så du kan granske hva som skjedde og rulle det tilbake hvis du trenger det. Det er hvordan du flytter deg raskt og likevel sover godt om natten.

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

Lenge før AI var stjernen av showet, var vi allerede besatt av ett spørsmål hos Calix: hva gjør en innsikt virkelig handling­bar for en virkelig person i en virkelig jobb? Siden 2018 har vi arbeidet med tjenesteleverandører for å forstå hvordan forskjellige personligheter arbeider – hva en markedsfører gjør på en tirsdag morgen, hva et driftsteam 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­drevet AI kom, startet vi ikke fra scratch. Vi hadde allerede sanntids­systemer som genererte handling­bare innsikt knyttet til spesifikke personligheter og arbeidsflyter. Design­spørsmålet ble: gitt et annet verktøysett og en annen teknologistack, hvordan ville du om­designe disse samme arbeidsflytene i en agens­drevet AI-verden, i stedet for å prøve å finne opp alt det fra scratch?

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

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 SaaS-verktøy og koblet dem sammen rundt et data­lager”. Hver nytt system betydde en ny punkt­integrering, en ny data­pipeline og en ny plass å forlike sannheten. I en agens­verden skalerer det ikke. Du ønsker at data skal forbli der det hører hjemme og la agenter snakke sammen over godt definerte grensesnitt.

Det er hvorfor 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 først har det, stopper samarbeidet å se ut som en haug 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急 og like viktig. Noen arbeid er virkelig tids­kritisk, noen er viktig men kan planlegges, noen må bare bli gjort 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 sværme rundt急-og-viktige problemer, køe eller planlegge viktige men ikke急, og holde lav­verdi­arbeidet borte fra å overbelaste alt annet.

Det er en svært annen verden enn “la oss legge til en til kobling og håpe køen tømmes”. Du ser effektivt på trustede, nøye orkestrerte dynamiske arbeidsflyter rundt dynamiske hendelser og data, i stedet for en rot av enkelt­koblinger hvor alt roper ut på samme prioritet.

Når AI-agenter er tillatt å handle selvstendig, 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 bolt agens­drevet AI på hva de allerede har og noen gang prøve å “balansere” hastighet, ansvar og menneskelig tilsyn etterpå. Du kan ikke. Du må starte med å anerkjenne at dette er et vertikal teknologistack-problem og med vilje bygge et tillitslag og et orkestreringslag. Uten disse to lagene, blir det et fritt-for-all – alt er først-til-møtes, eller hvem som roper høyest.

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

Og så er det “smal over tykk”­delen. De fleste selskaper tar feil av at større innvirkning fra AI kommer fra å forbli bred. Du er mye bedre å velge en smal vertikal skive – ett konkret brukstilfelle, ett sett med 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 så utvide. Det er hvordan du flytter deg raskt, forblir ansvarlig og unngår å lage en rot du ikke kan vikle ut senere.

Basert på 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 punktlø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 hardeste 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 begravd i et system. Tredje trinn er å tenke om arbeidsflyter rundt den kunnskapen og en virkelig tillits­lag – mest arbeid i dag er organisert rundt mennesker, ferdigheter og lokale kunnskapssiloer. Hvis du ikke endrer det, vil agenter bare være et nytt verktøy som svirrer rundt de samme gamle flaskenakker.

Først da kommer den kulturelle endringen, som ofte er den hardeste. Du trenger en kultur hvor mennesker ikke primært er bekymret for å miste jobben, verktøyene eller identiteten, men er genuint begeistret for å arbeide med nye evner. Det er en endrings­ledelses­problem, ikke et teknologiproblem. 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 for å adoptere operasjonell, agent­drevet AI neste, og hva betingelser gjør dem klare?

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

Derfra 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, virkelige 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 sakker eller hopper opp, forstå hvilke hånd­over­ganger skaper forsinkelser og så bak det opp med et føderert kunnskaps­lager, er agens­drevet AI et fantastisk verktøysett.

I den verden handler “bransje­klarhet” om ledelse. Er et selskaps ledere villige til å flytte seg beyond markeds­verktøy og tynne, horisontale dashboards og i stedet investere i en vertikal teknologistack – omdanne data til kunnskap, føderere den kunnskapen, legge 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 fast 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­drevne arbeidsflytene de muliggjør og den forretnings­verdien disse arbeidsflytene leverer. Agenter selv kommer og går. Lagene under dem – data, kunnskap, orkestrering, tillit og handling – vil fortsette å utvikle seg, men behovet for dem er ikke på vei bort.

Det er hvorfor jeg er mer fokusert på arkitektur enn på noen bestemt verktøy. Vi flytter oss 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 og agent-til-agent-protokoller på orkestrerings- og tillits­lagene. Etterhvert som 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 monolitisk. 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, definere klare “agent­kort” og bruke orkestrering til å bestemme hva som er急, hva som er viktig og hva som bare må bli gjort. Hvis du gjør det, kan du la teknologien endre seg – som den alltid gjør – uten å være konstant bekymret for å bygge om.