Vijay Rayapati, administrerende direktør og medgründer av Atomicwork – Intervjuserie

Vijay Rayapati er medgründer og administrerende direktør i Atomicwork. Før han grunnla selskapet, var han senior visepresident og general manager for Cloud Networking and Security‑virksomheten i Nutanix, etter at Nutanix kjøpte opp Minjar, skyadministrasjonsplattformen han hadde grunnlagt og skalert som administrerende direktør. Tidligere i karrieren hadde han lederroller innen engineering og produkt i Kuliza og Trilogy, noe som ga ham dyp erfaring med å bygge bedriftsinfrastruktur og programvareapplikasjoner. Bakgrunnen hans spenner over skyinfrastruktur, bedriftsprogramvare og AI‑arbeidsstyrketeknologi, og gjør ham til en anerkjent gründer i enterprise‑IT‑sektoren.

Atomicwork er et enterprise AI‑selskap som bygger en agentbasert IT‑service management‑plattform som hjelper ansatte med å løse teknologiproblemer, automatisere rutine‑supportoppgaver og få tilgang til bedriftskunnskap via AI. Plattformen kombinerer AI‑agenter med moderne ITSM‑funksjoner for å håndtere tjenesteforespørsler, feilsøke problemer, orkestrere arbeidsflyter på tvers av bedriftsystemer og redusere belastningen på IT‑teamene. Kunder bruker Atomicwork for å levere raskere ansattstøtte samtidig som de forbedrer operasjonell effektivitet på tvers av IT‑ og forretningsoperasjoner.

Du var medgründer av Minjar, bygde opp deres enterprise skyadministrasjonsvirksomhet, og ledet deretter driften i Nutanix etter oppkjøpet. Hvilke lærdommer fra å bygge, selge og integrere et enterprise‑programvareselskap overbeviste deg om å grunnlegge Atomicwork i 2022 og bygge IT‑service management fra bunnen av for AI‑æraen?

Hos Minjar utviklet vi programvare som kunne kutte en bedrifts skyregning med en tredjedel gjennom automatisering. Kundene elsket anbefalingene. Så satte de dem på vent i to kvartaler. Det tok meg en stund å forstå hvorfor, og svaret var ikke teknisk. Når automatisering gjør et kall og det går galt, er det ingen å holde ansvarlig. Bedrifter kjøper ikke bare programvare eller resultater. De kjøper noen som svarer for dem. Programvare uten en plass i organisasjonskartet får ingen myndighet, uansett hvor god den er.

Oppkjøpet ga meg en smalere lærdom. Punktprodukter blir kjøpt. Systemer for registrering blir bygget på. Du kan være det bedre produktet og likevel bruke livet ditt på å omgå den som eier arbeidsflyten.

Nutanix‑årene satte de to sammen. Jeg så IT kjøpe service management for kontroll, mens ansatte opplevde det som et skjema og en kø. Jeg innså også at saken aldri var produktet. Det var revisjonssporen. Det er derfor ITSM har overlevd i førti år med folk som misliker det, og også grunnen til at ingen kunne fjerne det.

Så spørsmålet i 2022 var ikke om AI kunne utføre arbeidet. Det var om du kunne gi AI en plass i organisasjonskartet. Eldre ITSM‑plattformer kan ikke dette, fordi en menneskelig tildelt sitter i sentrum av deres datamodell, og hver SLA, godkjenning og rapport henger på den forutsetningen. Legg til AI, og du får et raskere skjema.

Vi bygde for det andre svaret, hvor AI leverer en hybrid arbeidsstyrke, ikke bare programvare. AI‑medarbeidere gjør arbeidet, og IT styrer dem på samme måte som HR styrer mennesker. Du konfigurerer ikke en AI‑medarbeider. Du ansetter den i en rolle, vurderer arbeidet dens, og tilbakekaller den hvis den ikke presterer. Det er forskjellen mellom AI som en funksjon og AI som en arbeidsstyrke.

Atomicwork beskriver sine AI‑medarbeidere som systemer som eier definerte arbeidsroller og fullfører arbeid fra start til slutt, snarere enn bare å svare på spørsmål eller utføre isolerte oppgaver. Hvilke tekniske evner skiller en ekte AI‑medarbeider fra en chatbot, en copilot eller et tradisjonelt automatiseringsverktøy, og hvor bør autonomien stoppe?

