Moshe Sambol, VP för kundlösningar på Lightrun – Intervjuserie

Moshe Sambol, VP för kundlösningar på Lightrun, har mer än två decenniers erfarenhet inom mjukvaruutveckling, arkitektur, molninfrastruktur och teknisk ledning mot kunder. Innan han gick med i Lightrun 2022 tillbringade han nästan ett decennium på Google, där han hade flera ledande positioner, inklusive Cloud Customer Engineering Manager, som hjälpte organisationer att anta och skala upp Google Cloud-teknologier. Tidigare i sin karriär hade Sambol ingenjörs- och utvecklingsledarroller på Oracle, Sun Microsystems, BMC Software och JPMorgan Chase. På Lightrun ledde han initialt globala lösningsteknik innan han blev VP för kundlösningar, där han fokuserar på att hjälpa kunder att anta företagets Runtime Insights-teknologi och översätta dess funktioner till mätbara affärs- och utvecklingsvinster.

Lightrun är en AI-nativ plattform för teknisk tillförlitlighet som är utformad för att ge utvecklare och AI-agenter direkt insyn i hur mjukvara beter sig medan den körs. Dess teknologi kan dynamiskt fånga loggar, ögonblicksbilder, mått, spår, variabelvärden och exekveringskontext från liveapplikationer utan att kräva kodändringar eller omdistributioner. Företaget utökar alltmer denna runtime-intelligens till AI-assisterad programvaruutveckling via Lightrun MCP, som använder Model Context Protocol för att ge kodassistenter och agenter liveapplikationskontext i stället för att enbart förlita sig på statisk källkod. Detta möjliggör för AI-system att undersöka produktionsproblem, validera hypoteser mot faktiskt exekveringsbeteende och stödja rotorsaksanalys samtidigt som de införlivar företagskontroller som rollbaserad åtkomst och känslig dataredigering.

Din karriär har omfattat praktisk mjukvaruutveckling och arkitektur, molnkundteknik på Google, global lösningsteknik och nu kundlösningar på Lightrun. Hur har denna kombination av att bygga mjukvara och arbeta direkt med företagskunder format din förståelse för vad som skiljer en imponerande AI-agentdemonstration från ett system som kan lita på i produktion?

Det finns en stor skillnad mellan att visa vad en AI-agent kan göra och bevisa att den kan lita på i en företagsmiljö. Detta beror på att agenter bara är en del av ett produktionsklart system. Ramverket runt det är lika viktigt. Det måste tillämpa minst-privilegierad åtkomst, övervaka aktivitet, bevara en revisionslogg, förhindra oacceptabelt riskfyllda åtgärder och involvera en människa när det behövs.

Agenta system är inneboende annorlunda än traditionell mjukvara, eftersom utvecklare inte specificerar exakt hur systemet kommer att fungera. Vi ställer upp ett mål, tillhandahåller verktyg och vägledning, och modellen bestämmer hur den ska fortsätta. Den flexibiliteten är kraftfull, men den gör också systemets beteende svårare att förutsäga.

För företag, särskilt de i reglerade branscher, är produktionsflöden som vanligtvis fungerar eller tar en oförutsägbar tid att slutföra inte acceptabla. Produktionsmiljöer innehåller känslig data, källkod och immateriella rättigheter, så organisationer behöver kunna förhindra att agenter exponerar den informationen eller tar kreativa men oacceptabla vägar för att uppnå sina mål. Detta blir allt viktigare, eftersom varje vecka bringar ett nytt exempel på ett AI-system som, i sin strävan att nå ett mål, slutar vara sårbara för eller orsakar en säkerhetslucka.

De flesta ledare jag pratar med utvärderar fortfarande agenter på samma sätt som de skulle en ny anställd: på förmågor, omdöme och utdata. Den verkliga frågan är inte om agenten är tillräckligt smart. Det är om systemet runt den kan fånga och innesluta de ögonblick då den inte är det.

Många företag trodde initialt att att bygga en AI-agent i huvudsak var en fråga om att skriva en effektiv prompt. Vad missförstod organisationer om de tekniska, arkitektoniska och operativa kraven bakom produktionsklara agenter?

