Restoring Trust in AI-Native Development | apidays India 2026

Good morning everyone. Hope you had a good conferencing day yesterday, which is probably why you're here on time today. But we'll get started. I think there's been a lot of discussion around we want to make the agents autonomous. And I always joke that we've not got humans autonomous. We're trying to get agents autonomous, so that's a bit of a stretch, but I think there's been a lot of interesting work that's been happening in the last at least two years to move towards this direction, and I'm going to share some of my experience having worked with lots of enterprises in terms of how we are approaching this. I don't think we have an answer, but we have a direction, and that's kind of what I'm going to try and present here. Um But the first question to ask is why do we want the agents to be autonomous? What is that we're trying to achieve? Right? My hypothesis is that every organization wants to optimize the idea to cash cycle, right? And agents are a great way to accelerate that, to get faster. And so that is one of the motivations at least is to optimize this, to reduce the time to market, to be more responsive, etc. etc. And this is not new. I mean, as as a industry, as software, we've been doing this for many, many years, and there have been two kind of big ideas that we have been putting to use for many years in terms of optimizing the concept to cash cycle. One is modular production, which is basically defining components, defining modules, having a clean interface between them, and allowing them to be built parallelly so you can assemble rapidly and get it out, right? So, this is one way of basically reducing the time to market, right? And the other is just-in-time, which is again very important from minimizing inventory and optimizing flow. Um So, these two two ideas have been around with us for many many years, and we've been trying to do this. And since this is API Days conference, I'm going to try and map this to what does this mean, you know, to APIs, right? So, if you think of modular, right? I believe we've kind of now established that, you know, APIs are kind of the LEGO blocks, right? The building blocks by which we can assemble, integrate, and build products rapidly, right? So, we can reuse, we can you know, basically bring things very rapidly together and go from concept to idea in a very short cycle. Um However, we've had several challenges along the way, right? And one of the challenges to really talk about is what's happened in the last, I would say, 15 years at least in the, you know, the desire to move from monoliths to microservices, expose everything as interfaces. Actually, it's interesting to see who would you give credit to in terms of coming up with this idea. Any thoughts? Uncle Bob. No, no, no, no. Who actually made the case? I mean, of course, this is debatable. So, I'm going to present my viewpoint, but I would say the credit should go to Jeff Bezos for really pushing with the API mandate. He wrote a letter, you know, across Amazon to all the development team, all the engineering team, saying, "Going forward, everything should be built so that it can be exposed as a standard interface and integrated. It doesn't matter if you're building internal stuff or external stuff. Everything should have a clear service boundary, and your implementation can be in whatever language you care. I don't care, but it should essentially be remote procedure invocation with a clear service interface, right? And so, of course, there are a lot of other folks who also had this idea, and so we've gone through this. But one of the big challenges you will see when you move from a monolith to microservice is you lose the compiler safety. Right? Anyone's had this challenge? When you had a monolith, you had like a lot of feedback you could get if you made a function call, you missed a mandatory parameter, you know, it would be a compile-time error. When you do this across a network boundary, it's not easy to get this feedback. And where this becomes interesting is when you deploy agents at scale, the problem gets amplified, right? So, the problems of things like, you know, not having the compiler safety now becomes a run-time issue, and this is where the problems kind of start amplifying. So, what do we do to to kind of deal with this problem, right? Before we kind of jump into the solution, let's kind of quickly take a quick analogy to just put things into perspective, right? So, anyone's been at a really good highway where you eventually end up with a single booth or a few booths, and you have to pay toll before you can move, and you see a massive congestion. Right? So, you're building these massive parallel highways, so that people can, you know, go really fast, but then you introduce these artificial constraints, which really bottleneck people, right? And so, you can draw analogy to software, right? Everyone can draw an can can apply this back to your teams in software. Like a lot of companies I I still think have these central teams, which are kind of the toll booths, and they essentially block the path to production. I'm not saying that's a bad thing. What I'm saying is essentially this becomes a bottleneck in the system. And so, I think over the last 20 years, maybe because of Agile DevOps and a lot of things that have happened, people have moved to what we call as stream-aligned teams, where they are self-contained teams. They have all the cross-functional capabilities. And so, if you kind of apply that to this analogy, essentially what you're doing is you're basically introducing a toll booth per lane. Yeah? And I would say this is much better than what we had before, but this is not what will get us to that concept to cash in few days kind of a thought process that we have, right? So, if you really want to move to that, what you need to do is you need to make sure that the vehicles don't stop. The flow does not get impacted, right? So, if you if you do things which allow things to move seamlessly, so in case of like a lot of countries have implemented this where you don't have to stop at a toll booth, you just keep driving. Right? And you use RFIDs and other kinds of things which automatically, you know, charge, right? So, what is the equivalent of that in software that we are trying to do? Uh autonomous agents feel like the second one to me. At least as of today. Because in a lot of companies, you are deploying autonomous agents. The agents are producing things at a very rapid pace, and then you have someone who has to review that. That's a toll booth. So, some people say, "Okay, we're going to add more agents who are going to automate the toll booths, right?" But then, I've not at least met any large enterprise that can completely trust non-human, you know, toll booths, if you will, to let things just go to production. Some have tried, and then they have regretted. We've seen all those stories. So, I don't think we are yet at the stage where you can say that we have completely achieved a a flow in your software delivery which which has basically no stopping, no toll booths, right? It's just seamlessly flowing. So, >> [clears throat] >> let's quickly move forward. So, we are not the first to actually have this problem. So, I'll again draw another analogy from textile. Anyone's familiar with looms? Right? If you live in Bangalore, probably you should be familiar with looms because this used to be a pretty massive silk manufacturing hub. Those places got taken over by software factories, and you know that you see the history repeats itself in some sense. So, back in the days you would have hand looms where a craftsman would sit and basically hand weave cloth and produce really beautiful design but it was a very much a craftsman ship approach to building cloth, right? Of course, this had limited errors and it was kind of well controlled but you know you couldn't like really mass produce. So, during the Second World War or even probably the First World War, people wanted to mass produce cloth and this was not a solution. So, we had the next wave which is the power looms, right? Which basically meant that you could now mass produce cloth but unfortunately when power looms were originally introduced, you would see something like this. At every loom one person standing and watching the loom. Yeah? And so if you had a factory of 30 looms, you would have like 30 people standing and watching the loom. To me this is very similar to what we have today in software, right? We've hit the power loom moment with agents. But we don't fully trust the agents and so we basically put one human at every and we call it human in the loop, which is kind of very nice. But you know essentially you're putting a human to kind of monitor this, right? But of course, if you fast forward today, you wouldn't see in any factory stuff like this. So, what did what did the textile factory do to basically change the scenario? Right? So, we could draw some inspiration from that and that's kind of the crux of my talk is basically what are the things we can draw and one company that particularly pioneered this is a company called Toyota. It's a precursor to Toyota and what they ended up building is they ended up building these autonomous looms. Which essentially had all kinds of sensors built into the loom and that's generally now referred to as building quality in. So the loom would basically be self it's an autonomous loom it will run on its own and if something goes wrong it'll basically stop and ask a human to come and basically fix things, right? In fact they kind of evolved further. I believe they have about 118 patents if I'm not wrong on just one loom. And all the kinds of interesting things they have done to basically make the loom as autonomous as possible. So today in most places you would go you would see a factory with 100 looms managed by one human. Right? And that's to me kind of the aspiration or where you know I would personally like our industry to go, right? Where you don't need 100 humans sitting in front of a agent and becoming the toll booth to the agent, right? So how do we get there is is kind of the question and there are some principles we will talk about that actually help them achieve that. But before that I thought it'll be interesting for those who have not been to a power loom to see a quick video on this thing. Okay. That's how a power loom works. You don't see a human there. And this is just showing you when a thread breaks because that's one of the main challenge in in a power loom is the thread snaps. And so they built in these kinds of systems which basically as soon as the thread breaks the lever goes and jams the machine. So it kind of stops the machine from continuing with an error. Right? So, these are checks built into the machine, not inspection. Not some human watching over this, right? And so, this is kind of the one of the innovations that that they did. And so, this is referred to as If you look at the principle, it's referred to as jidoka. This is a Japanese term for basically what what the term means is automation with human touch. Because it's a little politically incorrect to say automation without human touch. Right? But, technically you would see that philosophy has, you know, in everyday life, things that we use. So, if you've ever used a washing machine and let's say the washing machine halfway through the wash cycle, water stops. There are sensors built into the machine that will not like just continue to wash your clothes and say, "Oh, even though water, I will just wash it and give it to you." Right? There are sensors built into it, it'll stop. Another example that's very popular is in the elevators, right? When the door is closing, there are sensors in the door. If you try to If some someone is in between, then the the doors will unlock, right? It won't continue to go through. So, these are all kind of mechanisms which basically makes them autonomous. Right? Which which basically helps them achieve this. What is the equivalent of this in APIs? So, I would say something like having a pre-commit hook, right? Before you push any change, you want to basically run a battery of tests, right? What whatever it could be linting, it could be contract tests, it could be backward compatibility checks, etc. And if if any of those checks fail, you want to basically stop uh the commit going out. Right? So, that's kind of my example of how we've tried to apply this. This is before agents, right? This is how we've tried to take some inspiration from this principle and apply this in in our work. The next principle I want to talk about is Poka-Yoke. Uh Poka-Yoke is essentially uh mistake-proofing. Uh and again, we've seen a lot of examples of this. Anyone remember uh USB 2 or USB A? Uh you have to always figure out which direction because it doesn't Like you can't just put it in any direction. And so, when you move to USB C, uh you don't care anymore, right? You can put it It's just you don't have to worry about the side or the direction. So, it's one way of mistake-proofing so people don't try to jam something. Sockets are another example. Uh so are uh you know, SD cards or your SIM cards. All of them kind of have a similar uh philosophy where you design something that it is not possible for you to make a mistake, right? So, it's mistake-proofing. So, what is an example of mistake-proofing in APIs? Contract testing seems a little bit as a uh the previous example to me, not necessarily a mistake-proofing, but more of a sensor that kind of tells you something's wrong, right? So, if you take this example where you say, "Okay, I have uh you know, I can post an order and uh status is a is a string uh and I've written a beautiful comment that it should be one of these three things, right?" Uh but this doesn't stop someone from sending a status which is not one of those three things. Then you'd have to put a sensor to stop someone from doing that, right? But if you were to mistake-proof this so that it's not possible at all, then you would essentially define an enum. And so it has to be one of these three values. Right? So that's kind of I would say an example of mistake-proofing in in the context of APIs. Right? And quickly I want to touch upon the third principle, which is very important because these have a daisy chain effect and they kind of work with each other is Andon. Andon, uh the idea with Andon is essentially if something goes wrong, make it visible as quickly as possible so an action can be taken, a corrective action can be taken. An example is you you see this every day in your uh cars, for example, if your tire pressure is low, the car can sense that and put it on the dashboard so you know about it and you don't drive halfway through and then have a flat tire, right? Uh so these are kind of giving you feedback so that you can avoid uh you know problems later. Uh same concept uh with uh you know your fire sensors. Uh all of these are again kind of idea to kind of give you the feedback so that you can uh you know and now quickly moving to Andon in case of API, what would be the example? Running things in CI and when they fail, you get a very visual feedback saying, "Hey, you know, something's wrong." Uh and then that kind of stops uh bad things, it notifies people and so whoever pushed this commit can actually uh address this, right? Uh so that So just to quickly summarize then, putting all three principles together, uh the way I kind of look at it is uh you know, Poka-Yoke is essentially mistake-proofing. Uh in spite of mistake-proofing, you may still end up with some challenges and this is where you would use the Dodo code to kind of uh sense and stop things from going bad. And then when things do slip through and show up, then typically during integration or in your CI, you would essentially make it visible. And then any learnings that come back from it circles back and you mistake proof it, right? And so this is kind of a principle that we've been applying for a long time, I would say. At least extreme programming made some of these things quite popular, right? So I've given some examples in software that kind of translate to that. But how does this relate to agents? What can we do with these principles to make agents autonomous? You've already probably seen a lot of this kind of stuff where we're moving from vibe coding to things like spec driven development and we're trying to say, "Okay, you know, if you provide a spec, the agents will probably do a much better job than just giving them some prompts." Right? And in some sense there are a bunch of principles baked into this idea and if you were to kind of double click on it, essentially what we're saying in this new spec driven development paradigm, spec is the new source code. Right? Spec is the new source code because that's the level of abstraction at which humans will operate and whatever code is generated is equivalent to assembly or byte code, so you don't really care about it. Every time you just recompile, you throw away and you start from scratch, right? Not everyone's fully on boarded with this idea, but that's kind of where you know, like if you see the industry is going is moving towards specifications being source of truth. One other interesting idea is harness engineering and recently I think there was a interesting blog on Martin's Martin Fowler's site where they try to kind of classify this into a little bit more categories so you have guides which basically give feedback to the agent so that the first generation of code that the agent would do is guided based on certain things, right? So we've all written agents.md file, we've written a bunch of we provide a bunch of skills which essentially, you know, act and then again, you know, you can have both inference-based things so any MD file and things like that you're writing is more inference-based so the agent will have to infer it, derive what you're trying to say and then guide itself. And there are also some computational things which are not necessarily just inference-based but they are something that the agent can execute as a way to get feedback and move forward, right? So you've got the initial generation done which typically we call as the forward loop, but that is not sufficient, right? Once the agent has produced something, you do want to then use a set of sensors and this is kind of your Girocco in action if you will where you're essentially providing feedback to the agent saying, "Oh, you produced this but you kind of dropped, let's say, the code coverage or you didn't write tests or you you made this architectural mistake, right? So you kind of provide that feedback so it goes into a self-correcting loop and and provides you the response finally, right? And again, while all of this is happening, human is still in the loop in some sense because the human is kind of watching what's happening and maybe steering. Not all the time sitting in in of it but maybe at some regular intervals you may want to steer that, right? So, this is uh kind of harness engineering. If you were to try and extrapolate this to like API specifically, what are the what are the guides and sensors in case of APIs? Right? So, if I were to quickly just jump ahead, uh what you will see is, you know, you can feed in like API best practices, uh you can feed in things like API specifications, you can give in examples, uh you can give in agent plugins which are skills and uh MCPs packaged together. Uh these all can act as guides for the agent when it's producing the code. It'll keep these things in mind and produce things, right? What are the kinds of sensors when it comes to uh APIs? Absolutely. So, contracts, uh contract tests, mocks, compatibility tests, these are all important things. Things like resiliency and security tests becomes important. Linters and other policies become important. You can execute them and kind of give feedback. You can look at things like API coverage, uh not just code coverage, but API coverage and kind of use that as a feedback again to the agents to say, "Hey, you've not covered these scenarios and things like that." So, uh there's quite a lot of work happening in this space both on the guides and sensors to basically make API design lot more autonomous uh with the agents. Uh but it doesn't have to stop here, right? This kind of can apply throughout the uh SDLC process in terms of even at further stages in the pipeline, in production, you can have a constantly learning running loop to basically do drift detection and so forth so that you can feed that back to the agent so they can self-correct, right? So, it doesn't have to stop at the first uh generation of the code. It can go all the way uh into your pipelines, it can go all the way into production and keep the loop running, right? And I think there's a lot of promise with harness engineering, lot of work is happening with harness engineering, but I would ask myself, is harness engineering sufficient? Will that really help us achieve the the dream of autonomous agents? And that's kind of where you start wondering about what happens to things like your architecture, overall architecture, not just an individual API, but the whole system architecture. What about things like governance, you know, would would it be able to handle all of those kinds of things? So, just kind of again, like if you have guides that help the coding agent, you have sensors, which basically are executable specifications, which kind of guide the thing. So, that's an important thing at a individual API level, but a system is not just an individual API level, right? So, typically when you have some kind of an intent that you're trying to communicate, how do you make sure that what you are thinking is being effectively communicated to an agent, right? So, there's a term that is emerging for this, which is called executable intent, which means that you are able to express the intent and validate the intent before you actually give it to the agent to make sure that what you are thinking is actually machine understandable, agent understandable, right? And there are things where you can go from like plain English to an executable specification, you can spin up a sandbox in which you can actually prototype and figure out whether, you know, if this is your business case, whether it has captured it correctly in terms of an API specification. And when I mean an API specification, it's not just OpenAPI specification, it's things like Arango, it's things like which allow you to orchestrate an entire workflow, right? So, it allows you to capture that, simulate that whole thing so that you'd be able to validate It's It's almost like Figma for API design, if you will, right? Where you can quickly do high-fidelity prototyping and kind of execute your intent and validate whether your intent is what you need, right? So, that's one idea that we've been working on. Lots of other folks are also doing a lot of interesting work in this space. The next one is what we call as executable architecture. Uh the idea with executable architecture is that individual APIs is fine, but across the several different integration patterns that I have, it could be uh RESTful integrations, it could be asynchronous integrations, it could be uh file-based integration, CLI-based integration, several other forms of integration. How do I define all of that not in a document which is again inference-based, but a document which is executable? A document that I can actually click a button, spin up my entire architecture, right? And then be able to kind of test itself, right? So, one of the ideas that you would see that is emerging is kind of using a combination of Arango specification with uh OpenAPI specification, AsyncAPI specification, and then spinning up a mock for the entire system. So, you have all the pieces that that basically spin up as a mock, and then you use the same specification to then generate a test from it. And so, it gives you uh a set of tests that will run against the mock. We call it the closed-loop uh test. And what this will do is it'll help you visualize if this is how you're envisioning your architecture to be, whether it makes sense, right? You know, so before you've actually built a single line of code, before you've even asked the agent to build anything, you want to kind of quickly validate your architecture itself, right? So, that's again another I would say idea on top of Harness Engineering that would allow you to you know, validate your architecture and keep this loop going, right? So, as as components get built, they get plugged in, but the overall feedback back loop on your architecture to make sure that you're not drifting. You intended this to be asynchronous. It should not suddenly become synchronous, right? Those kinds of things can be now validated at this level. Is that sufficient? Are we good with these two things? Is there anything missing? I would say there's one other important thing, which is the governance thing, but not the current style of governance that a lot of places we are seeing. What we want is essentially again a continuous governance, which is kind of a control plane, taking feedback and providing feedback to each of these. So, just to give you a little bit more context, when I'm trying to do executable intent, let's say I'm going from a plain English intent to executable specification, I don't want to reinvent things that already exist, right? How How does How does the agent know when it's going from plain English to an executable spec that this already exists? Today in a lot of organizations, we don't have a single view of the API inventory that exists in your organization. Even if you have, it's it's in lots of different formats, which is not very friendly for an agent to understand, right? So, imagine you had a kind of central repository of all your specification. You don't need the details, but mostly the metadata which an agent can understand and that can be fed into this upper cycle there, executable intent cycle. And so, it can basically leverage what is already there, not rebuild it. So, it avoids duplication and stuff like that. It can reuse schemas that already exist. So, for example, if shipping address is already defined in your system, you don't want to build a different implementation of a shipping address again, right? So, all of those things can be leveraged back in this. And also, same thing applies at executable architecture level. These all kind of feed into each other. So, there's almost you can imagine a loop going around this whole thing, right? So, you have executable intent, you have executable architecture, you have the hardness in between, and then you have governance, which is kind of your control plane. So, all put all of this together is what I think we're calling as closed-loop engineering and this is I'm not sure if this is sufficient, but it is at least something that we're all kind of building towards as we go to figure out if this can help avoid a lot of challenges that we are seeing to avoid kind of the toll booth, right? So, just to again quickly summarize what we're saying is you want autonomous generation, you want validation against executable specification, you want any deviation to be detected and removed. You then want the correction, the sensors to auto feed in and then that leads to a continuous flow which allows you to trust the output before a human gets it, right? So, all of this happens before you actually look at it and so, the trust in what the agents are doing would go up and hence probably you'll stop putting a human in front of an agent and slowing it down, right? So, I think that's pretty much what I had. I am uh I wanted to leave time for questions, so I think it's good time. We have 10 minutes, if I'm not wrong, or 8 minutes for questions. Yes. Can someone please help with the mic? >> So, my question's on the previous closed-loop diagram that you just showed. >> Yeah. >> So, what if we have an ability to treat that whole thing as a skill and then put it in a continuous uh self-learning mode? Would that be a good extension of improving that? >> Uh you will run out of context. >> [laughter] >> If you try to stuff all of this into one skill, you will run out of context. That's my short answer. >> Got you. >> Yeah, Naresh, uh really nice uh presentation. Uh so, I had one question. Uh you mentioned at one place uh in your uh kind of uh the structure you presented that uh whenever there's a mistake, uh we would like the human to get involved there. Yeah? So, with the uh new systems and AI becoming more and more powerful and uh all the experimentation going on, uh will it not be an idea where we actually have some bit of intelligent auto correction also built there? And then, if AI is not able to correct something, then only human comes in the loop. >> Absolutely. That's That's the idea with Basically, that's why you're providing the sensors, so it can self-correct itself. You don't necessarily need a human. You only need a human when the the agent is not able to figure out things. Uh but, you make sure that you can provide uh both the guides and the sensors, so that the agent can be autonomous to the extent. But, I'll give you an example, right? What if you've given contradicting uh you know requirements in your prompt to the agent? What should it do? Should it self-correct? >> Yeah, yeah, it can It can still try to self-correct, but when it gets into a situation, see, that that trigger has to be there somewhere, yeah? So, that trigger has to be there because AI in the current form is highly likely that it will never come back to us with the LM support will never come back to us saying that okay, I'm not able to do this, yeah? >> That's the problem I feel today is that the agent assumes, right? So, if you give a contradicting requirement, like to make it very specific, let's say in one place you've said that this particular value should be less than 10. In another place you are you've given that it should be more than 20, right? Today, the agent will pick one of them and move forward, right? So, you'd give some guides that will tell it like, "Hey, don't do this when you're confused." Like basically, pull the human. Don't So, the the difference, right? Is that don't expect a human watching over you, but when you can't figure out stuff, pull the human, right? So that you you can like not make assumptions because once you start making assumptions and people figure out it's not what they wanted, then the trust factor doesn't kick in. When the trust factor doesn't kick in, then you'll have one human standing in front of every agent waiting to watch, right? So, we want to get out of that loop, that mentality, and you want to let the agents do things, and that's where you want to provide as much information you can, but when you try to provide too much information, again, like you end up, you know, uh exceeding the context, you end out uh other kinds of problems, uh and you may not get the results, right? So, there's a lot of uh I would say skill involved in terms of optimizing the context that you're going to provide and when you're going to provide that. But, let the agent pull you when it's not able to figure out something rather than assuming and moving forward. But, to your point, absolutely, you'll provide the sensors, you'll provide everything so that it can self-correct, right? You don't want to be waiting and watching over it. But, that's not always possible. Like the example I gave you where you've given contradicting things, right? Or there may be other regulatory kinds of things where it's you wouldn't want it to just make Yeah, okay. >> Um hi. So, I really like how we are, you know, uh putting this together for APIs because right now in my organization, we are we have something called maturity index for each of the repositories. So, this stands first, I guess, the guides and the sensors and everything else should be put together for APIs and then separately for UI. My question is regarding the guides, uh where uh the agent plugin uh has skills and MCP. What do you specifically mean by MCP in this place because whether it's a developed MCP or you're just providing the guidance to create that MCP along with the API? >> Uh so, there are several different forms of MCPs that you can plug into it. Uh so, anytime like basically an agent is going from a prompt to generating the code for you, it'll need a set of uh inputs, right? So, a language server, for example, is an MCP that you could provide to it, right? But, you could also have an MCP sitting on your control plane that the agent can talk to to figure out like, "Hey, am I doing uh something that I should avoid, right?" Uh from uh let's say uh if you see like a API is unstable, should you be depending on that API? >> Okay. >> Right? You may not want to depend on an API which is unstable, which is not or deprecated. Like that's even better example, right? So, if an API is deprecated, you would want that feedback to go in. But you can't stuff all of that in up front, right? So, you would provide, you know, MCPs to kind of make those decisions. >> we are talking about real MCPs that do the job of implementation and correcting and all that, right? >> MCPs for mostly providing feedback to the agent or guidance to the agent so that they can kind of self-correct. >> Okay, yeah, yeah, understood. >> Or produce things right in the first place. >> Thank you. >> Uh so, really loved the presentation, Naresh, and especially the analogies of the loom and the traffic lights. Uh brilliantly done. And I was actually I worked on the Citrix API platform long back when I was 18, 19, and I just wish I could take all of this and go back in time and you know, use all of this. Uh coming to the question, to me looks like this takes care of a lot of the design aspects, implementation aspects, even testing. Where do you think you know, runtime characteristics like scale, performance fit into this whole you know, framework? >> That's That's a brilliant question. So, when we saying the governance piece, that's also looking at has all the observability aspects into it. And that's kind of where you want to have these feedback loops between them, right? Expose an MCP on your control plane. So, everybody else can tap into it. And you know, you basically are getting feedback from a monitoring from your governance, sorry, from your observability systems into this. So, you know what's happening in the production environment at runtime as you scale things. But also what at least we've done in a lot of cases is built a lot of that stuff here. Right? So, when you're individually designing an API, you can do a lot of resiliency testing. You can do a lot of things. For example, if a downstream service is down, how are you going to behave? You know, you have you implemented circuit breakers correctly? How do you validate that? So, both as part of sensors and guides, you can kind of So, guide would be essentially like, "Hey, for for this kind of an API, I want you to fall back to asynchronous." Right? So, instead of doing 201, do a 202 uh and then respond back with the monitor pattern. Right? Like that would be a like a best practice that you would feed into uh the the agent. Right? But then you need to validate whether it did actually implement it exactly in that way or not. Right? Is It's given you a monitor link, but is the monitor link actually when you hit it, eventually when it completes, does it give you back a result? Right? >> [clears throat] >> So, a lot of those kinds of things at an individual API level, today we already have the capability to do that. Right? But at a scale, when you're trying to look across like in my case, 40,000 services, then you essentially want all of that data coming into your control plane and then feeding it back into all the agents. Right? So, that's kind of another example of the MCP that kicks in. >> Thank you. That helps. And if I may add a part B to the question, if let's say you're specifically designing and implementing APIs to be consumed by agents, in that case, do you see this framework evolving and >> Absolutely. So, there are a lot of like AI quality metric score cards and things like that that you build into your governance, which essentially helps you understand whether the API itself is ready that you want to expose to an agent or not. I think there's a lot of great work that I don't know I Eric and Frank, the folks from Genentech are doing. Even Kin Lane is doing some very interesting work in that space. So, there's a lot of folks who are trying to figure out whether like how do I score, how do I guide, whether my APIs are actually ready for the agents to be consumed.