En chatbot svarer på et spørsmål, og en copilot hjelper noen med å fullføre en oppgave, men ingen av dem er ansvarlige for å føre arbeidet til fullføring. En AI‑medarbeider er annerledes fordi den er tildelt en definert rolle og forventes å levere et resultat. Enten den triagerer hendelser, provisjonerer tilgang eller ombordstiller ansatte, fortsetter den arbeidet gjennom hvert trinn for å nå målet i stedet for å stoppe etter første svar.

Det krever mye mer enn en kapabel modell. En AI‑medarbeider trenger en identitet, riktige tillatelser, tilgang til godkjente verktøy, organisatorisk kontekst, et budsjett og klare driftsgrenser for sin rolle. Den må kunne jobbe på tvers av forretningssystemer, forstå når (og hvem) den skal be om godkjenning, og legge igjen et revisjonsspor for hver handling. Derfor har vi lagt så stor vekt på plattformen rundt modellen. Pålitelig AI avhenger av orkestrering, styring og utførelse like mye som av intelligens.

Autonomi bør aldri være ubegrenset. En AI‑medarbeider bør operere innenfor ansvarsområdene i sin arbeidsrolle, mens mennesker forblir involvert når arbeidet påvirker sensitive systemer eller har juridiske, økonomiske eller ansettelsesmessige implikasjoner.

Plattformen deres gjør det mulig for spesialiserte AI‑medarbeidere å samarbeide på tvers av hendelsesstyring, tilgangsprovisjonering, onboarding og IT‑operasjoner. Hvordan deler disse AI‑medarbeiderne ansvar, deler kontekst, og gjenoppretter når en AI‑medarbeider tar en feil beslutning som kan påvirke resten av arbeidsflyten?

Vi mener ikke at én AI‑medarbeider skal prøve å gjøre alle jobber. IT‑organisasjoner deler allerede ansvar på tvers av ulike team fordi hver rolle har ulike mål, tillatelser og ekspertise. Vi har anvendt den samme tankegangen på AI‑medarbeidere, og derfor lanserte vi med sertifiserte AI‑medarbeidere som spesialiserer seg i ulike IT‑operasjonelle områder.

Hver medarbeider eier en spesifikk funksjon mens de deler samme bedriftskontekst. Når en ansatt oppretter en sak i Atomicwork, sikrer smart ruting at den blir sendt til riktig AI‑medarbeider som jobber med forespørselen og (avhengig av forespørselen) videresender den til en annen AI‑medarbeider, oppretter under‑saker for AI‑medarbeidere slik at problemet kan løses parallelt (for eksempel kan en onboarding‑sak deles opp i aktiviteter som kan arbeides med samtidig) eller eskalerer den til et menneske. Etter hvert som arbeidet flytter fra én medarbeider til en annen, flytter den relevante informasjonen med seg gjennom saken (systemet for registrering), sammen med tilgang til relevante systemer som servicedesken, identitetsplattformer, HR‑systemer og samarbeidsverktøy. Den delte konteksten gjør at hver medarbeider kan ta beslutninger basert på hva som allerede har skjedd i stedet for å starte fra bunnen.

Atomicwork støtter ulike agent‑rammeverk og modeller fra leverandører som OpenAI, Anthropic og Google. Hvordan bestemmer dere hvilken modell som skal håndtere henting, resonnering, planlegging og utførelse, og hvordan kan bedrifter opprettholde konsistent oppførsel mens de underliggende modellene fortsetter å endres?

Ulike modeller er gode på ulike typer arbeid. Vår fokus har vært på å bygge en plattform som kan dra nytte av fremskritt uten å tvinge kundene til å redesigne arbeidsflytene hver gang en modell endres. Bedriftskontekst, orkestrering, identitet, policy‑håndheving, telemetri og evaluering gir den konsistensen organisasjoner trenger i produksjon, uavhengig av hvilken frontier‑modell som ligger under.

Vi har offentlig diskutert støtte for flere modellleverandører sammen med evalueringsrammeverk og styring, men vi har ikke beskrevet rutelogikken som bestemmer hvilken modell som håndterer henting, resonnering, planlegging eller utførelse. Vi har heller ikke delt valideringsprosessen vi bruker når leverandører slipper nye modeller og oppdateringer.

En enterprise‑AI‑agent kan støte på motstridende dokumentasjon, ufullstendige konfigurasjonsregistre, utdaterte kunnskaper og ulike tillatelser på tvers av systemer. Hvordan bestemmer Atomicworks Universal Context‑lag hvilken informasjon som er pålitelig og oppdatert før den tillater en agent å ta en beslutning eller handling?