Jag tror att den största missförståelsen var en nästan naiv tro på AI:s kraft att lösa alla utmaningar, så länge den fick en välskriven prompt, relevant kontext och lämpliga verktyg. Team anslöt sin LLM till kod, dokumentation, biljetter och historisk telemetri, och förväntade sig sedan att den skulle resonera sig fram till rätt beslut.

Vad de inte byggde var en verifikationsmodell för varje steg i AI:s resonemang. En av AI:s stora styrkor är att den använder probabilistiskt resonemang, hittar och tar en av många möjliga vägar till målet. I komplexa, sammanflätade produktionsmiljöer introducerar den styrkan allvarliga risker: ett enda beslut kan utlösa nedströmsregressioner, tysta fel eller annat oväntat beteende som hotar den operativa motståndskraften i ett körsystem.

Det farliga är att agenten kan fortsätta att verka fungera korrekt medan den producerar felaktiga men trovärdiga svar, byggda på ofullständig data eller antaganden rotade i föråldrad information. Det är därför produktionsagenter behöver kontinuerlig utvärdering som fortsätter att köras efter lansering, explicit hantering av saknad data och verktygsfel, och liveverifiering av ett beslut innan det slutför en högimpaktåtgärd.

När man ser över den första vågen av internt utvecklade företagsagenter, vad är de vanligaste arkitekturmässiga misstagen du ser, och vilka problem kan korrigeras inkrementellt snarare än att kräva en fullständig ombyggnad?

Det centrala problemet jag ständigt återkommer till är validering. Agenter kan bli en svart låda: de samlar information från en mängd olika källor och fattar sedan beslut som ser rimliga ut i teorin men kanske inte är lämpliga för verkligheten i en komplex produktionsmiljö.

Det pekar på en mer grundläggande förändring, och det är något vi diskuterar konstant på Lightrun när vi hjälper kunder att bygga agenter för sina tekniska organisationer. Team behöver ombygga den agenterade flödesstrukturen och sätta grindar på agentens åtgärder, för att säkerställa att dess användning av verktyg är föremål för tillsyn, granskning och utvärdering. Att ge agenten en stark återkopplingsloop – inklusive live runtime-övervakning – fokuserar dess kontext på vad som faktiskt händer just nu. Det är det som låter agenten validera sina egna designbeslut, rotorsaksanalys och felmitigeringsrekommendationer mot produktionsverkligheten i stället för mot antaganden baserade på statisk analys av kod eller gammal telemetri.

En dramatisk ombyggnad är inte den enda möjligheten. Vad som kan göras inkrementellt, och det är inte banbrytande men det är avgörande, är att investera i de färdigheter som styr agentens beteende. Välkonstruerade och utvärderade färdigheter knuffar agenten i riktning mot ett deterministiskt arbetsflöde. Team behöver inte omkonstruera hela systemet för att få den fördelen. De behöver behandla färdighetsdesign med samma rigor de skulle ge vilken annan produktion logik som helst.

Varför presterar vissa agenter bra under kontrollerade tester men börjar producera inkonsekventa, ofullständiga eller vilseledande resultat när de utsätts för riktiga användare, förändrade data, externa verktyg och komplexa produktionsmiljöer?

Kontrollerade tester tar bort de flesta av de variationer som kommer att definiera produktionsverkligheten som AI-systemet måste hantera. Datat är kuraterat, verktygsbeteende är förutsägbart, behörigheter är kända, och vi täcker en väg vi förutsett. När du släpper en agent för att interagera med riktiga användare och deras effekter i live-system, är du inte jämförande lika med lika.

Användare introducerar tvetydiga förfrågningar och kör samtidiga åtgärder, systemtillståndet är i ständig flux, agenten måste ofta arbeta från ofullständig data, och externa verktyg bringar sin egen latens och felmoder på toppen av det. Eftersom modellen är probabilistisk, skapar varje ny variabel en annan plats där arbetsflödet kan avvika eller förvärra ett tidigare misstag.

