Shane Eleniak, Chief Product Officer på Calix – Intervju-serie

Shane Eleniak är Chief Product Officer på Calix, där han leder det strategiska synsättet och genomförandet av företagets branschledande plattform och SaaS-lösningar. Med fokus på att möjliggöra för kommunikationstjänsteleverantörer att förenkla sin verksamhet och leverera exceptionella abonnentupplevelser, övervakar Shane hela produktlivscykeln – från konceptualisering till marknadsledande distribution.

Under hans ledning har Calix befäst sin position som en pionjär inom bredbandsindustrin, och levererar konsekvent innovativa verktyg som ger leverantörerna möjlighet att konkurrera och vinna.

Calix är ett amerikanskt teknologiföretag som tillhandahåller moln-, programvaru- och hanterade tjänsteplattformar som är utformade för bredbands- och kommunikationstjänsteleverantörer. Deras kärnerbjudande kretsar kring en AI-aktiverad bredbandsplattform som integrerar molninfrastruktur, data och nätverkssystem för att hjälpa leverantörerna att förenkla verksamheten, förbättra kundengagemanget och leverera mer personliga digitala upplevelser. Genom att möjliggöra för dessa leverantörer att gå från grundläggande anslutningstjänster till fullständiga “upplevelseleverantörer” hjälper Calix dem att öka intäkterna, öka abonnentlojaliteten och stödja den digitala transformationen av samhällen genom mer avancerade och skalbara bredbandstjänster.

Din karriär spänner över mer än tre decennier inom teknik, nätverk, molnplattformar och storskalig produktledning. Hur har dessa erfarenheter format din syn på vad det verkligen krävs för att AI ska kunna utföra riktigt arbete inom företag, snarare än att förbli en sidouppgift?

Jag började inom traditionell telekommunikation och nätverk, där hela spelet var datapath och tillförlitlighet i stor skala. Om du inte kan leverera en ren och tillförlitlig tjänst, spelar ingenting du bygger ovanpå det någon roll. Då var telefonen på köksväggen, den inre kablagen flyttades aldrig och så länge det fanns en signalton, var allt bra.

Bredband och internet förstörde allt detta. Plötsligt var det inte bara “är det på?” Det var Ethernet och sedan Wi-Fi, barn på spelkonsoler och surfplattor, du på ett Zoom-samtal som samarbetar på ett molnbaserat kalkylblad och konstant rörlighet – enheter inom hemmet, i bakgården, på fotbollsmatchen, på kaféet. Abonnentupplevelsen blev mycket mer komplex än en binär på/av-tillstånd, och världen för tjänsteleverantörer blev mycket dynamisk. I den världen räcker det inte med en bakåtblickande vy av data – klassiska datawarehouse och historiska rapporter en månad senare. Du måste samla in data, förstå upplevelsen och generera insikter i realtid, eftersom abonnenter nu förväntar sig att problem ska åtgärdas proaktivt, inte på några timmar eller dagar.

Den utvecklingen har format hur jag tänker om AI. De flesta människor vill lägga AI “på toppen”, på samma sätt som de lägger business intelligence eller SaaS ovanpå befintliga data sjöar. Min erfarenhet säger att du måste tänka mycket djupare än så och designa för realtidsinsikter och möjligheten att vidta lämpliga åtgärder.

För abonnenter har förväntningarna inte förändrats så mycket under de senaste 25 åren. De vill fortfarande ha säker, hanterad anslutning som känns lika enkel som signalton – de vill att allt ska “fungera” utan att tänka på alla lager och komplexitet, och de vill ha det överallt i sina liv. Min karriär inom telekom och moln har gjort mig mycket bekväm med den paradoxen: du bygger extremt komplexa system så att du kan abstrahera allt detta och leverera en enkel, bra upplevelse i gränsen. Det är exakt hur jag tänker om AI som gör riktigt arbete inom företag, oavsett om det är bredband eller inte.

På Calix betonar du ofta att operativ AI byggs snarare än köps. Vilka är de vanligaste misstagen som organisationer gör när de försöker lägga till AI utan att ompröva hur arbetet flödar genom företaget?

