Sushil Kumar, VD för Cyara – Intervjuserie

Sushil Kumar, VD för Cyara är en erfaren ledare inom företagsprogramvara och entreprenör med mer än 25 år av ledarskap inom artificiell intelligens, DevOps, molninfrastruktur, produktstrategi och programvarutestning. Han gick in som VD för Cyara i december 2025, efter sin roll som medgrundare och VD för RelicX.ai, där han byggde en generativ AI‑driven, avsiktsbaserad testautomatiseringsplattform som förvärvades av Harness. Därefter ledde han integrationen av RelicX:s teknik i Harness och hjälpte till att forma företagets strategi för AI‑testautomatisering. Tidigare i sin karriär var Kumar General Manager för DevOps på Broadcom, Senior Vice President för produkter på CA Technologies, och tillbringade mer än 16 år på Oracle, där han hade seniora produktledarskapsroller och hjälpte till att skala stora företagsprogramvaruföretag. Genom dessa roller har han fokuserat på att bygga och skala AI‑, moln‑, DevOps‑ och automatiseringsplattformar för stora företag. Hans tillsättning på Cyara är inriktad på att utöka företagets AI‑drivna funktioner för kundupplevelsegaranti och globala räckvidd.

Cyara är ett företag för kundupplevelsegaranti som hjälper företag att testa, övervaka och validera kundinteraktioner över röst, digitala, meddelande‑ och konversations‑AI‑kanaler. Dess Cyara Agentic Platform är utformad för att bemöta de växande utmaningarna som skapats av AI‑drivna kundupplevelser, inklusive testning av icke‑deterministiska AI‑agenter, upptäckt av hallucinationer och beteendedrift, validering av efterlevnad, övervakning av produktionssystem och bedömning av end‑to‑end‑kundresor. Plattformen kombinerar AI‑agenttestning, produktionsövervakning, röst‑ och telekommunikationsgaranti, digitalkanaltestning och CX‑observabilitet, och stödjer mer än 350 miljoner kundresor årligen över ett globalt fotavtryck som omfattar mer än 140 länder. När företag implementerar alltmer autonoma AI‑agenter i kundorienterade arbetsflöden positionerar Cyara sin teknik som ett garantilager för att utvärdera om dessa system beter sig pålitligt, säkert och konsekvent före och efter driftsättning.

Du har tillbringat större delen av din karriär med att bygga och skala företagsprogramvara, från Oracle och CA/Broadcom till att grunda Relicx och nu leda Cyara. Hur har den erfarenheten format din syn på att AI‑agenter bör hanteras mindre som traditionell programvara och mer som medlemmar i en arbetsstyrka?

Jag har tillbringat största delen av min karriär med att bygga och skala företagsprogramvara, och den disciplin vi byggde där var en disciplin kring deterministiska system. Du vet vad programvaran förväntas göra. Du validerar den mot den förväntningen. När den går sönder, talar den om för dig: ett fel, en misslyckad transaktion, ett larm.

AI‑agenter fungerar inte så. De är icke‑deterministiska, så samma inmatning kan ta en annan väg. Dessutom kan de agera på företagets vägnar. De gör åtaganden: återbetalningar, policys, löften. Och när ett av dessa är fel, går inget sönder. Ett fel svar låter exakt som ett rätt svar. Transaktionen lyckas, instrumentpanelen förblir grön, och kunden går därifrån med något som företaget aldrig har gått med på.

När programvara kan fatta beslut och åtaganden, och kan ha fel utan att meddela dig, krävs en annan driftsmodell.

Det är här jämförelsen med arbetskraften visar sitt värde. Du styr inte en anställd genom att skript varje beslut de kommer att fatta. Du ger dem en roll, du fastställer den auktoritet som följer med den, och du utökar den auktoriteten när de förtjänar det. En agent beter sig på samma sätt under samma struktur.

Min slutsats är att autonomi inte är ett driftsättningsbeslut. Det är en serie befordringar. En agent tjänar varje befordran genom att visa att den kan utföra jobbet, hålla sig inom sin auktoritet och inse när den behöver hjälp.

Hur ser en \”HR‑liknande\” driftsmodell för AI‑agenter faktiskt ut inom ett företag, och vilka element bör företag införa först?