Bedriftskunnskap finnes sjelden på ett sted. Noe av den lever i dokumentasjon, noe i systemer for registrering og noe i den daglige virksomheten. AI trenger all denne konteksten for å kunne ta pålitelige beslutninger.

Universal Context samler disse kildene ved å kombinere bedriftskunnskap med data om personer, nettverk, infrastruktur og enheter fra levende operasjonelle systemer. En AI‑medarbeider kan referere til informasjon fra plattformer som Confluence eller SharePoint, MDM‑systemer som Intune og JAMF, samtidig som den forstår hva som skjer i systemer som Jira, Workday, Salesforce eller identitetsleverandører. Den respekterer også eksisterende tillatelser, slik at personer og AI‑medarbeidere kun får tilgang til informasjon de allerede er autorisert til å se.

Vi har forklart hvordan Universal Context kobler sammen bedriftsystemer og bevarer sikkerhetsgrenser, men vi har ikke beskrevet hvordan den løser motstridende informasjon når pålitelige kilder er uenige eller hvordan den bestemmer hvilken kilde som skal ha forrang. Disse implementasjonsdetaljene er ikke en del av vår offentlige dokumentasjon.

Den universelle AI‑medarbeideren kan støtte ansatte via Microsoft Teams, Slack, e‑post, nettleser, portal og via chat, stemme og visuelle moduser. Hvilke nye feilsøkingsmuligheter blir mulig når en agent kan se og høre hva den ansatte opplever, og hvordan hindrer dere at sensitiv skjerminnhold eller samtaler blir eksponert?

Tradisjonell IT‑support er avhengig av at ansatte beskriver tekniske problemer nøyaktig, og det er ofte den vanskeligste delen av interaksjonen. Stemmen og visuell kontekst gjør at AI kan se den samme feilmeldingen, applikasjonen eller konfigurasjonsskjermen den ansatte ser på, noe som gjør det mye enklere å forstå problemet og veilede noen gjennom neste steg uten en lang frem‑ og tilbake‑samtale.

Disse funksjonene fungerer kun hvis ansatte har tillit til dem. Vi mener at visuell tilgang bør kreve eksplisitt samtykke, og brukere bør alltid vite når den er aktiv. Sensitiv informasjon beskyttes gjennom PII‑maskering, administrative kontroller og passende lagringspolicyer.

Vi har også vært tydelige på at kundedata ikke brukes til å trene våre modeller eller tredjeparts grunnmodeller. Det gir organisasjoner muligheten til å ta i bruk multimodal AI uten å gi fra seg kontrollen over sine data.

Atomicwork kan distribueres ved siden av et eksisterende ServiceNow‑ eller Jira Service Management‑miljø uten å kreve en umiddelbar migrasjon. Ser dere dette primært som en overgangsstrategi, eller vil mange bedrifter permanent operere en AI‑arbeidsstyrke over sitt eldre system for registrering?

De fleste store bedrifter har brukt år på å bygge prosesser, integrasjoner og styring rundt plattformer som ServiceNow og Jira Service Management. Å kreve at de erstatter disse systemene før de kan ta i bruk AI skaper unødvendig friksjon.

Vi bygde Atomicwork‑integrasjonene med ServiceNow og Jira Service Management slik at kunder kan transformere ansattopplevelsen og styrke sine serviceteam med AI‑medarbeidere fra dag én, uten å forstyrre systemene de allerede er avhengige av. Tilkoblingen henter inn relevant IT‑kontekst for AI‑medarbeidere å utnytte, samtidig som den opprettholder en toveis‑synkronisering for serviceagenter i deres eksisterende system. Vi mener ikke at bedrifter skal måtte velge én vei fra dag én. Prioriteten er å hjelpe dem med å ta i bruk AI i sitt eget tempo.

Å gi AI‑medarbeidere tilgang til identitetssystemer, ansattdata, infrastruktur og forretningsapplikasjoner introduserer risikoer som prompt‑injeksjon, forgiftede kunnskapskilder, overdrevne tillatelser og kaskaderende agent‑feil. Hvilke sikkerhetstiltak, godkjenningsgrenser og revisjonsmekanismer er nødvendige før en bedrift trygt kan la agenter handle autonomt?