För mig handlar det mindre om “byggt eller köpt” och mer om om du har tagit ett steg tillbaka och tittat på hela teknikstacken. Många företag bestämde sig för att AI bara var att använda några API:er för att få tillgång till en LLM, ansluta det till sin stack med en wrapper och köpa tokens – då hade de en AI-strategi. Det är inte så det fungerar.

För många av oss blir vi för fascinerade av tekniken istället för resultatet. Vi har sett den här filmen förut. När PC:er kom, ville alla diskutera om de hade en 286 eller en 386, hur mycket minne de hade och vilken DOS de körde. Idag kan ingen berätta för dig specifikationerna för sin laptop eller mobil, och ingen bryr sig förrän den slutar fungera som de behöver. Vad som är viktigt är: gör det här mig mer effektiv i mitt jobb? Det är samma sak med AI. Om du inte kan knyta det till riktiga arbetsflöden, riktigt värde och riktigt ROI, är tekniska specifikationer bara brus.

En annan stor misstag är att försöka skruva fast AI på det du redan har utan att fråga vad det gör med din arkitektur, ditt säkerhetsmodell och dina kostnader. AI är grundläggande teknik, inte en inkrementell funktionuppgradering. När du behandlar det som inkrementellt, hamnar du med dåliga data, säkerhetsproblem, hallucinationer, springande kostnader eller en massa aktivitet som inte löser något problem för någon.

Slutligen kan du inte ignorera kontexten och vikten av vertikal expertis. Åtgärd handlar alltid om kontext, och den kontexten skiljer sig mellan telekom, fintech och hälsovård. På Calix började vi med djup erfarenhet inom en bransch och byggde en vertikal plattform runt den. Vi förstod redan datan, insikterna, arbetsflödena och kontexten, så stacken kunde återspegla den verkligheten. De flesta företag känner till sin vertikala bransch inifrån och ut. Möjligheten är att koda den kunskapen in i en vertikal teknikstack istället för att förlita sig på ett tunt horisontellt lager och en generisk AI-modell, och sedan försöka sy alla bitar ihop. Företag handlar om resultat, inte modeller. Den riktiga frågan är hur den här tekniken hjälper dig att leverera de resultaten på det sätt ditt arbete flödar.

Du har beskrivit en femlagersarkitektur för operativ AI som inkluderar data, kunskap, orkestrering, tillit och åtgärd. Varför är det viktigt att explicit separera dessa lager, och vilket lager underskattar företag vanligtvis eller hoppar över helt?

För länge sedan var stacken ganska enkel: data, insikter, instrumentpaneler, arbetsflöden, människor. Du byggde datawarehouse, lade BI ovanpå, skapade arbetsflödesmotorer och gav det hårda arbetet till människor. I en agensvärld fungerar det inte. Du behöver data, kunskap, orkestrering, tillit och åtgärd, eftersom varje lager utför en distinkt funktion.

Den synliga delen som alla vill prata om är åtgärdslagret – agenterna. Det är toppen av isberget. Vad som bestämmer om du någonsin kan låta agenter röra sig i riktiga system är allt det “tråkiga” under ytan: datapipeliner och ren data, kunskapslagret som ger dig kontext, orkestreringen som koordinerar dynamiska arbetsflöden och tillitmodellen som bestämmer vad som ska tillåtas från första början. När Titanic sjönk, var det inte den lilla biten du kunde se som sjönk den; det var den enorma massan av is under ytan. Operativ AI är samma sak. Rörsystemet under ytan är vad som gör eller bryter det.

Historiskt har vi aldrig behandlat orkestrering och tillit som separata lager, eftersom människor gjorde det mesta av det arbetet. Orkestrering betydde chefer och köer; tillit betydde användarnamn och lösenord. Nu måste du lita på entiteter – agenter – för att göra saker, och du måste koordinera flera agenter i realtid runt dynamiska data. Det är ett helt annat designproblem, vilket är varför dessa lager måste vara explicita.

Lagret som de flesta människor underskattar är tillit. Många organisationer tror att de hanterar tillit, eftersom de har åtkomstkontroll – vem som kan logga in på vilket system. Men riktig tillit i en agensvärld är inte “har den här användaren åtkomst?” Det är “är den här specifika åtgärden lämplig för den här personen eller den här agenten vid den här tidpunkten?” Det är en styrningsfråga, inte en åtkomstkontrollfråga. Om du inte gör det lagret explicit, fastnar du i demo-land, eftersom du aldrig kommer att vara bekväm med att låta agenter göra riktigt arbete i produktion.