Börja med jobbet. Varje agent bör ha något som liknar en arbetsbeskrivning innan den går in i produktion. Vad är den där för att uppnå, vilken information är auktoritativ för den, vilka kunddata kan den använda, vilka beslut kan den fatta på egen hand, och var slutar dess ansvar. Om ett företag inte kan skriva ner detta i ett stycke är agenten inte redo för en roll. Den är redo för en demo.

Fyra saker följer av den rollen, och ordningen är viktig. Bevis innan lansering, vilket innebär att bevisa att agenten kan utföra jobbet under förhållanden som liknar den verkliga världen snarare än ett kontrollerat test. Övervakning medan den körs, så du vet vad agenten faktiskt gjorde och inte bara om systemet svarade. Befordringsgrindar, så mer auktoritet beviljas när det finns bevis som stödjer det och inte tidigare. Och en ägare i verksamheten, inte i ingenjörsavdelningen, som är ansvarig för vad den agenten får göra.

Får du ordningen fel så håller resten inte. Om ansvaret är otydligt är god prestanda omöjlig att bevisa, likaså misslyckande. Rollen kommer först, och bevisen följer.

Om en AI‑agent tilldelas en specifik roll, hur bör organisationer definiera dess ansvar, behörigheter och gränser innan den får interagera med kunder eller kritiska system?

Rollen beskriver vad agenten är avsedd för. Behörigheterna anger vad den kan nå. Det är två olika samtal, och företag tenderar att bara ha det första.

Var tydlig med tre saker. Vilka system och data agenten får röra vid, och i vilken riktning, eftersom läsning av en kundpost och ändring av en sådan inte är samma behörighet. Vad den kan åta sig på egen hand, vilket är där pengarna och ansvaret ligger: en återbetalning, en kredit, ett undantag från policyn. Och vad som tvingar fram en överlämning, både de fall du kan namnge i förväg och signalen att agenten har gått utanför sin kompetens.

Detta är inte beslut som ska lämnas åt teknikteamet. De avgör den risk företaget tar. Personerna som ansvarar för kundupplevelsen och efterlevnadsriskerna måste ha ett ord med i när de linjerna dras, och de är vanligtvis de sista som blir tillfrågade.

Därefter måste du bevisa att agenten håller sig inom dem. Målet är inte att eliminera varje möjlig fel. Det kommer att bli fel. Frågan är om agenten förstår sina gränser, vet när den ska sluta, och kan utföra det arbete den har fått utan att skapa konsekvenser någon annanstans i kundresan.

Du hävdar att större autonomi bör förtjänas snarare än beviljas från början. Vad bör en AI‑agent visa innan ett företag utökar omfattningen av handlingar den kan utföra självständigt?

Det är nu enkelt att bygga en AI‑agent. Den svåra delen är att bevisa att den förtjänar autonomi.

Innan ett företag utökar vad en agent kan göra på egen hand, behöver det bevis på att den utför sitt tilldelade arbete konsekvent och håller sig inom sina gränser. Det innebär hur den hanterar de situationer du förväntar dig, och även de du inte förutsett. En agent kan framstå som stark under kontrollerade förhållanden men agera annorlunda när kontexten eller de omgivande systemen förändras.

En kund kan börja med en enkel faktureringsfråga och bli frustrerad efter en misslyckad betalning. Agenten måste känna igen den förändringen i realtid och ändra kurs, i stället för att fortsätta på den bana den validerades för.

Tre saker bör vara sanna innan befogenheten utökas. Agenten utför jobbet under verkliga förhållanden, inte bara under ideala. Den känner till gränsen för sin egen kompetens och stannar där. Och någon kan på begäran producera bevis för båda.

Bevisnivån måste motsvara autonominivån. Små beslut, lätt bevis. Tillgång till ett betalningssystem eller förmågan att binda företaget till ett policyundantag bör ha en avsevärt högre tröskel.

Hur bör företag kontinuerligt utvärdera AI‑agenters prestanda när de väl är i drift, särskilt när kvaliteten på deras beslut inte kan fångas enbart av traditionella mjukvarutestningsmått?

Här faller traditionellt mjukvarutänkande samman. Med deterministisk mjukvara testar du om något klarat eller misslyckats. Med en AI‑agent kan du få ett lyckat svar från systemet men ändå ha en misslyckad kundinteraktion.

Så utvärderar du resultatet, inte svaret. Förstod agenten vad kunden försökte åstadkomma? Använde den rätt information? Slutförde den resan? Höll den sig inom sina gränser och eskalerade när det var nödvändigt?

