Moshe Sambol, VP van Klantoplossingen bij Lightrun – Interviewreeks

Moshe Sambol, VP van Klantoplossingen bij Lightrun – heeft meer dan twee decennia ervaring in software-ontwikkeling, -architectuur, cloud-infrastructuur en klantgerichte technische leiderschap. Voordat hij in 2022 bij Lightrun kwam, werkte hij bijna een decennium bij Google, waar hij verschillende leiderschapsfuncties bekleedde, waaronder Cloud Customer Engineering Manager, waar hij organisaties hielp om Google Cloud-technologieën te adopteren en op te schalen. Eerder in zijn carrière had Sambol technische leiderschapsfuncties bij Oracle, Sun Microsystems, BMC Software en JPMorgan Chase. Bij Lightrun leidde hij aanvankelijk de wereldwijde Solution Engineering voordat hij VP van Klantoplossingen werd, waar hij zich richt op het helpen van klanten om de Runtime Insights-technologie van het bedrijf te adopteren en de mogelijkheden ervan om te zetten in meetbare bedrijfs- en ontwikkelaarsproductiviteitswinsten.

Lightrun is een AI-natieve engineering reliability-platform ontworpen om ontwikkelaars en AI-agents directe zichtbaarheid te geven in hoe software zich gedraagt terwijl deze wordt uitgevoerd. De technologie kan dynamisch logs, snapshots, metrics, traces, variabele waarden en uitvoeringscontext van live-toepassingen vastleggen zonder dat hiervoor code-wijzigingen of opnieuw implementeren nodig zijn. Het bedrijf breidt deze runtime-intelligentie steeds verder uit naar AI-ondersteunde software-ontwikkeling via Lightrun MCP, dat het Model Context Protocol gebruikt om coding-assistenten en agente-tools te voorzien van live-toepassingscontext in plaats van alleen te vertrouwen op statische broncode. Hiermee kunnen AI-systemen productieproblemen onderzoeken, hypothesen valideren tegen de werkelijke uitvoeringsgedrag en ondersteuning bieden bij root-cause-analyse, waarbij ondernemingscontroles zoals rolgebaseerde toegang en gevoelige gegevensredactie worden geïntegreerd.

Uw carrière heeft zowel hands-on software-ontwikkeling en -architectuur, cloud-klanttechniek bij Google, wereldwijde oplossingsengineering en nu klantoplossingen bij Lightrun omvat. Hoe heeft deze combinatie van software-opbouw en directe interactie met ondernemingsklanten uw begrip gevormd van wat een indrukwekkende AI-agentdemonstratie onderscheidt van een systeem dat in productie kan worden vertrouwd?

Er is een groot verschil tussen laten zien wat een AI-agent kan doen en bewijzen dat het in een ondernemingsomgeving kan worden vertrouwd. Dit komt doordat agenten slechts een onderdeel zijn van een productieklare systeem. Het kader eromheen is net zo belangrijk. Het moet least-privilege-toegang afdwingen, activiteit controleren, een audit-trail bewaren, onaanvaardbaar risicovolle acties voorkomen en wanneer nodig een mens inschakelen.

Agente-systemen zijn inherent anders dan traditionele software, omdat ontwikkelaars niet exact voorschrijven hoe het systeem zal werken. We stellen een doel, bieden tools en richtlijnen, en het model bepaalt hoe het verdergaat. Die flexibiliteit is krachtig, maar maakt het systeemgedrag ook moeilijker te voorspellen.

Voor ondernemingen, vooral in gereguleerde branches, zijn productiewerkstromen die meestal werken of een onvoorspelbare hoeveelheid tijd nodig hebben om te voltooien, geen optie. Productieomgevingen bevatten gevoelige gegevens, broncode en intellectueel eigendom, dus organisaties moeten in staat zijn om te voorkomen dat agenten deze informatie blootstellen of creatieve maar onaanvaardbare routes nemen om hun doelen te bereiken. Dit wordt steeds belangrijker, aangezien elke week een nieuw voorbeeld van een AI-systeem brengt dat, in zijn streven om een doel te bereiken, kwetsbaar wordt voor of een beveiligingslek veroorzaakt.

De meeste leiders die ik spreek, evalueren agenten nog steeds op de manier waarop ze een nieuwe werknemer zouden beoordelen: op capaciteiten, oordeel en output. De echte vraag is niet of de agent slim genoeg is. Het is of het systeem eromheen in staat is om de momenten te vangen en te bevatten waarin het niet zo is.