Så, tillit är uppenbarligen en grundläggande del av din AI-strategi. Hur designar du system så att automatiserade beslut förblir observerbara, granskningsbara och återställningsbara, samtidigt som de rör sig tillräckligt snabbt för att leverera affärsnytta?

Du måste börja med en noll-tillitsmentalitet. Den första frågan är inte “kan den här agenten tekniskt göra detta?” Den första frågan är “ska den här agenten, på uppdrag av den här personen, försöka göra detta alls?” Om svaret är nej, gå inte vidare.

Om svaret är ja, går du in i skyddsräcken: granskningsbarhet, spårbarhet och behovet av en människa i loopen. Vår modell bygger på ett tillitlager som fungerar som en trafikpolis i början av varje interaktion: vem är du, vad gör du och varför gör du detta? Det eliminerar många säkerhetsproblem, eftersom du inte låter agenter springa iväg och göra saker och sedan hoppas att du märker det efteråt.

Alternativet är att släppa lös agenterna och sedan höja en varning om de går och gör något dåligt. Du antar att du kan se det, förstå det, identifiera det och stoppa det i realtid, i den takt och skala som dessa system opererar. Det är ett mycket svårt problem, och det är varför så många människor kämpar – de försöker leta efter dåliga aktörer i realtid istället för att förhindra dåliga åtgärder från första början.

På toppen av det har vi lagt till skiktade grindar. Även om en agent agerar på uppdrag av rätt person, tittar vi fortfarande på sessionen och innehållet – försöker de förgifta en modell, missbruka en API eller skjuta något utanför policyn? Allt detta är inneslutet i fullständig observerbarhet, så att du kan granska vad som hände och återställa det om du behöver. Det är så du rör dig snabbt och sover gott om natten.

Många företag lyckas generera AI-insikter, men kämpar med att översätta dem till åtgärder. Vilka designbeslut tillät Calix att trycka AI direkt in i dagliga arbetsflöden över marknadsföring, drift och kundsupport?

Länge innan AI var stjärnan i showen, var vi på Calix redan besatta av en fråga: vad gör en insikt riktigt åtgärdbar för en riktig person i ett riktigt jobb? Sedan 2018 har vi arbetat med tjänsteleverantörer för att förstå hur olika roller fungerar – vad en marknadsförare gör på en tisdagsmorgon, vad ett driftsteam gör när en varning utlöses, vad supportteam gör när en abonnent ringer in arg. Det tvingade oss att bli mycket precisa om vilka insikter som betydde något för vem, i vilken kontext och vad “bra åtgärd” såg ut.

Så, när agensbaserad AI kom, började vi inte från scratch. Vi hade redan realtidsystem som genererade åtgärdbara insikter kopplade till specifika roller och arbetsflöden. Designfrågan blev: givet ett annat verktygssortiment och en annan teknikstack, hur skulle du omstrukturera dessa arbetsflöden i en agensbaserad AI-värld, istället för att försöka uppfinna allt detta från scratch?

När du parar detta djupa roller-kunskap med agensbaserad AI, kan du bygga dynamiska arbetsflöden över dynamiska data. Agenter kan avgöra i realtid vilka steg och vilka roller som behöver vara involverade, baserat på vad som händer, istället för att tvinga dig att hårkoda hundratals rigida flöden i mikrotjänster. För de flesta företag är det svåra problemet just nu att försöka fatta beslut i realtid baserat på kontext och sedan designa rätt arbetsflöde runt det. För oss var det redan på plats; vi hade redan byggt realtids-, rollerbaserade, åtgärdbara insikter i åratal. Agensbaserad AI är bara ett nytt verktygssortiment på toppen av den grunden.

Din plattformsvision inkluderar agent-till-agent (A2A) interoperabilitet och federerade AI-system. Hur förändrar detta tillvägagångssätt sättet som företagsverktyg samarbetar jämfört med traditionella punktintegrationer?

Om du tittar på de senaste 20 åren, har standardmönstret varit “köp en massa SaaS-verktyg och koppla ihop dem runt ett datawarehouse”. Varje nytt system betydde en ny punktintegration, en ny datapipeline och en ny plats att försona sanningen. I en agensvärld fungerar det inte. Du vill att datan ska stanna där den hör hemma och att agenter pratar med varandra över väldefinierade gränssnitt.