Grundläggande utvärderingar, där svar poängsätts mot ett guldstandardset, är miniminivån. Alla företag kommer att ha dem. De dimensioner som avgör om en kund fortsätter att lita på dig är de underliggande: efterlevnad, bias, missbruk och hur agenten klarar sig med riktiga samtalspartners, deras accent, bakgrundsljud, den billiga telefonen, avbrottet mitt i en mening. I röst är detta viktigare än vad folk förväntar sig, eftersom varje poäng baseras på ett transkript. Om tallagret missuppfattar frågan svarar agenten på en fråga som ingen ställde.

Arithmetiken är värd att fundera på. En 99 % poäng i utvärderingen låter utmärkt. Vid en miljon konversationer per år innebär det tiotusen misslyckade.

Två principer håller. Valideringen bör vara oberoende av agenten och modellplattformarna. Vi bygger inte agenterna själva, vilket är en del av varför jag tydligt kan säga att ingen leverantör bör vara domare över sin egen AI. Standard är företagets egna policyer, dess kundåtaganden och dess regulatoriska skyldigheter, inte en leverantörs poängkort.

Och varje produktionsfel bör bli en grind. Inte ett ärende, inte ett backlog‑objekt. Ett test som agenten måste klara innan nästa version släpps. Om ett problem uppstår i produktion och det inte blir något som agenten måste klara, betalar du för att upptäcka samma problem två gånger.

Förtroende och styrning nämns allt oftare som stora hinder för att skala agentbaserad AI. Anser du att teknologin utvecklas snabbare än företagens förmåga att övervaka den, och vilka risker medför det?

Jag tror att det är precis vad som händer, och klyftan är strukturell snarare än ett resultat av bristande ansträngning. En idé kan bli en kundfokuserad agent på några veckor. Driftsdisciplinen kring den agenten, ägandet, bevisen, tillsynen, tar mycket längre tid, eftersom det involverar människor och ansvar, inte bara mjukvara.

Risken är att klyftan förblir osynlig medan den vidgas. En agent kan ge en kund ett självsäkert felaktigt svar utan fel, utan misslyckad transaktion och utan varning. Varje instrumentpanel ser grön ut. Traditionella operationer förlitar sig på att systemen talar om när de är i trubbel, och agenter gör det inte på ett pålitligt sätt.

Jag tror inte att svaret är att sakta ner. Företagen som vinner här kommer att gå snabbt. Svaret är att bygga den evidens och tillsyn som låter dig gå snabbt med förtroende. Ju mer autonomi en agent får, desto mer bevis behöver du för att den ska kunna bära ansvaret.

När en autonom agent fattar ett dåligt beslut, vem bör i slutändan hållas ansvarig: utvecklaren, affärsenheten som implementerar den, leverantören av modellen eller chefen som godkände dess användning?

I slutändan äger företaget som implementerar agenten resultatet. Flera parter är involverade i att bygga och driva systemet, men kunden har ingen relation till modellleverantören. Kunden har en relation till företaget vars namn står på interaktionen.

Det betyder inte att ansvaret ligger hos en enda person. Det löper genom beslutskedjan. Utvecklaren är ansvarig för hur systemet byggdes. Företaget bestämmer vad agenten får göra. Leverantören är ansvarig för den teknik den tillhandahåller. Ledningen är ansvarig för att säkerställa att företaget har kontroller och tillsyn för att hantera risken fullt ut.

Felet är att tro att eftersom modellen fattade beslutet, så äger modellen det. Det gör den inte. Om en agent gör ett åtagande till en kund på dina vägnar, tillhör det åtagandet varumärket. Kunder förstår detta intuitivt, och det gör även regulatorer.

AI-agenter kan bete sig oförutsägbart när de möter situationer som inte förutsågs under testning. Hur bör företag testa dessa kantfall innan agenter får tillgång till kunder, finansiella system eller känslig data?

Du måste anta att agenten så småningom kommer att stöta på något den inte är designad för. Frågan är vad som händer när det sker.

Så validera bortom den förväntade vägen. Ge agenten tvetydiga förfrågningar. Ge den motstridig information. Ge den ofullständig kontext. Placera den i situationer där det rätta svaret är att stanna och eskalera snarare än att fortsätta. Lägg till verkliga förhållanden, vilket i röst innebär accenter, brus, dåliga anslutningar och samtalspartners som byter ämne halvvägs. Målet är inte att bekräfta att agenten fungerar. Det är att ta reda på hur den beter sig när förhållandena inte är rena.