Det farliga är att agenten kan fortsätta att verka fungera korrekt medan den producerar felaktiga men trovärdiga svar, byggda på ofullständig data eller antaganden rotade i föråldrad information. Det är därför produktionsagenter behöver kontinuerlig utvärdering som fortsätter att köras efter lansering, explicit hantering av saknad data och verktygsfel, och liveverifiering av ett beslut innan det slutför en högimpaktåtgärd.

Lightrun lägger stor vikt vid att ge AI-systemer tillgång till runtime-kontext. Vilken information tillhandahåller runtime-kontext som konventionella loggar, mått och spår kanske missar, och varför är denna information särskilt viktig för att diagnostisera agentfel?

Konventionell övervakning visar de yttre symtomen på systembeteende, ofta aggregerad, sampad eller filtrerad genom instrumentpaneler och larm som utlöses av tröskelvärden. De är vanligtvis beroende av beslut fattade av utvecklare när koden skrevs: vad är av intresse för framtiden? Vad är värt att logga eller mäta? Runtime-kontext kopplar loss synlighet från detta behov av att veta i förväg vad som kan vara av intresse, och den tillhandahåller granulär data som visar vad som händer under huven och hur vi kom dit.

Det verkliga gapet är statisk kontra dynamisk data. Konventionella loggar, mått och spår är statiska och producerar en historisk redogörelse för vad som hände. Lightruns runtime-kontext är dynamisk. Den ger en agent möjlighet att placera ny instrumentering i körsystem, på begäran, och observera exakt variabelvärden, funktionsargument, objekttillstånd, anropsstack eller grenvillkor när de inträffar.

Denna distinktion är särskilt viktig för att diagnostisera fel i agentgenererad kod, eftersom dessa ofta är tysta. En agent kan välja fel verktyg, passa fel argument eller agera på en föråldrad antagande, och fortfarande slutföra sin uppgift utan att utlösa något fel. Ett sådant fel kommer inte att visas i statisk telemetri, eftersom ingen visste i förväg att instrumentera för det. Ovänligt beteende kräver en dynamisk undersökning direkt på det körsystemet, med ny instrumentering exakt där agentens modell av världen avvek från verkligheten, snarare än att förlita sig på vad som redan spelades in.

Det är vad som gör dynamisk runtime-kontext den naturliga verifikationsskiktet för AI-genererade beslut i teknisk utveckling.

Hur kan Model Context Protocol (MCP) och liknande integreringslager tillåta kodagenter att lära sig från riktigt exekveringsbeteende utan att ge dem överdriven eller osäker åtkomst till produktionsystem?

MCP och andra kontrollerade åtkomst till externa verktyg (t.ex. CLI-omslag) låter en agent anropa en specifik, omfångsbestämd funktion i stället för att få allmän åtkomst till ett system och lita på att den kommer att bete sig. En agent ansluten via en MCP-server för runtime-kontext kan begära skrivskyddad bevis, ett variabelvärde, en anropsväg, om ett tröskelvärde överskrids, utan att röra skrivåtkomst, utan möjlighet att omfördela något och utan att behöva stående autentiseringsuppgifter till den underliggande miljön.

När man omkonstruerar en första generationens agent, hur bör företag närma sig verktygsbehörigheter, minne, dataåterställning, utvärdering, mänsklig tillsyn och återställningsförfaranden som delar av en sammanhängande arkitektur snarare än separata funktioner?

Du kan inte skruva på dessa delar oberoende av varandra, eftersom var och en förändrar de andra. De bästa platserna att börja är ramverket, det som kontrollerar agentloopen, och den övergripande arbetsflödeskoordinering som binder samman flera agenter och andra aktörer. För en rotorsaksanalysarbetsflöde, till exempel, bör team bestämma vilken bevisning som krävs, vilka system agenten får inspektera, om den kan publicera en slutsats eller bara utkast, när en människa måste godkänna nästa steg och vad som händer om runtime-bevisning inte är tillgänglig.