Veel ondernemingen geloofden aanvankelijk dat het opbouwen van een AI-agent voornamelijk een kwestie was van het schrijven van een effectieve prompt. Wat hebben organisaties verkeerd begrepen over de technische, architecturale en operationele vereisten achter productieklare agenten?

Ik denk dat de grootste misvatting een bijna naïeve geloof was in de kracht van AI om elke uitdaging op te lossen, zodra het een goed geschreven prompt, relevante context en geschikte tools had gekregen. Teams hebben hun LLM verbonden met code, documentatie, tickets en historische telemetrie, en verwachtten vervolgens dat het op een accurate manier tot de juiste beslissing zou komen.

Wat ze niet hebben opgebouwd, was een verificatiemodel voor elke stap in de redenering van de AI. Een van de grote sterke punten van AI is dat het probabilistische redenering gebruikt, waarbij het een van de vele mogelijke routes naar een bestemming vindt en neemt. In complexe, met elkaar verbonden productieomgevingen introduceert deze kracht echter een serieus risico: een enkele beslissing kan downstream-regressies, stille fouten of andere onverwachte gedragingen triggeren die de operationele veerkracht van een actief systeem bedreigen.

Dit is waar deterministische sturing essentieel wordt. De redenering van de agent kan probabilistisch blijven, maar de checkpoints rond zijn acties kunnen dat niet. Voor een agent die deelneemt aan een engineeringsworkflow, vereist dit een verificatiestap die zijn veronderstelde volgende actie controleert tegen de productierealiteit, een deterministische poort in plaats van een andere probabilistische gok. Het moet zien wat de gevolgen van die beslissing zullen zijn en deze alleen goedkeuren als het heeft vastgesteld dat de actie veilig is.

Als we naar de eerste golf van intern ontwikkelde ondernemingsagenten kijken, wat zijn de meest voorkomende architectonische fouten die u ziet, en welke problemen kunnen incrementeel worden gecorrigeerd in plaats van een complete herbouw te vereisen?

De kernzorg waar ik steeds op terugkom, is validatie. Agenten kunnen een black box worden: ze verzamelen informatie vanuit een reeks bronnen en nemen vervolgens beslissingen die in theorie redelijk lijken, maar mogelijk niet geschikt zijn voor de realiteit van een complexe productieomgeving.

Dat wijst op een fundamentele verschuiving, en dat is iets waarover we constant spreken bij Lightrun als we klanten helpen om agente-automatiseringen voor hun engineeringsorganisaties op te bouwen. Teams moeten de agente-stroom zelf opnieuw opbouwen en poorten plaatsen op de acties van de agent, om ervoor te zorgen dat het gebruik van tools onder toezicht, audit en review staat. Het bieden van de agent zelf van een sterke feedbacklus – inclusief live runtime-observatie – richt zijn context op wat er echt gebeurt op dit moment. Die toegang is wat de agent in staat stelt om zijn eigen ontwerpbeslissingen, root-cause-analyse en foutmitigeringsaanbevelingen te valideren tegen productierealiteit in plaats van tegen aannamen op basis van statische code-analyse of oude telemetrie.

Een dramatische herbouw is niet de enige optie. Wat incrementeel kan worden gedaan, en dat is niet revolutionair maar essentieel, is investeren in de vaardigheden die het gedrag van de agent leiden. Zorgvuldig ontworpen en geëvalueerde vaardigheden duwen de agent in de richting van een deterministische workflow. Teams hoeven het hele systeem niet opnieuw te ontwerpen om dat voordeel te behalen. Ze moeten de ontwerpvaardigheid van de agent behandelen met dezelfde rigor die ze zouden geven aan elke andere productielogica.

Waarom presteren sommige agenten goed tijdens gecontroleerde tests, maar beginnen ze inconsistent, onvolledig of misleidende resultaten te produceren wanneer ze worden blootgesteld aan echte gebruikers, veranderende gegevens, externe tools en complexe productieomgevingen?

Gecontroleerde tests verwijderen de meeste variabiliteit die de productierealiteit zal definiëren waarmee de AI te maken krijgt. De gegevens zijn gecureerd, toolgedrag is voorspelbaar, toegang is bekend en we dekken een pad dat we hebben voorzien. Als u een agent vrijgeeft om te interageren met echte gebruikers en hun effecten in live-systemen, vergelijkt u niet met gelijken.

Gebruikers introduceren dubbelzinnige verzoeken en lopen gelijktijdige acties uit, de systeemstatus is in constante flux, de agent moet vaak werken met gedeeltelijke gegevens en externe tools brengen hun eigen latentie en foutmodi met zich mee. Omdat het model probabilistisch is, creëert elke nieuwe variabele een andere plek waar de workflow kan divergeren of een eerder gemaakte fout kan verergeren.