Det är varför vi pratar om att röra systemet på två lager: MCP på kunskapslagret och A2A på orkestrerings- och tillitlagren. MCP är hur agenter upptäcker och använder verktyg och data utan en ny anpassad integration varje gång. A2A är hur agenter koordinerar arbete med varandra under tydliga skyddsräcken.

När du har det, slutar samarbetet att se ut som en hög med sköra anslutningar och börjar se ut som ett nätverk av specialister som kan dynamiskt samarbeta runt riktigt arbete. Här kommer Eisenhower-matrisanalogen in. Inte allt är lika brådskande och lika viktigt. Vissa arbeten är verkligen tidskritiska, vissa är viktiga men kan schemaläggas, vissa behöver bara bli gjorda och vissa är brus. Med agent-till-agent-koordination som sitter på toppen av ett tillit- och orkestreringslager, kan du behandla dessa kategorier olika i stor skala: agenter kan svärma runt de brådskande och viktiga problemen, köa eller schemalägga de viktiga men inte brådskande, och hålla det lågvärdesiga arbetet från att tränga undan allt annat.

Det är en helt annan värld än “låt oss lägga till en till anslutning och hoppas att kön töms”. Du ser i själva verket betrodda, noggrant orkestrerade dynamiska arbetsflöden runt dynamiska händelser och data, istället för en röra av engångsintegrationer där allt ropar med samma prioritet.

När AI-agenter tillåts agera autonomt, blir styrning snabbt en utmaning. Hur balanserar du hastighet, ansvar och mänsklig övervakning när AI-system fattar eller verkställer beslut i stor skala?

Misstaget jag ser är att människor tror att de kan skruva fast agensbaserad AI på vad de redan har och sedan försöka “balansera” hastighet, ansvar och mänsklig övervakning efteråt. Du kan inte. Du måste börja med att erkänna att det är ett vertikalt teknikstackproblem och bygga en tillitlager och ett orkestreringslager. Utan dessa två lager, blir det en fri för alla – allt är först till kvarn, eller vem som ropar högst.

Igen, det är Eisenhower-matrisen: inte allt arbete är skapat lika. Tillit och orkestrering är hur du operationaliserar det i en agensvärld. Du vill inte att varje agent ska behandla varje uppgift som en brandkårsutryckning; du vill att systemet ska veta vad som verkligen är tidskritiskt, vad som kan schemaläggas och vad som ska hanteras tyst i bakgrunden.

Och sedan finns det “smal över fet” -delen. De flesta företag misstar större påverkan från AI med att stanna bred. Du är mycket bättre på att välja en smal vertikal skiva – ett konkret användningsfall, ett uppsättning arbetsflöden – och bygga den tillit och orkestrering du behöver där först. Bli smalare i vertikalen, få det rätt, håll människor i loopen på kanterna och expandera sedan. Det är hur du rör dig snabbt, stannar ansvarig och undviker att skapa en röra som du inte kan vrida tillbaka senare.

Från din erfarenhet av att leda stora globala produkt- och teknikteam, vilka organisations- eller kulturella förändringar krävs för att AI ska bli en hållbar företagsförmåga snarare än en samling frånkopplade piloter?

De flesta företag har inte ett “AI-problem”; de har ett kunskaps- och arbetsflödesproblem. Den första förändringen är att sluta leka med punktlösningar och flytta från datawarehouse till ett federerat kunskapslager som alla kan se och agera på. Så länge kunskapen bor i silos och AI är en körsbär på toppen av varje silo, kommer du att få piloter, inte transformation.

Från där, måste du vara villig att gå efter de svårare problemen i en specifik ordning. Steg ett är att skilja hype från verklighet och anta vad som fungerar, inte vad som är högst i din flöde. Steg två är att omstrukturera kunskapslagret så att du kan omvandla data till delad, federerad kontext istället för en till rapport begraven i ett system. Steg tre är att tänka om arbetsflöden runt den kunskapen och ett riktigt tillitlager – de flesta arbeten idag är organiserade runt människor, färdigheter och lokala kunskapssilor. Om du inte förändrar det, kommer agenter att vara bara ett verktyg som kretsar runt samma gamla flaskhalsar.

