Latest / The MonkCast / Why the Gateway Approach to Agents Sucks (and What to Do Instead) with Marek Poliks
Transcript
- speaker-0: Hey, it's James Governor. We're here for another monkcast. ⁓ I'm really pleased today to have Marek Pollux, ⁓ head of AI at LaunchDarkly. And we got some content that's maybe well can't actually why did I call it content? It's not content. Content is close to slot. What it is is a conversation with value. Yes, not content. It's not content, it's a conversation. ⁓ and it's it's possibly a little bit spicy today. speaker-1: Okay. Yeah. speaker-0: ⁓ so I I think that if we if we had a title and and you know sometimes the title comes later, but it's it's something something like having having done a little bit of planning with Marek, it's how the gateway approach to agent management sucks and why observability and why observability is not going to save you. So there you go. Now, a lot of you know LaunchDarkly from the feature management space. Maybe you don't even know that they're in this ⁓ agent management space. ⁓ certainly what I've seen, ⁓ lots of vendors, as I say, coming in from kind of ⁓ you've got API gateways, now being AI gateways, now being agent gateways, you've got messaging vendors in there. All the security vendors are all like, yes, we are gonna secure the agents, we can help you manage that. ⁓ so I was kind of interested when I was talking to Marik ⁓ about this. We'll we'll get to that ⁓ during the conversation. But I guess from my perspective, as I say, we ⁓ very much know LaunchDarkly as a feature management company. You invented the category and and then I I guess what's a nice feature management company like you doing nothing round in the AI Asian space variety? And welcome to the show, by the way. speaker-1: Thank you. Thank you so much for having me. I wore my red shirt today so that I could be, you know, extra spicy, I guess, in terms of the opinion setting. Though it's matching the color of my nose from a lot of nose blowing. I have a little bit of a cold, so apologies if I sound bad. ⁓ yeah, so like what is what is what business does Launch Darkly have in the AI space? I'll say I joined Launch Sharkly because I came to the same conclusion that a lot of folks inside of Launch Sharkly and product and also a lot of Punch dark these customers were coming to, which is the idea that like feature flags are actually really, really useful for agents. So as someone who was building a lot of agents, you know, a year, year and a half ago, certainly earlier than that as well, I found it to be really useful to take the agent outside of the application space itself. You have the application space, you have this world that you've defined where you're really looking to do specific things. The agent that lives within that world, or in many cases, the 16 agents that are living within that application space or 80 agents that are living with that application space. Like, if I think of that application space as one topology, as like one neutral world, it's really difficult to govern those agents. It's really difficult to shut those agents off if they're doing something problematic. It's really difficult to root cause those agents if they're doing something problematic. And I think most critically, it's really difficult to like improve on those agents because those agents are kind of like, Hard coded entities that are living in code. So prior to me joining at Lod joining Lodge Starkly, I was starting to put agents behind feature flags so that I could iterate on them. I could like swap in an agent, swap out an agent. That was definitely the most important thing early on. But then I also learned that like, well, the way of improving an agent, if I start with an agent, let's say I built an agent harness, I'm like, all right, this agent harness is is good, but I'm gonna make it better. If I improve that agent harness by just Iterating on like a single surface, I'm doing something really weird in in terms of like a non-deterministic system. Because every time I'm testing that non-deterministic system, I'm basically rolling the dice again. But if I'm just testing one version or variation of an agent harness and then seeing if it gets better, seeing if gets worse, I'm kind of playing an awful stoca stochastic game with myself. And the better thing to do is actually work with a large kind of communion of variations of agent harnesses, test them out at some level of scale. And then look at the probability distribution of those performances. And that is also something that's really useful. Well, I can I can keep going on why I think feature flags are great for agents, but like taking them out of application space and putting them somewhere I can see and think about them. And then like treating them as like these variational kinds of things that I can test at some level of scale were two really kind of like node-brainer conclusions for me that led me to join Launch Sharkly and start building out what we call agent control, which is principally this. super complex and I think really robust way of ultimately delivering agents behind feature flags. speaker-0: So I I think one of the points you're making there is that we sort of live in an age now of of of experimentation. I mean w in the world kind of everything is experimentation, something we've spoken about for the longest time. You know, ⁓ we would have feature flags, but how many feature flags? And I guess now there are so many flowers blooming ⁓ that you know we need to be able to I guess nip those nip some nip garden. speaker-1: Gardening, right? speaker-0: N knit some of them in the bud and as as you say, it's it's much more probabilistic. So is it is it partly that that just the the degree of experimentation ⁓ aligns itself with what we'd been doing with feature flags already? speaker-1: 100%. I think that's something that we keep kind of joking about internally, is like maybe like this is actually the best usage of feature. Maybe like this is what feature flags were designed to do all along. And we've just kind been anticipating this moment. Because like we were we're moving to a place where, you know, first there was a lot of experimentation and kind of pre-production context. Then the feature flag came around and allowed you to do some experimentation in production context. Then agentic AI and you know AI in general kind of had its big surge. And now everyone is experimenting in production, no matter what they say, like absolutely no matter what they say, they're doing it all the time, all the time in production. Because no matter what, you're rolling dice and customers are involved in those dice rolls. And so the question is like whether or not you're collecting information about those dice rolls or just casting dice all the time. And so we're yeah, for us, like it's very much a moment of taking advantage of the fact that no matter what you're experimenting now, everything is experimentation now. It's just a matter of actually ensuring that you're building a proper experiment that'll teach you something as opposed to just damping, I guess. Right. speaker-0: Right. And so on that note, I mean, i is this so we're all we are all now fully testing in production. That's that that ship has sailed. Is that is that the articulation? speaker-1: Yeah, I mean I I don't think that's a con controversial perspective at all. And and like to a certain extent, we always were, right? Like there's never been a place where we like to think of of compute as discrete state machines. We like to think of like moving through a series of gates and like everything being deterministic and determined from from the beginning to the end. But as soon as you put anything non-deterministic into a loop. Including a human, you know, the OG non-deterministic system, you get an aggregate non-deterministic system. That's ultimately what happens. ⁓ as soon as you allow for the concurrency of deterministic systems with our beautiful non-deterministic world, you get a non-deterministic space. And that necessarily incurs something like experimentation, right? In that you're you're you're testing alternatives, you're testing possibilities, you're opening up vulnerabilities in a lot of cases. That's always been the case. We've just kind of ratcheted that up like mega style with agents because now it's both sides of the loop that are highly non deterministic, no matter no matter how much we want them not to be. speaker-0: Yeah, I mean distributed systems, ⁓ by their nature, we may w it want and hope that they are deterministic, ⁓ but we certainly can't rely on that. ⁓ things break. ⁓ you know, I I think the ⁓ I always think of of of Mike Tyson, you know, everybody has a plan. Everybody has a plan until they get punched in the face. So, you know, people had pre prod, but prod is liable to punch you in the face. speaker-1: Yeah. speaker-0: I think everything everything has moved that way. So yeah, I I I don't think it's a controversial statement ⁓ in in twenty twenty six. So one thing ⁓ I I I think that's interesting is when Launch Darkly started to talk about runtime control. ⁓ I had issues with this. I'm like, what do you Launch Darkly does not do ⁓ runtime control. For me, runtime is it's about going down a level. you're working more at the the feature level. So how is that runtime control? And slightly annoyingly, as we see so often in this era of AI, we have to ⁓ reassess our priors. And and during this conversation, I I think that that conversing to me that that yeah, like at least in this new world, the way that you're using flags, I think I'm gonna say it's reasonable and look how unhappy I look saying it. speaker-1: Okay. speaker-0: I think it's reasonable to say that you're doing runtime control. So talk a bit about that transition for Launch Darkly, 'cause again I don't think that's something that people think of you for. speaker-1: You're you're 100% right. So I think like a lot of people, incl including some customers as well, think of us as like a kind of binary gate that's like outsourced from the application, right? You have something going on in the application space, you've identified that this feature, this component, you're gonna take that out of the app, you're gonna you're gonna move that to the LaunchDarkly ecosystem, and then you're probably just gonna turn it on or off based on certain conditions. Most classic possible example is like We're gonna put out a new feature, but we're just gonna put out that new feature to beta users, right? And if it if it's bad, we're gonna shut it off immediately. And that's like a very kind of classic launch darkly use case in that you've taken something out of code, you've moved it to another place where you can conditionally gate whether or not it's active based on customer segmentation. So whether or not a customer is part of a beta user segment. And then you can shut it off really easily by toggling it on and off ⁓ from from the outside of the application logic, which is great. So what that does is that does That decouples deployment from release. Now I'm just like straight up ⁓ spitting LaunchDarkly marketing speech. But I think it's actually pretty. speaker-0: I I I grew up on this stuff. I mean I'm I I I wrote a book about this stuff. I mean we'll get to progressive delivery in a minute, 'cause you know, I mean, I don't mind you like being spicy about everything else, but if you start coming after my baby, then this is gonna be so anyway, keep going, keep going. But yeah, no, that world definitely makes sense. That is the expectation. speaker-1: Hell yeah. So where does runtime control come in? So let me just articulate the decoupling of deployment from released. Yes. Deployment, of course, to the uninitiated means the moment that software is ultimately actualized. You've got your servers, you've got your clusters, everything is kind of rolling out into the world. And release is is being separated from that moment because you're actually turning on a feature or turning off a feature to the fact, right? After the software is already out there, you have the ability to release some new piece of software. Or unrelease some new piece of software based on live conditions. Now live starts to sneak in here just a little bit. This gets really, really exciting with agent control in a lot of ways, but also just kind of generally how Launch Berkeley has progressed over the past couple of years. But let's let's stick to agents because I'm an I'm an agent guy. So ⁓ think of it this way. Let's say you have ⁓ a new version of an agent that you wanna that you wanna roll out. Let's say you've you've got Agent A, you want to move to agent B. You've done some pre-production, offline emails, you've validated that agent B is good. So we're going to roll it out. The first kind of like primary primitive that Launch Directly lets you use is what we call a guarded progressive rollout. And what that ultimately means is I can gradually stage that release from A to B of an agent harness, again, separated from code. Just the harness, the prompts, hyperparameters, policies, tools, model, model provider stuff. So just that. Is g is on its own release track, independently from anything in the kind of application body. And you then have some like live signals that were an SDK driven. Now you can you can hear. I'm gonna start to ramp up like the the ⁓ the dissing. I guess I'm trying to think of like a safe way to say it on air, but like the ⁓ negative opinion I have towards like strictly gateway based ⁓ logics here. speaker-0: I think it's I think we're all friends here. I think if you w if you wanna stay shit talking, I think we can speaker-1: Hell yeah. Let's let's go for it. Let's speaker-0: We could just about get away with that. ⁓ speaker-1: Yeah. So ⁓ so we're we're inside an SDK. So we're inside the actual application space itself. So let's say ⁓ application initializes, it pulls a series of flags that are ⁓ available via LaunchDarkly. We serve fifty trillion or sixty trillion, I forget what number it is, but it's trillion. And I love being able to say trillion every day. Like lots and lots of flags every single day, lots of points of presence all over the globe. Those flags are retrieved. speaker-0: A Doctor Evil thing, right? speaker-1: Yeah, yeah, yeah, exactly. True. So ⁓ application visualizes, grabs the flags, and then inside the application space, this is where we get towards runtime control. We're gonna switch that trigger from A to B over some progressive scale. So I've identified, let's say, my enterprise customers. I'm gonna roll out from A to B of this version of an agent, gonna stage that progressively. So gradually it'll get switched on to those customers. And then here's the important bit. There's all kinds of metrics that are living in the application space that can be attended to. The application space has variables, and all those variables can be emitted to launch darkly or leveraged inside the app actual application space itself as ⁓ some kind of tool for what we call runtime control. So let's say you have an online evaluator that's sampling some percentage of exchanges for accuracy or bias or contextual grounding. Or let's say you're you're polling the model response API and you're getting a sense of how latent it is or whether or not you get any errors, et cetera. That information could be leveraged two ways. Let's say you a bad series of bad ⁓ online eval scores. You can automatically roll back that progressive release from A to B, blam, done, rolled back. You don't need to page an engineer, get page an engineer and let them know the rollback already happened. They're good to go. But let's step further into into runtime level control. This is where I get really excited about adaptive triggers, as we call them. So let's say you have ⁓ some level of latency that's been determined as unacceptable. Or let's say you have some level, let's let's say an online evaluator has deemed the response of a model to be unacceptable in the context of the actual application space itself. You can immediately escalate to another variation of that flag. Because we're serving different variations of flags, because we expect you to go through the betting process of flags that are going to be exposed to the production surface. Yeah. Let's say you got a bad review from an online evaluator. You can escalate to a more powerful model. Or let's say ⁓ you know Anthropic is is timing out again for you know some reason. Like you can escalate to a more more powerful ⁓ you know ⁓ either connection or to a different model provider or to a different model altogether. Right? And that's inside the actual runtime logic. That's literally at machine time. speaker-0: Okay. So that therefore run time. speaker-1: Therefore runtime. Yeah. speaker-0: So here's the thing. What what I do find interesting about this, I mentioned progressive delivery a minute ago. ⁓ yep. ⁓ me and and and ⁓ some friends wrote a book about that. ⁓ feat flags was definitely part of ⁓ the underpinnings of that. ⁓ you know, we we needed observability for the feedback loop, ⁓ really leaning into obviously automation has come a long way. ⁓ you know, if we think about CI C D, a lot of that stuff was you know. really pre-cloud. So cloud abundance wasn't part of that world. And we're certainly, whilst we're worried about token economics right now, there is a huge amount of abundance of infrastructure that we could take advantage of. How do you get alignment between the business? And you get live in a world where developers have autonomy, ⁓ and where engineers have autonomy so that we can do effective work. And we just felt there wasn't ⁓ an articulation for all of this stuff ⁓ that that that captured all of those things. ⁓ and so we talked about progressive delivery. Now, I think to your point, ⁓ we started writing the book pre chat GPT. And let me tell you, when The world is changing as fast as it is. You're kind of like Does this book have any relevance in this? So we were a little bit worried about that. But but I I think what we've seen is that that clearly it does. And I I I think that in terms of of of what you're talking about, ⁓ yeah. ⁓ AI and using models and agent-based development very much need some of these concepts around speaker-1: Yeah. Aggressive delivery has never been more important. Like I mean, like it literally I can't imagine it being more important than it is at this particular moment. speaker-0: Yeah, and I think what's interesting there is is having leaned so heavily into autonomy in the core concept, we weren't even thinking about autonomizations. We could and and you know, and then alignment, we were thinking about alignment, human alignment. And obviously now, once we start getting into loop based development, alignment that is really critical. So seeing these things, you're like, ⁓ okay, we're just describing this new world. ⁓ and I think what's really interesting is of course that transition you're making. ⁓ now, loop-based development. Like that's you is that is that is that something you're seeing i in your customers? ⁓ another word I think people are beginning to talk about like ⁓ you know, software factories. Like is that Well, I mean you're launched darkly, so they're definitely dark factories. speaker-1: Factories. Yeah. speaker-0: ⁓ w one of my questions is I'm certainly seeing and and look, I mean, it depends from org to org. You know, I could go in, I I was lucky enough, I was hanging out with ⁓ Richard Sauder, who ⁓ runs product at the Alaskan Williams racing team the other day, and he's definitely all about look, ⁓ we're gonna we're gonna build stuff. We're kind of not gonna mind if it breaks. What we are gonna have is really good pipelines and the ability to roll things back. But you can't he actually, I mean, I use that. the the we you know a few minutes ago we were talking about the sort of like flowers blooming and so on they talk about leaves rather than branches but things that you can snip off that is fine ⁓ now they're pretty advanced obviously sophisticated in the use of technology my question for you is a i are normal humans ⁓ your your sort of your normy customers doing this stuff or is it just sort of customers south of market that are like we're living in the future you know Token maxing, completely AI pilled. What are you seeing in in the sort of those the I guess those different modalities, different customers? Are real customers living in the future with you? speaker-1: Absolutely. I think like, as with all things, like it's less of a ⁓ let's say a movement between ⁓ I don't know, two separate sides or something like that, and an an absolute tear in the fabric of like how people do software. You're either all in or you're unbelievably behind. But the actual constituencies of those sides is crazy. Like it really doesn't make any sense to me. It's not split based on just like AI native versus non-AI native. It's not based on industry or even like degree of ⁓ you know, ⁓ subjectedness to regulation. It does seem to be pretty random and largely based on leadership principles and a little bit geography. I guess I'll be real with that. Geography is like pretty, pretty leading indicator there. ⁓ speaker-0: Are you are you saying that Europeans are slow at AI adoption? speaker-1: Well, ⁓ you know, there's this this this act that keeps getting pushed back every six months. Yeah, seems pretty threatening. And I'll tell you that, you know, my customers in Europe are justifiably very concerned about it. And at the same time, I guess just shamelessly I'll say I really I get really excited reading the ⁓ the EU AI Act because of the just degree of conformity to what it is that we offer at Watch Darkly, credibility, ⁓ humans in the loop, ⁓ you know, in important decision-making ⁓ apertures like Anyways, but yeah, I mean there's certainly a little bit of that, for sure. But I think the thing that I'm most interested in is in how healthcare and financial services are actually leading the way in a in a big, big way. This is where I see actual full scale software factories starting to be built. And moreover, this is also where I see, I guess, the most surprising moment of my career at Launch Directly thus far was with a highly regulated ⁓ you know, customer who is working with ⁓ let's say in an open cloud like system. Already like starting to build fully, fully autonomous architectures here. I was really surprised to hear that because like, you know, there's a lot of security vulnerabilities and and problems when it comes to like managing fully autonomous agents. But I think this just a sense that like this is happening and that like maybe the posture or the approach to things like security, data provenance, and ⁓ you know, ⁓ observability in general has a lot more to do with exactly what you're describing, this kind of like leaf-based approach where you're kind of continuously pushing out new things at the end. ⁓ those things can be rolled back easily and and and safely. And then kind of you can continue to progress forward. Like lots and lots of like kind of filigree that's growing on the outside of these teams. But at the same time, like the more substantial stuff, I haven't quite seen that yet, where you're seeing like, you know, full, like large scale ⁓ institutional architectures being completely automated. That I have not seen outside of, you know, ⁓ folks at the bleeding edge of the industry, but everyone gets the sense that it's inevitable. The number of conversations I have with people who say, you know, the workflow is dead is is a lot. Like, I mean, that's that's not an insubstantial amount. And then on the other side, you have people who are who have spent their past year and a half like getting their data story in order so that they are ultimately ready for the agentic turn. And I think they're learning very quickly that that last year and a half was ⁓ full of potential lessons that they haven't learned yet. So like that's a that's a that's a zone of like real real vulnerability, I think, for a lot of folks. speaker-0: Yeah, I think I think there's a lot of truth to that. But on the other hand, there there is a lot of prep to be done. I mean, you know, it's one thing like get the data foundation right, but from a context perspective, ⁓ really ensuring that you you want your agents to be working with the right context. And so, yeah, talking to an organization recently and and quite literally, you know, they they turned the agents on. ⁓ agents had gone out, ⁓ started getting access to things, getting pulling data in. And they were getting like 15 years of SharePoint data. And it turns out that the model was not Yeah, no, that was a serious yikes moment. So ⁓ you know, definitely ⁓ take a view of of cutoff points, you know, like ⁓ that stuff may not be relevant. I I remember I I thought it was funny when you know Amazon first started talking about trading models and and you know how it was going to improve life of the Amazon customer. And they're like, well, you know, yeah, we have speaker-1: Yeah. speaker-0: you know, all these all these years of of like Amazon documentation we can train the model on and everything. I'm like, you don't want to feed the model on old docs. That's like not something that's gonna give you a more effective context. ⁓ I mean, unless you're working in a very specific sort of modernization ⁓ con So I I do I I I I I I I think we're absolutely right and what we are seeing is ⁓ Yeah, waiting around is not a good idea. speaker-1: Yeah. You have to kind of do both. Like, I mean, totally context is critical and important. But if you're like you have to learn the lesson. Like that lesson that you described of that ⁓ you know, that person that you spoke to, that's a lesson you learn by actually leveraging an agentic system and seeing what kind of context it's actually pulling. It's critical to do both at the same time. speaker-0: Yeah, a hundred percent. So so we've got, as you say, sort of healthcare. ⁓ and there's, you know, there's the on the healthcare thing and regulated in industries and ⁓ yeah, I mean. ⁓ now, I'm not saying that the entirety of every organization is working in this way, but I'm not talking to many enterprises that don't have pockets of teams working i in this way. Exactly. And to your point about like product velocity, it's like, well Obviously disruption continues to be a thing. ⁓ but but you know, I I I don't know, I was thinking it you know, Charity Major says, you know, ⁓ five nines don't matter if the user isn't happy. Well, you know, you know, being fully industry compliant really doesn't matter if you go out of business. I mean, the the the I'm a big believer in in the value of of ⁓ regulations, consumer protections and so on. ⁓ But pretty clearly the the the the challenge ⁓ for organisations today is they've got they've they ⁓ as you say, that you are at such a disadvantage if you are not ⁓ moving fairly quickly to a new way of of of of of building software. So I think one thing that that is interesting just about this whole this willingness to Say to the machine, you do the work. We you know, commander's intent, right? This is what we want. Now you go and and and build the thing. ⁓ is it in a way and like so software factories, we're talking about that now. That's not new, is it? I mean that's speaker-1: It's an an AI is just an intensification of automation, right? Like, I mean, it's really just it's like a really nice kind of linear growth of automation applied to pectoral muscles, to machine controls, to ⁓ fully automated systems, now to the automation of automation itself, right? Like it's a really kind of nice curve there. Totally. I completely agreed. And also in the software space, it's also like absolutely not a new thing. If you think about what E even something like CI is like, I mean, that is like just the progenitor to this in in absolutely every respect. It's just the introduction of automation, the introduction of loops. I think kind of most importantly, an increased attentiveness to outcomes as opposed to inputs. Like right now, I think like we're starting to see this across the industry in general. It's like actually really alluding to what you were just saying around something like regulation. Like there is a a heightened attentiveness to outcomes. Like The actual customer outcome, the impact to the PL, like the impact to the business, like these are outcomes that are measurable and that are ultimately the kind of like, you know, the thing that one steers toward. And so there's less of a focus on less of a focus on inputs, more of a focus on outputs, but that's been a progressive component of software development for a very, very long time. speaker-0: Yeah, I'm absolutely right. I mean, you know, and I I do think that that's it's I mean, at any given time and we you know, we were talking about the transition to product as as the key way of you know sort of moving away from this focus on projects, ⁓ which is what we used to do. and again, a lot of that was, you know, input based, ⁓ to to very much 'cause products have by their nature are about outcomes. It's about value. speaker-1: Exactly. Yeah, yeah. speaker-0: ⁓ to the user. And on that note, let me let so we ⁓ I I wanna I wanna rewind a little bit because we we we said we were gonna ⁓ get spicy. I I wanna I wanna make sure that we get spicy. So ⁓ you explained you you you you explained why you you you you've got some views on why the gateway approach doesn't fully make sense. Is some of that to do with th the I guess the number of black boxes that we currently face? Like what's the what what's wrong with you know, securing endpoints? What's wrong with the endpoint approach? speaker-1: Also like there's nothing in principally in principle wrong with a gateway. And in fact, like I think every mature enterprise AI body should have a gateway. Like that that is like a speaker-0: Some some of your best friends. Some of your best friends in great ways. speaker-1: Some of my best friends are gateways. Absolutely. Absolutely. But I mean, they also introduce a lot of issues. ⁓ especially, so first, like especially if you're using a third party gateway, this means that you've introduced a serious ⁓ level of vulnerability, a serious level of dependency, a critical juncture point within your system. And this tends to be how like a lot of AI observability and a lot of like AI, you know, tooling, especially around governance, is ultimately instrumented, including things like guardrails, is like by introducing A third party dependency that adds latency, that adds you know single point of failure logic right at the API call itself to the model provider, which is already such a sensitive, like, you know, infrastructurally contingent like moment that's happening in applications right now. And I think like the the the the bigger question there is ⁓ so like if you if if you're sending information that's critical, that might go to let's say the enforcement of whether or not someone has access to a model. Where the enforcement of ⁓ whether or not a guardrail should be imposed. If you're sending that to a third party, that means you're sending your customer context. So everything the customer sent in in the form of like, you know, ⁓ a user prompt. You're sending the model's response, you're sending like all of this like business critical PII forward security rich information through a brittle third point of failure. And to me, that's like a serious problem. And so the majority of people that I see, especially like the advanced folks who are working in highly regulated, when they're building gateways, they're like confronting this impossible problem, which is like, how do I, how do I regulate what is going into and out of these models without looking into what's actually being said, without storing any of that information anywhere because I'm not allowed to? And that becomes a really, really, really complicated question. And so you can certainly build some instrumentation around that. But that instrumentation starts to look a lot less like a gateway and a lot more like runtime control from our perspective. But yeah, so just to kind of put a button on it, like gateways, like certainly centralized administration of AI is a good thing. If that centralized administration doesn't have an understanding of the constituent components of the harness of a given agent, it can be kind of toothless. Like most gateways are just like you have access to this model, you don't have access to this model, or like maybe if the model starts to suck, we'll we'll switch to this model. But like They're not a like highly active control point because the amount of context that's actually being handled there is actually not very rich. You don't have the full harness information often. You don't have necessarily like a tools registry or a skills registry or anything like that in place that you can actually supervise. You're just working with an application that is a client that is like somewhat invisible to you. You have an API call that you're handling, and that's kind of it. And so like you're limited in terms of what you can what you can control. You're limited in terms of your governance, and you're also sitting at like the most contingent, the most brittle, the most like security complex point of the entire architecture. And so that for us is like where it's kind of cooler to be inside the application, where we can do things like provide guardrails and even online evals and and other kinds of metrics from inside the application without necessarily revealing any context back to LogSharkly at all. Because we're serving harnesses that go to a place that can be enforced in application logic to do certain things. Like for example, our online evals work by sending you a harness and saying, do an online eval. They don't return any information to launch darkly. Okay. There's no API call to launch darkly that's being made in the middle of the run. No, it's all happening nicely in machine time, no added latency, no requirement to pass back customer context, for example, or customer query launch darkly. And at the same time, you still get your eval, which is nice. speaker-0: Okay. Okay. More spiciness. speaker-1: So speaker-0: You've just talked a quite a lot about sort of instrumentation, the value of telemetry, but I mean you do it will observability will it or will it not save us? speaker-1: It won't will not save us. Observability won't save us. It's a lagging observe. Can you think of a worse word? Who wants to observe a dynamic, incredibly contingent, powerful system? Observ ⁓ observability to me means passivity. It means like looking at a giant log of like every bad experience my customers ever had. ⁓ and those experiences have happened, right? Like that's what it means. It's like l living testimony that something bad occurred. And the goal is to get ahead of that, right? And and that's even more important in the agentic era because like It's theogenic era. Like the old bad things can happen. The more useful ⁓ a system is, the more critical, contingent, complicated information it has access to, right? The more agency it has to do things that are potentially bad. So the blast radius is large already. You see like that blast radius can have a serious impact on brand integrity, for example. It can also have, you know, lots of complexities when it comes to things like, you know, security, for example, of course. So It's the problem with observability is that it is lacking. And so that's why we're so interested in runtime control. We're interested in doing things inside the turn of the conversation. We're interested in in giving customers the ability to intervene before the bad thing happens, right? That for us is really critical. That doesn't mean that information is bad. Information is great. Like it's it's super important to have information. That being said, I can imagine, absolutely imagine, a year from now where we do see software factories really humming along. Where that information becomes significantly less useful. ⁓ already, I I mean, I'm sure all of us have been in situations where we see observability information about a system that doesn't exist anymore, right? And like, that's great. All right. Like I get some information about something that no longer is part of a chain that I that I'm actually leveraging. And as we see like rates of rollout to production move to the, you know, every three second rate, like I mean, just continuous, continuous, continuous software changes. That raises a huge hurdle, not just for things like observability, but for things like versioning. Like it it just like creates this like huge question of like what is this software thing and what what about its ⁓ behavior is actually you know accessible to me as an observer, as someone who wants to learn about it, as someone who wants to intervene in it. So yeah, I think I think observability is in a is in a really kind of challenging position. That doesn't mean that like Logs are bad. Of course, every log is great. But it what it means is that you need more. Like you need the ability to actually intervene. You need the ability to get actually active inside of runtime. You need the ability to thwart problems from actually happening. And to me, that is more useful than that information about a thing that's happened that may or may not be reproducible ever again. speaker-0: Yeah, you're you're you're you're definitely you're just you just do not Yeah, I mean that that's that's quite a thect about observability. Or not rock. speaker-1: No, no, it's absolutely not. speaker-0: Observability is all driving along, looking in the rear view mirror. I mean, you know, I I'm I I I I think that that the Yeah, that's quite a log based view of observability. That's what I was speaker-1: I think that's probably true. Yeah. But I mean, ⁓ I think like to me, the more useful and interesting component of observability, let's take it at like the higher level perspective. And ⁓ the last time that we met, we we chatted br we nerded out briefly about like the history of software factories or dark factories in general. And I was thinking about Stafford beer. ⁓ so early cyberneticist, really important for the phrase. The purpose of a system is what it does. Possi win. Great, great simple statement. Understanding what a system does is really important. Information around around what a system is actually inducing in terms of customer behavior is the most important thing as we shift to fully outcomes driven engineering. Like a thousand percent. And it's that particular regime of observability that I'm unbelievably committed to and interested in. It's it's significantly less, however, about the understanding the ⁓ let's say the superposition of states. That an application is in at a given point in time, that to me becomes a lagging indicator. Instead, like the focus just continues to drift to the right, continues to drift towards the customer, and continues to drift towards like really motivating the desired behavior of the factory without too much of an ability to actually get a sense of what is happening on a millisecond to millisecond or second by second basis. speaker-0: Yeah, yeah. I mean I I think that's one of the the to your point Or rather, the the the key thing is is is closing the loop. I mean, you know, control theory that that that observability is only valuable in so much as it allows us to take action ⁓ to deal with the fact that again, we are actually talking about customer behaviors, the purpose of a system. and I mean, of course, you have valued colleagues ⁓ that that are building observability tooling. So, you know, throw them a bone, Mark. speaker-1: Dziękuję. Yeah, absolutely. So you you you asked me to throw my colleagues a bone and I I let me do that. That's okay. Yeah. Yeah, absolutely. And I think like what I'm really, really interested in is like ⁓ to me, like the future of LaunchDarkly is is absolutely what is being enabled by the observability team right now. But what we're ultimately building is we're building essentially the kind of primitive or the controls team. speaker-0: ⁓ yeah. Let's do that. Like throw your speaker-1: for software factories. And that does require observability in the sense that that requires the ability to continuously pull information from production and to enable that information to drive feedback loops. That is really, really critical. And that's exactly what you were referring to earlier when you invoked control theory, right? This idea that like the goal is to take information, especially and that information is objectively more useful the closer it is to the moment in which it was actually captured, right? And it's objectively more useful the more ⁓ that information contains, let's say, some kind of like salient characteristics of the end customer experience. So both of those components need to go through a continuous feedback loop through which code is being continuously revised. So the individual observability components of, let's say, a single feature, and this is again why feature flags are so useful, or the or ⁓ let's say a particular agent harness are extremely useful. And that you have the ability to then connect and retroject the that harness's influence on the metrics that it was experiencing in time with its next iteration. The ultimate goal, especially like using a system like agent control, is that you have an agent, it's live, you have live information around how that agent is performing from evaluators, from logs, from ⁓ metrics that are being sourced from user experiences. And that information is continuously going into a reinforcement loop, right? It should be a reinforcement learning loop. Through which that agent harness is gradually and continuously evolving. That is really objectively useful. The consumer of those logs, the consumer of that observability information at the small scale tends to be the system itself, right? If I think about, let's say, ⁓ a user who is right now coding at this very moment in Claude Code, and they're looking at you know two diffs that like they have they they can't c absolutely can't parse and they and they hit accept. But like that, like That larger scale picture is really, really difficult to deduce. That smaller scale picture, when you're looking at individual contributions from a single harness to a series of experiences as expressed in statistical means and necessarily as part of a continuous live running system, that's the future. Like that's the future of Launch Darkly. And so I feel like, you know, I don't think it's a contradiction at all to say that observability in the sense of passive observance of phenomena is over. And the new phase is about continuous feedback loops, ⁓ continuous, ⁓ continuous ⁓ you know sourcing of information from prod, from customer behavior, from again this this idea of the purpose of a system being what it does into the continuous refinement of that object. And it becomes, you know, as you do that, it becomes more and more difficult to observe that system as a whole. And ultimately, you are going to ultimately attend to the behavior, to the outcome. That's the thing that like as you move up the management ladder. That's ultimately the thing that you attend to, and that's what Stafford Beer taught us back in like nineteen sixty five. speaker-0: Amazing. I love ending a podcast in nineteen sixty. I am all about I am all about theory and history and how we got here. ⁓ I think that's great that's a great rap. We we we threw them a bone. We ended up in up to sixty five. Nineteen sixty-five would you know, I'm pretty sure we'll you know we'll we can get our flares out going into the late sixties. It's gonna be it's gonna be great. ⁓ speaker-1: We pause. speaker-0: But yeah, no, that was ⁓ fascinating conversation ⁓ today. ⁓ thank you very much ⁓ for joining ⁓ the monk cast. It was super fun. ⁓ I hope you'll come back. I'm sure there will be ⁓ more room for further spicy takes ⁓ from Marek Pollux, ⁓ head of AI at Launch Darkly. ⁓ so yeah, thanks very much for joining us. speaker-1: Thank so much for having me. This is really fun. James, we gotta talk more often. I really like hanging out with you for real. ⁓ speaker-0: That is 100% true. And ⁓ it I mean it's 100% true that it is fun hanging out with you. I'm not saying I'm a mega free. But but you know, we can we can live with that. We can live with that. Occasionally we have to take the win. so ⁓ you should do all the things. You should share it with your friends, ⁓ you should get your mother to listen to this podcast, you should lose all the pot. ⁓ share it, like, subscribe. ⁓ but most of all, once again, thanks so much, Murray. speaker-1: But if you join