Den viktigare poängen är att du måste validera hela resan, inte bara agenten i isolering. Modellen är vanligtvis inte problemet. När något går fel är min första fråga vilken kontext modellen fick. Det kan ha varit en föråldrad kunskapsartikel, eller två system med motstridiga policys, eller ett överlämnande som tappade det kunden redan förklarat. Varje komponent kan klara sitt eget test och ändå kan kundresan misslyckas i skarvarna mellan dem.

Det lager mellan systemen är det vi har spenderat år på att instrumentera, över 450 företag och mer än 350 miljoner kundresor per år. Agentbaserat eller inte, det går sönder på samma sätt. Vi ser också agenter byggda på teknik från mer än 55 olika leverantörer, plus varje större kontaktcenterplattform, vilket är hur vi vet att mönstret gäller oavsett vilken modell som ligger under.

Innan en agent får tillgång till något som är viktigt bör företaget ha bevis på vad den gör när saker går rätt och när de inte gör det.

Hur ser du på AI-testningens utveckling när företag går från deterministisk mjukvara till system som resonerar, planerar, kommunicerar och agerar över flera applikationer?

Testning måste gå från att fråga om ett system levererade det förväntade svaret till att fråga om det uppnådde rätt resultat.

Det är en betydande förändring. En agent kan ta flera olika vägar för att lösa samma kundproblem, och dessa vägar kan förändras över tid när modellerna och kunskapen bakom dem förändras. Du kan inte skriva ett skript för varje möjlig interaktion. Du måste utvärdera om agenten förstod avsikten, fattade sunda beslut längs vägen och höll sig inom de gränser som gavs.

Jag vill vara försiktig med en sak, för branschen börjar göra fel på ett dyrt sätt. Testning före lansering är viktigare nu, inte mindre. Det är vad som fastställer om en agent är redo. Argumentet att du kan hoppa över det och i stället observera produktion är ett argument för att upptäcka problem inför kunderna.

Det som förändras är att testning före lansering inte längre är slutet på processen. Produktion avslöjar förhållanden som en kontrollerad miljö inte kan reproducera helt, och vad produktionen avslöjar blir ett test som agenten måste klara innan nästa release. Bevis före lansering, vaksamhet i produktion, och att varje steg matar in i det andra. Agenten som körs i sjätte månaden bör vara mätbart bättre än den som lanserades.

Framåt i tiden, vad kommer att särskilja organisationer som framgångsrikt bygger pålitliga AI-arbetsstyrkor från de som fortfarande sitter fast i små agentbaserade AI-piloter?

De organisationer som får verklig avkastning från agenter är de som har byggt en operativ modell kring bevis. De som stagnerar är vanligtvis inte hindrade av tekniken. De hindras eftersom ingen kan leverera det som nästa godkännandenivå kräver. Juridik ställer en rimlig fråga, eller så gör riskkommittén, och det finns inget svar, så pilotprojektet förblir ett pilotprojekt. Tekniken kan vara klar, men organisationen kan fortfarande inte motivera att ge den mer befogenhet.

Det är skillnaden mellan ett pilotprojekt och en operativ arbetsstyrka. I ett pilotprojekt är någon alltid iakttagande. I en operativ modell har varje agent ett uppdrag som du kan uttrycka i en mening. Dess befogenheter är begränsade och dokumenterade. Dess prestation utvärderas av något annat än teamet som skapade den. Produktionsfel blir utgivningsgrindar. Mer autonomi följer på bevis.

Den andra skillnaden är ägande. I de företag som skalar tillhör agenten den affärsfunktion den betjänar, med en utsedd ägare som ansvarar för vad den gör. När den förblir ett AI‑projekt som ägs av ett AI‑team, förblir den liten, eftersom ingen affärsledare kommer att ta på sig risken för något de inte kontrollerar.

Inget av detta är exotiskt. Det ligger nära hur ett företag redan hanterar de personer de litar på med verkligt ansvar.

Ett pilotprojekt kan drivas på en organisations övertygelse. Skalning kräver bevis.

Tack för den stora intervjun, läsare som vill lära sig mer bör besöka Cyara.