Bara då kommer du till den kulturella förändringen, som ofta är den svåraste. Du behöver en kultur där människor inte främst är oroliga för att förlora sina jobb, verktyg eller identitet, utan är genuint entusiastiska över att arbeta med nya förmågor. Det är ett förändringsledningsproblem, inte ett tekniskt problem. Det ser ut som riktad, distribuerad ledning: människor på spetsen av spjutet förstår arbetsflödena, känner sig säkra på att namnge friktionen och är entusiastiska över att sätta agenter i arbete på det.

Bortom bredband och telekom, vilka branscher tror du är bäst lämpade att anta operativ, agentdriven AI nästa, och vad är förutsättningarna som gör dem redo?

Jag tänker inte på det som att välja vinnare efter branschetikett; jag tänker på mönster. Nästan varje vertikal har samma underliggande utmaning: de har byggt data silos och funktion silos istället för en vy över tre livscykler – kund, anställd och produkt. De som är redo är de som är villiga att se det, erkänna att de inte har ett riktigt kunskapslager och fixa det.

Från där, ser förutsättningarna ganska lika ut oavsett om du är i hälsovård, fintech, detaljhandel eller kritisk infrastruktur. Du behöver komplexa arbetsflöden där människor är utsträckta, riktiga friktionspunkter som du kan namnge och tillräckligt med högkvalitativa data för att ge agenter kontext. Om du kan karta nuvarande arbetsflöden, se var arbetet sakta ner eller hoppar upp, förstå vilka överlämningar skapar förseningar och sedan backa det med ett federerat kunskapslager, blir agensbaserad AI ett otroligt verktygssortiment.

I den världen är “branschberedskap” en ledarskapsfråga. Är ett företags ledare villiga att flytta bortom marknadsföringsverktyg och tunna horisontella instrumentpaneler och istället investera i en vertikal teknikstack – omvandla data till kunskap, federera den kunskapen, lägga till orkestrerings- och tillitramverk och ha ärliga samtal om var den riktiga ROI:n är? Varje företag i varje bransch som gör det arbetet är väl lämpat för operativ, agentdriven AI; de som inte gör det kommer att fastna i att lägga till ett till verktyg i en redan bullrig hög.

När företags-AI utvecklas mot multi-agent och multi-molnmiljöer, vad ser bra AI-arkitektur ut som om fem år, och vilka principer bör ledare åta sig idag för att undvika att bygga om sina system senare?

Om fem år kommer den intressanta delen av AI inte att vara de enskilda agenterna eller modellerna; det kommer att vara de agensbaserade arbetsflödena de möjliggör och det affärsnytta dessa arbetsflöden levererar. Agenter i sig kommer och går. Lagren under dem – data, kunskap, orkestrering, tillit och åtgärd – kommer att fortsätta att utvecklas, men behovet av dem försvinner inte.

Det är därför jag är mer fokuserad på arkitektur än på något specifikt verktyg. Vi flyttar från datawarehouse till federerade kunskapslager, från sköra punktintegrationer till öppna, skiktade stackar. I den världen kommer du att ha agenter som körs i olika moln, som rör olika kunskapskällor och som koordinerar över väldefinierade gränssnitt – MCP på kunskapslagret, agent-till-agent-protokoll på orkestrerings- och tillitlagren. När tekniken förbättras, vill du kunna byta in bättre bitar i dessa lager utan att bygga om allt igen.

Så, principerna för ledare är enkla. Bygg inte monolitiskt. Designa för lager så att data, kunskap, orkestrering, tillit och åtgärd kan utvecklas oberoende. Designa för flöden, inte funktioner, så att du är tydlig med vilka arbetsflöden som betyder något och vad “bra” ser ut i kund-, anställd- och produktlivscykler. Och designa för styrning på agentnivå: anta nolltillit som standard, definiera tydliga “agentkort” och använd orkestrering för att bestämma vad som är brådskande, vad som är viktigt och vad som bara behöver bli gjort. Om du gör det, kan du låta tekniken förändras – som den alltid gör – utan att ständigt oroa dig för att bygga om.

Tack för det underbara samtalet, läsare som vill lära sig mer bör besöka Calix.