Het gevaarlijke deel is dat de agent kan blijven lijken alsof hij correct werkt, terwijl hij onjuiste maar plausibele antwoorden produceert, gebaseerd op gedeeltelijke gegevens of aannamen die zijn geworteld in verouderde informatie. Daarom hebben productieagenten continue evaluatie nodig die blijft lopen na de lancering, expliciete afhandeling van ontbrekende gegevens en toolfouten, en live-verificatie van een beslissing voordat deze een hoge-impactactie voltooit.

Lightrun legt veel nadruk op het geven van AI-systemen toegang tot runtime-context. Wat voor soort informatie biedt runtime-context die conventionele logs, metrics en traces misschien missen, en waarom is deze informatie bijzonder belangrijk voor het diagnosticeren van agent-fouten?

Conventionele observatie toont de externe symptomen van systeemgedrag, vaak geaggregeerd, bemonsterd of gefilterd via dashboards en alerts die worden geactiveerd op drempelwaarden. Deze zijn meestal afhankelijk van beslissingen die door ontwikkelaars zijn genomen op het moment dat de code werd geschreven: welke informatie zal in de toekomst van belang zijn? Wat is het waard om te loggen of te meten? Runtime-context ontkoppelt zichtbaarheid van deze noodzaak om van tevoren te weten wat mogelijk van belang kan zijn, en biedt granulaire gegevens die laten zien wat er onder de motorkap gebeurt en hoe we daar zijn gekomen.

Het echte gat is statische versus dynamische gegevens. Conventionele logs, metrics en traces zijn statisch en produceren een historisch verslag van wat er is gebeurd. Lightrun’s runtime-context is dynamisch. Het geeft een agent de mogelijkheid om nieuwe instrumentatie in uitgevoerde code te plaatsen, op aanvraag, en de exacte variabele waarden, functieargumenten, objectstatus, call stack of branch-voorwaarden te observeren zoals ze optreden.

Dit onderscheid is bijzonder belangrijk voor het diagnosticeren van fouten in door agent gegenereerde code, omdat deze vaak stil zijn. Een agent kan de verkeerde tool kiezen, het verkeerde argument doorgeven of handelen op basis van een verouderde aanname, en nog steeds zijn taak voltooien zonder een fout te triggeren. Een dergelijke fout zal niet in statische telemetrie verschijnen, omdat niemand van tevoren wist om welke instrumentatie te vragen. Onverwacht gedrag vereist een dynamische onderzoek rechtstreeks op het actieve systeem, waarbij nieuwe instrumentatie exact op de plek wordt geplaatst waar het model van de wereld van de agent afweek van de realiteit, in plaats van te vertrouwen op wat al werd opgenomen.

Dat is wat dynamische runtime-context de natuurlijke verificatielaag maakt voor AI-gegenereerde beslissingen in engineeringsprocessen.

Hoe kunnen het Model Context Protocol (MCP) en soortgelijke integratielagen coding-agenten in staat stellen om te leren van het werkelijke uitvoeringsgedrag zonder hen excessieve of onveilige toegang tot productiesystemen te geven?

MCP en andere gecontroleerde toegang tot externe tools (bijv. CLI-wrappers) laten een agent toe om een specifieke, afgebakende capaciteit aan te roepen in plaats van algemene toegang tot een systeem en vertrouwen op goed gedrag. Een agent die via een MCP-server is verbonden voor runtime-context kan read-only bewijs, een variabelewaarde, een call-pad, of of een drempelwaarde is overschreden, zonder schrijftoegang, zonder de mogelijkheid om opnieuw te implementeren, en zonder dat er permanente referenties naar de onderliggende omgeving nodig zijn.

Wanneer een eerste-generatie-agent opnieuw wordt ontworpen, hoe moeten ondernemingen toolmachtigingen, geheugen, gegevensopname, evaluatie, menselijke toezicht en terugvalprocedures benaderen als onderdelen van één samenhangende architectuur in plaats van afzonderlijke functies?

U kunt deze onderdelen niet onafhankelijk op elkaar aansluiten, omdat elk ervan de anderen verandert. De beste plekken om te beginnen zijn het kader, de harnas die de agentlus controleert, en de algehele workflow-orchestratie die meerdere agenten en andere actoren samenbrengt. Voor een root-cause-analyse-workflow, bijvoorbeeld, moeten teams beslissen welk bewijs vereist is, welke systemen de agent mag inspecteren, of het een conclusie kan publiceren of alleen een concept, wanneer een mens de volgende stap moet goedkeuren, en wat er gebeurt als runtime-bewijs niet beschikbaar is.