När det kontraktet är klart tillhandahåller ramen och ramverket de mekanismer med vilka man kan tillämpa dessa riktlinjer. MCP-grindar kan utnyttjas för att begränsa agentens åtkomst till specifika funktioner som är relevanta för dess syfte. Verktyg kan beviljas med minst privilegier. Minnet kan övervakas, med känslig data redigerad deterministiskt. Återställning kan konstrueras runt den bevisning som arbetsflödet behöver.

Utvärdering, tillsyn och återställning stänger sedan loopen. Systemet bör mäta om slutsatser är korrekta och stöds, involvera en människa när risk eller osäkerhet korsar en definierad tröskel och stoppa eller återgå till en skrivskyddad rekommendation när det inte kan samla tillräckligt med bevis. En gemensam revisionspost bör koppla samman utlösare, behörigheter, bevis, verktygsanrop, godkännanden, åtgärd och resultat. Det är vad som gör dessa komponenter en produktionsarkitektur snarare än sex separata funktioner.

Vilka skyddsåtgärder bör omge agenter som kan inspektera liveapplikationer eller delta i site reliability engineering-arbetsflöden, särskilt i reglerade miljöer där åtkomstkontroll, sekretess, granskbarhet och operativ stabilitet är kritiska?

Detta var en av de centrala designfrågorna när vi byggde Lightrun AI SRE. En AI SRE-operatör arbetar nära några av de känsligaste systemen i en organisation, så vi utformade den som en privilegerad operativ aktör, inte en chattassistent. Ett viktigt beslut var att separera inspektionplanet från åtgärdsplanet. AI SRE samlar bevis genom skrivskyddda integreringar och Lightruns sandlåda runtime-instrumentering, med åtkomst begränsad av identitet, hyresgäst, tjänst och miljö. Den kan inspektera live-exekvering och generera saknad bevis, men runtime-inspektionslagret kan inte modifiera applikationstillstånd.

I en reglerad miljö måste den gränsen stödjas av RBAC, SSO, hyresgästisolering, PII-redigering, kvarhållningskontroller och en revisionslogg som visar vilka verktyg och bevis som stödde varje slutsats. Vi behöver också operativa begränsningar runt hur mycket data som kan samlas in, hur ofta runtime kan frågas och vilka åtgärder som kräver godkännande. Om bevis saknas eller en slutsats inte kan verifieras, bör AI SRE säga det och lämna beslutet till en människa snarare än agera som om den vet mer än den gör. Målet är kontrollerad autonomi: användbar nog att accelerera en utredning, men tillräckligt begränsad för att förbli säker för det live-systemet.

När företag går bortom experimentella agenter, vilka mått bör bestämma om en agent verkligen är produktionsklar, och hur förväntar du dig att relationen mellan AI-agenter och mänskliga ingenjörer kommer att utvecklas under de närmaste åren?

Jag skulle bedöma produktionsklarhet baserat på hur ofta en AI-agents åtgärder producerar önskade resultat, dess slutsatser står sig mot vad som verkligen var sant i produktion, oskyddade slutsatser fångas innan åtgärd och om den misslyckas synligt och säkert när bevisen inte finns. För ingenjörsagenter är verifierad utfallsnoggrannhet, bevisningstäckning, tid till att bekräfta rotorsak, framgångsrik återställningsfrekvens och post-åtgärdsresultat de centrala måtten vi bör fokusera på.

Under de närmaste åren förväntar jag mig att agenter kommer att ta på sig mer av bevisinsamling och första pass-utredning, samt övervakning av agentarbetsflöden och kontinuerligt lärande från erfarenhet och feedback, medan ingenjörer ställer policy, löser tvetydighet, godkänner högriskåtgärder och styr de självförbättrande agent-systemen. Förtroende kommer att expandera arbetsflöde för arbetsflöde. Agenter som kan spåra sina slutsatser tillbaka till livebevis och tydligt avslöja vad de inte kunde verifiera kommer att tjäna större autonomi. De som inte kan kommer att förbli begränsade till smala, lågriskåtgärder, oavsett hur flytande de låter.

Tack för den utmärkta intervjun, läsare som vill lära sig mer bör besöka Lightrun.