AI‑medarbeidere styres som ansatte med privilegert tilgang. Hver medarbeider har en definert rolle, begrensede tillatelser, godkjente verktøy, forbruksgrenser og klare grenser for hva den kan gjøre uavhengig. Sensitive handlinger – spesielt de som involverer identitet, infrastruktur, økonomi, juridiske saker eller ansettelse – krever menneskelig godkjenning.

Ferdigheter og instruksjoner blir vurdert før publisering for risikoer som prompt‑injeksjon, skjulte instruksjoner, tilgang til legitimasjon, datalekkasjer og usikre handlinger. Hvis et verktøy endres på en måte som øker risikoen, blir det automatisk deaktivert til det er gjennomgått. Ytterligere sikkerhetstiltak – inkludert handlingsgrenser, forebygging av dupliserte handlinger, nød‑avstengningskontroller og menneskelig overtakelse – bidrar til å innkapsle feil før de sprer seg.

Hver handling er sporbar: organisasjoner kan se hva som utløste medarbeideren, hvilken informasjon og hvilke verktøy den brukte, hvilke godkjenninger som ble innhentet, og hvilket resultat som fulgte. Kontinuerlig evaluering, overvåking og red‑team‑testing sikrer at disse sikkerhetstiltakene forblir effektive etter hvert som modeller, verktøy og bedriftsmiljøer utvikler seg.

Vi har investert tungt i evaluering, policy‑håndheving, overvåking og red‑team‑testing fordi utrulling av AI bare er begynnelsen. Organisasjoner trenger tillit til at disse medarbeiderne fortsetter å oppføre seg som forventet når modeller og bedriftsmiljøer utvikler seg.

Atomicworks State of AI in IT 2026‑rapport fant at to tredjedeler av IT‑profesjonelle rapporterer positive avkastninger fra AI‑investeringer, mens kun én av fem organisasjoner har fullt integrert AI i sine service‑management‑team. Hva skiller implementeringer som gir målbar forretningsverdi fra pilotprosjekter som sitter fast i eksperimentering?

De fleste organisasjoner har allerede vist at AI kan forbedre individuelle oppgaver. De selskapene som ser målbar forretningsverdi, kobler AI til komplette operative arbeidsflyter i stedet for å bruke den som en frittstående assistent.

Det starter med å løse et spesifikt forretningsproblem ved å tenke i roller, gi AI‑medarbeidere tilgang til systemene de trenger og måle resultater som betyr noe – enten det er raskere løsningstid, lavere supportkostnader eller en bedre ansattopplevelse. Når teamene har tillit til disse resultatene, blir det mye enklere å utvide AI til flere arbeidsflyter.

Vår forskning fant også at ansvarlig AI fortsatt er en av de høyeste prioriteringene for IT‑ledere. Det gir mening fordi organisasjoner ikke vil gi AI mer ansvar med mindre de forstår hvordan den tar beslutninger, kan gjennomgå beslutningene i etterkant og vet at riktige sikkerhetsrammer er på plass.

Etter hvert som AI‑medarbeidere begynner å løse supportforespørsler, administrere tilgang, diagnostisere hendelser og koordinere arbeidsflyter, hvordan vil ansvarsområdene til service‑desk‑profesjonelle, IT‑operasjonsteam og Chief Information Officers endres? Ser vi fremover, kan IT bli avdelingen som er ansvarlig for å ansette, styre og måle en bedrifts komplette digitale arbeidsstyrke?

AI vil ta over mye av det repeterende operative arbeidet som i dag opptar service‑desker, slik at folk kan bruke mer tid på å håndtere unntak, forbedre prosesser og finpusse kunnskapen AI er avhengig av.

IT‑operasjonsteam vil i økende grad fokusere på å styre AI‑medarbeidere i stedet for å manuelt utføre hver arbeidsflyt. De vil definere tillatelser, koble systemer, overvåke ytelse og sikre at AI fortsetter å operere innenfor etablerte retningslinjer.

Jeg forventer også at CIO‑rollen vil utvides. Å håndtere hundrevis av AI‑medarbeidere begynner å ligne på å håndtere annen bedriftsinfrastruktur. Noen må bestemme hvilke systemer medarbeiderne kan få tilgang til, hvordan de måles, når de oppdateres og om de leverer verdi. Forretningsenheter vil fortsette å definere arbeidet, mens IT blir HR for AI, altså ansvarlig for plattformen, styring og operative kontroller som holder en enterprise AI‑arbeidsstyrke i sikker drift.

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