Zodra die overeenkomst duidelijk is, bieden de harnas en het kader de mechanismen om die richtlijnen af te dwingen. MCP-poorten kunnen worden gebruikt om de toegang van de agent tot specifieke capaciteiten te beperken die relevant zijn voor zijn doel. Tools kunnen worden verleend met least privilege. Geheugen kan worden gesuperviseerd, met gevoelige gegevens die deterministisch zijn gereduceerd. Opname kan worden ontworpen rond het bewijs dat de workflow nodig heeft.

Evaluatie, toezicht en terugval sluiten dan de cirkel. Het systeem moet meten of conclusies correct en ondersteund zijn, een mens inschakelen wanneer risico of onzekerheid een bepaalde drempel overschrijdt, en stoppen of terugvallen naar een read-only aanbeveling wanneer het niet genoeg bewijs kan verzamelen. Een gedeelde audit-record moet de trigger, machtigingen, bewijs, toolaanroepen, goedkeuringen, actie en resultaat verbinden. Dat is wat deze componenten één productiearchitectuur maakt in plaats van zes afzonderlijke functies.

Welke waarborgen moeten om agenten heen worden geplaatst die live-toepassingen kunnen inspecteren of deelnemen aan site reliability engineering-workflows, vooral in gereguleerde omgevingen waar toegangscontroles, privacy, auditeerbaarheid en operationele stabiliteit kritiek zijn?

Dit was een van de centrale ontwerpvragen toen we Lightrun AI SRE bouwden. Een AI SRE werkt dicht bij enkele van de meest gevoelige systemen in een organisatie, dus we ontwierpen het als een bevoorrechte operationele actor, niet als een chat-assistent. Een belangrijke beslissing was om de inspectie-laag te scheiden van de actie-laag. De AI SRE verzamelt bewijs via read-only-integraties en Lightrun’s sandboxed runtime-instrumentatie, met toegang beperkt door identiteit, tenant, service en omgeving. Het kan live-uitvoering inspecteren en ontbrekend bewijs genereren, maar de runtime-inspectielaag kan de toepassingsstatus niet wijzigen.

In een gereguleerde omgeving moet die grens worden ondersteund door RBAC, SSO, tenant-isolatie, PII-redactie, retentiecontroles en een audit-trail die aangeeft welke tools en bewijs elke conclusie ondersteunden. We hebben ook operationele limieten nodig rond hoeveel gegevens kunnen worden verzameld, hoe vaak de runtime kan worden bevraagd en welke acties goedkeuring vereisen. Als bewijs ontbreekt of een conclusie niet kan worden geverifieerd, moet de AI SRE zeggen dat het niet weet en de beslissing overlaten aan een mens in plaats van te handelen alsof het meer weet dan het daadwerkelijk doet. Het doel is gecontroleerde autonomie: nuttig genoeg om een onderzoek te versnellen, maar beperkt genoeg om veilig te blijven voor het live-systeem.

Terwijl ondernemingen de experimentele agenten ontstijgen, welke metingen moeten bepalen of een agent echt productieklare is, en hoe verwacht u dat de relatie tussen AI-agenten en menselijke ingenieurs zich in de komende jaren zal ontwikkelen?

Ik zou productieklare beoordelen op basis van hoe vaak de acties van een AI-agent de gewenste resultaten produceren, of zijn conclusies standhouden tegen wat er werkelijk in productie was, of onondersteunde conclusies worden gevangen voordat er actie wordt ondernomen, en of het zichtbaar en veilig faalt wanneer het bewijs er niet is. Voor engineeringsagenten zijn verifieerde uitkomstnauwkeurigheid, bewijsdekking, tijd tot bevestiging van root-cause, succesvolle terugvalpercentage en post-actieresultaten de kernmetrieken waarop we ons moeten concentreren.

In de komende jaren verwacht ik dat agenten meer van de bewijsverzameling en eerste-pas-onderzoek zullen overnemen, evenals toezicht op agente-workflows en voortdurend leren van ervaring en feedback, terwijl ingenieurs beleid vaststellen, onduidelijkheden oplossen, hoge-risicoacties goedkeuren en zelfverbeterende agente-systemen sturen. Vertrouwen zal workflow voor workflow toenemen. Agenten die hun conclusies kunnen traceren naar live-bewijs en duidelijk aangeven wat ze niet konden verifiëren, zullen grotere autonomie verdienen. Diegenen die dat niet kunnen, zullen beperkt blijven tot smalle, lage-inzettaken, ongeacht hoe vloeiend ze klinken.

Bedankt voor het geweldige interview, lezers die meer willen leren, kunnen Lightrun bezoeken.