The Death of API Management. Welcome to the Funeral | apidays India 2026

Uh so it's my honor to welcome uh Medi. Uh he is I'm sure you know about his background. Uh you created a startup uh when you were 27 I believe. >> Yeah. A long time ago. [laughter] >> Uh Oth at >> O at that time. uh and uh of course sold the startup and doing a lot of interesting work now. Uh but what I really like interacting with Medi is he's a deep thinker. So you can pick any topic with him and you can go uh pretty deep philosophical practical uh lots of uh experience. So it's always fun to kind of uh spend time interact with him and uh the topic today he has and I think he gave a little brief in the pre-conference that we had that uh this is going to mix like sugar and disappear but I'd let I'll not steal the show I'll let you kind of continue. So thanks again Mary for joining us >> and thank you Narish. >> Please welcome him. Yeah, [applause] thank you very much Nares because actually as I organize the EPA conferences most of the time I don't speak in these conferences again my role is to put everyone uh under the light right and not be under the light but narish you ask me so thank you very much for for that and that gave me the opportunity to share actually what a lot of things that I'm seeing in the in the in the space so again you know since the uh the chat GPT like three you know over the I almost two years three years sorry uh four years wow that goes fast no but almost four years a lot of things have changed in the API industry space have changed a lot right we've seen many vendors that are actually completely who have been who have feared a lot what was happening a lot of developers architect that are completely you know changing the way they're they're they're uh working their the jobs are changing so yeah I just wanted to share you a little bit what I've what I'm seeing really strongly over the 18 months right and so a little it's a little bit provoking but uh as I I created the API conferences series 14 years for for 14 years ago uh more than 100 conferences I wrote two books on APIs and API management I I did consulting on API management I made a company a startup that I sold so I'm I'm leaving API management over the last 15 years right and today I may I may do the I may do the uh the conclusion that yes uh we may assist to the death of API management and maybe today is the funeral. So, welcome to the funeral of the AP of of API management. So, uh yeah, 20206 26 we will see. Uh actually the 2000 I'm not completely sure you know uh uh I I relate to Nares what he said about Jeff Bezos mandate which is to 2002. Uh but the 2026 I have a feeling that's we're close right we're really close. So for the people who may have a call or may leave the room will management is up here. Yes. Okay. Talk is over. But if you want more details you can stay. You you can stay to know exactly when I'm saying that. So this is me uh you know uh wrote two books on API management. Actually there will be a book signing at 10:30. We have 100 books to to give away. Uh and yes I created APIs conference series. I created the O.io developer tool and startups and also conferences about AI. Right. Also currently I launched a new startup. We raised some money to build a bunny. So Bunny is just a few words but it enables humans and agents to ship full application directly on discord slack or teams right it's fully open source and actually what you do you use the slack you use the the chat as the context layer to uh to uh to mix between humans and agents and also you can stream and remote control a full um a terminal full shell and you can set up a full VM so it's humans and agents controlling a full dev environment. You you SSH connect and then you are able to fully work humans and agent together, right? So you can test bunny and cloud. Uh if you love pens like me, you you'll get it. Okay. So API management from birth to life, right? From birth to life. So actually the birth it's funny because we didn't plan that for me. The birth of the concept of API management was the Jeff Bezos mandate. You know, I just copy and paste here uh what he said. But I love the fact that it doesn't use the term API. He used the term service interfaces. Right? So the term API is has been there. The first time it was coined, it was 1968, right? It was at the mother of all conferences. So that was the first time the the the application to the interface to program application was was mentioned, right? 1966. But it was a technical term, right? Jeff Bezos is not a he understand computer science, but he's not an architect or whatever, at least by job definition. But he used the term service interfaces because it's all about interfaces. And what I really like in this is that of course team must communicate with each other through these interfaces. This is what he claimed. But there are really two sentences I really I really love. It doesn't matter what technology they use, right? So API is not a technology, you know, just an interface to access to a system. It's not rest JSON, it's not soap, XML, it's not gpc, it's not graphql. It's the interface that matter. As long as an interface to program the application, that's fine. you know we will manage it out right of course some protocols and some technologies are enabling to do it faster better cheaper but yeah doesn't matter about the technology the second one I really love is that the other one like all interfaces all service interfaces without exception must be designed from the ground up to be externalizable so he understood first the concept of the exposure of APIs to people you may not know in organization right so that's 15 years later we call API as a product Right? The fact that you will not integrate APIs, which is really a technical term, you will consume APIs. They are so sweet, so nice, so well designed, so well documented. You consume them, you don't integrate them. It's the same thing. But, you know, it's just a mindset here. So, he was pushing that mindset uh directly, right? So, and then there's a governance aspect. So, anyone who doesn't do this will be fired. That's the governance. So, but he understood that since the beginning, right? So for me that's really the start of API the API management mindset because now if every service in organ in an organization has an interface that you can talk to so you can decouple the interface from the service. So you can the service can evolve but not the interface you know vera vogels the CTO of AWS say APIs are forever code can change but APIs are forever right you know so then you can manage all the traffic all the interaction between applications you can manage versions just using the interface so because of that mindset the API management mindset and practice arise right you know managing what's going on from interface to interface right and actually it works So Amazon is a growing really great company AWS is thriving but actually Marshian von Alstein who is a researcher at the Boston University he made a study over 200 companies over $2 billion valuation so not just tiny small businesses uh but at least $2 billion valuation and he compared from industry company who have a strong API initiative and strong API management practice versus company who don't have yet a strong API management practice practice and so he called it how API create growth by inverting the firm because what he claimed is that when you put an API on top of a service you make it discoverable you make it self-service you know if you document it well and everything you know you can it can reach its maximum capacity and output right you know because people will discover self-service integrate or consume and then you know you don't have to promote it uh so it can it has full full reach right internally or externally with partners with developers of of the world, right? So, and in this paper he has this graph that is really interesting. So, he compared these 200 companies, you know, and industry per industry, right? And he has this log function which is the market value versus the quarter relative to API adoption, right? So, this is the API adoption signal here. and you can see a a decoupling for or for the first quarter you don't see a big decoupling but you see a decoupling after right so when I met him because he spoke at one API conferences I asked him like is it because they had good API management practice that they thrived or is it because they were thriving that they had to adopt API management capabilities to sustain right that's that that so he told me this chicken problem is not solved but at least there is a strong correlation you know there is strong correlation not position but strong correlation. [sighs] So what he found after two years company who have a strong API management practice in average have 12% higher valuation $2 billion in minimum that's that's few hundred million of valuation right 38% extra growth over 16 years you know he conducted a study over a long time again so it works right the API management mindset worked Amazon Jeff Bezos started the idea but company who have implemented actually made it work and in the paper He continues and you can see that if you check revenues he claims that company who have a strong API and API management practice have 60 66% more revenue in average. Wow, you know something is right here. Something is right. But yeah, so that's the area of API management and you know in the paper he takes lot of examples of uh industries but he also take the example of many US giants and you can claim that all these companies at some point have a strong API initiatives and even in India all the banks in India all the telos in India you know at some point their success is linked to how they manage their APIs at some point or how they internally or externally right but then over the last 15 years things have changed change a little bit because a new practice emerged. Uh this is actually a talk from Andre Karpati you know he was the previous open AAI developer now he's previous Tesla AI developer now then open AAI then entropic right now at entropic so he has this idea so so in the same time the API managements were thriving we had this new era of software coming so so he claim he used to call it software 1.0 O is where you classic code programs classic computers right deterministic code like real programming language the same code gives the same results right then you say in 2012 AlexNet you know with deep learning the start of deep learning you know we begin to have new way to program technology you know with weight we were able to program neural lens so it's a different you know because it's a it's a completely another way to program you know what we will call now a AI I today right and he say like in the last few years he called it software 3.0 Oh, is that prompt or natural language is able to program large language models. So actually, so it's not a full programming language per se because the same prompt does not give exactly the same results, right? But at least you know this is a this is uh how how we claim that you know you you kind of program the large model. So this happened in the same time in parallel, right? And then you know you have the explosion of uh of uh the the LLMs and everything. But and Jensen talks about the token economy. He say now tokens actually are the new currency. You know they're the new currency. You can turn tokens into text into pictures into videos into whatever documents. So tokens will be the new currency of the software we know today. Right? I don't know if you've seen but some actually people train are trained to develop full computer that is just an LLM. So actually you just it's just an LLM that you browse and and all the application are generated right doesn't work perfectly but they have this idea right so just to say there is a there is a shift yeah there is a shift that you all know right so and this shift we can turn that into like we're maybe shifting from code to tokens [snorts] as the unit piece of information where maybe shifting from computing to cognition you know it's not just the output now we want the outcome the outcome is cognition is the intelligence, right? We are shifting from syntax like exact syntax to semantics you know with the natural language aspect and in the common line you know exact common line uh to conversations and that change a lot of things into how we build software and we will see that actually that change a lot of things for API management but there's a link on the other side the opportunity of AI is huge you know so you know this company of course but we they claim that a at least tokens will be just a proxy of electricity. So it will be as fundamental as electricity, right? So that changed a lot of things about how we think we will build software tomorrow. So about the GI use cases and everything. So again some researchers have scales you know from just data transformation, natural language interfaces, workload automation, um a copilot assistant or autonomous agents. So Narish talked about the autonomous agents depending on where we are. I think we're approximately here, right? I don't know if people agree. It's an average, right? So the average is misleading. U you may know the joke, right? About an economist who was was not knowing how to swim, you know, sorry, an economist who didn't know how to swim uh died in a river of an average of 1.5 meter, you know. So that's that's the joke about the average. only mathematicians laugh at this one. But so yeah, um I think we're approximately here. And what happened here is that in 1997, Robert Solo, who is a Nobel Prize of economics, he said that we were having thriving software, but we didn't see labor productivity as much as the software impact was was there. Right? So he said we have we see the computer age everywhere except uh in the productivity statistics you know. So my question today with all the agents all the token we spend all the money with organization spend are we seeing the AI revolution everywhere but in the productivity statistics how many organizations did not find their ROI did not find the value in AI and agents we know the opportunities here but we they didn't find it and maybe the solution is that is transitioning from API management to something else and this is what we will explore in the second part this is uh what openai send to machines when they reach 100 billion token. Funny enough, you know, they had this idea of organization will use AI to develop and thrive, right? But finally consulting company are using AI to help customers, right? So finally the adoption of companies didn't work. the adoption of company didn't work and it didn't work so much that actually open AAI had to launch a deployment company with a consulting company you know the the fact that organization will adopt it didn't work and not just open AAI you know entropic launched one Amazon launched one you know it seems that yeah AI is not easy to adopt right you need a you need more tooling and more practice right even Alex Karp the CEO of Palanteer you said about his fellow American company's friends. Yeah, these guys are stealing people. Company engaging in token maxing are wasting massive amount of money on rising token costs without seeing actual productivity gains on return on investment. Businesses burn budget and token consumption that acts like a compulsion rather than solving core problems. Whoa. What's going what's wrong here? The opportunity is huge. We didn't make it work. and but what we've learned in API management can help maybe this is what we'll see so the question today we'll try to understand what killed API management but why what we can learn from API management to actually make AI successful so the act one the act one is the new practice is emerging so for me API management is disappearing because a new practice is emerging so if we go back on definitions so API management is everything about managing the life cycle from the the API from the from the strategy, the design, the the the development, the test, the management, the security, the versioning, you know, the exposure, the the metrics, the monitoring and everything. So that's the API management practice. Then you have the API gateway who is really the the runtime proxy, you know, for everything which is part of the management about authentication, authorization, rate limit, throttling and everything. And then we have the appearance of AI gateways. So maybe in the room who has an AI gateway at least in test in their organization really few okay but still you know so it's coming so it's the same thing but for AI models right you know the control point for model prompts and hallucination token consumption and everything and then the new thing I think that is kind of actually diluting API management is context engineering you know I think at the end APIs and API management will be just feeding context you know and you can see there approxim imately 10,000 open position of context engineer you know they're really well paid so if you want to find a new career think about context right so API gateways really manage how software rich systems AI gateways how agents or LLMs or models like reason decide and and are governed but context engineering is really the discipline of giving the right context at the right time for an agent being sure that he's as always what he needs why because actually the context window of agent is limited now for now most of the frontier API like give up to 1 million token uh 1 million token window for context that's not huge right an organization has lot more institutional knowledge you know so you have to give the right context at the right time for the the agent so when he will do these actions so and there are research papers to have unlimited context infinite context because they actually they they have 1 million token on the context window and they call the previous 1 million token on a context window and they try to do it infinitely. So Google is having some research. But we found that no the more important is the better context than the infinite context. So it's an engineering problem. We don't have enough but we need to actually master it and optimize. Right. That's good. That's good. So for me context engineering is the thing that is that that's one of the killer of API management. The act two is that agents are taking all the management attention. they're taking all the management attention because with APIs we have requests per second you know rate limiting we just manage the output with uh LLMs and agents where tokens per second so it's not requests now it's tokens completely different world right completely different mindset and I think the future of context engineering in a business context will be cost per task so we're shifting from request per second to token per second to cost per task and that's the end goal Right? If we really want autonomous agents that enable company to thrive, we need new metrics. We need new models, right? Then we will see we will actually see if we earn productivity or not. So what what what chang into that? So of course the the reasoning and everything around that is really changing the way we have to think management of governance and in the in in the of technology. What stays the API stays you know they're still here to provide deterministic context you know they're here to stay they're already managed and and it works right business capabilities transactions and everything but what emerge is that new gateways are needed for AI capabilities so these are the AI gateways that is the new way to think uh like the management of LLMs and and and in organizations okay so two reasons that I think are hurting that have hurt API management. The third one is API management is not made to get intent. An agent needs intent, right? You know, everywhere from S SOA to RES, GraphQL, whatever API products mindset, LM application agent, multi- aents, right? But API management has reached his limits, you know, doesn't get the intent. It's mostly for calling URL path and getting response and and that's it, right? we had to hardcode and orchestrate ourselves you know the the the the different workflows now the workflows are directly thought by the agent so API management is not made for that right at least the way we know it the way we know it so we were shift we're shifting from call this endpoint to invoke this tool to solve your problems to actually complete this task management is not made for that the way we know it definitely not definitely So yeah the governance is completely shifting from you know requests to operations to capability to outcome and again the way we do API management today not made for that act four APIs are relegated to the execution layer APIs were there on the management layer you know because they were actually on API management side right but now they're just on the execution layer so now the workflow is mostly you have a user goal that try to a customer an employee right then the agent is planning the actions. He will check what are the tools, what are the data available, what's the context he can use and then he will call APIs to actually execute. But now APIs are relegated to execution, right? They're not the management layer of data flows and everything, right? So in my opinion, this is what's where it's going, right? So the reasoning layer will be where LLMs are mainly used or agents and they're the probabilistic planning. So we'll need to shift that. Then you have the context layer who will be mainly the control plane of all of this where MCP actually will come into the game give context to models right and maybe some rag also to give some data right you know all the as we say the PDF the confluent model the documents the wikies and stuff like that and then the execution layer will be made by APIs right we already have this it's already governed it's already working and it's deterministic so we have the nondeterminist istic uh probabilistic planning but we need at the end to have deterministic actions this is why API will still be there but they lost prime time they've lost the the prime time of governance of course without API agent can only talk then we need tools we need API we need access to data access to systems to execute bounded capabilities so yeah so that's API will still be there but we will manage them in totally different way so what does that mean that means that for the agent era we should maybe now expose capabilities and not just uh raw endpoints right okay act five the gateway shift the gateway shift so we talked about API gateways and and AI gateways actually there is a big shift so I love this quote from Jensen again we're going to a world where it will be just API calls to LLM to API calls to LLM to API calls to LLM right in organization so that means we have two new models of architecture for API management uh you know either We have API management. We keep it for APIs flows and we have AI gateways for LLM flows. So two separate entity, two separate teams, two separate skills, two separate budgets and you know with all wrong that could be come with it or we have a mix. We have APIs calling LLMs calling APIs calling LLM and we have API management with AI capabilities. Many vendors actually in or which are API sponsors are actually doing this. You know they have they add AI capabilities to their API management. But there is an interesting sign. Kong one of the companies actually said that they are decoupling their AI gateway to their classic API gateway. So they still have AI capabilities into their API gateway but they say we're separating the AI gateway from that. Right. company like Port Key, they are just AI gateway. They have been acquired by uh PaloAato networks again just as a pure standalone AI gateway. Something is coming right you feel it. So of course at the end they will do the same thing but with a complete different mindset you know uh they will just still authenticate users or authenticate apps or authenticate clients. they will still root request but not the same way with API calls or or prompts completely different thing. Rate limiting will be token consumption. Uh caching will be semantic caching or prompt uh uh prompt caching. So it will be completely different completely completely different same job but not the same practice. So again that means we may also need to change the way we design governance because now we have intelligent systems. So maybe we'll go to more natural language governance you know instead of having a really more defined into into the system maybe you know the agent will be able to interpret a little bit but still specified at some point right so AI gateways will not directly replace API gateways but they are the last mile to the customer. So that means you know they will take prime time they will take the budget they will take the attention and API gateway will be released like ESBs and you know in the in the abbyss of the systems right so many architecture are possible but you you know like really from the user from the agent the API and API gateways will be released you know below right you know below but still there will be the deterministic uh authoritative execution boundary I'll give you access to the slide right So you can take photos totally fine but just to let you know I'll share the slides. Act six the tokconomics is replacing the APIomics. We talk about management but for me again the traditional API KPIs for API doesn't work well with the KPIs for agents you know latency errors and everything but again it's a completely different way to think it's not like errors uh call it's a it's response failure but how do you identify that the response failure from an agent you know did accomplish the task it's not the response so so many things are changing the way that the practice cannot be the same, right? The practice definitely can't be the same, right? So just an example how we count. We used to just have API calls, you know, reg limiting counting. Now the cost per task will replace the classic API calls. So imagine you have you have an agent that have 20k input tokens 2k output tokens four tool calls that is calling you know and you know and then you will have the cost per token then you will have to think completely how much you pay in infrastructure you will have to completely change the way classic API management is doing complete new mindset it needs to be something different in my opinion it needs it needs to be different and then when we have multi- aent that will scale, right? That will scale. And when you do the work with multi- aents, for example, 10 agents, four tasks per minute, 20k input token, 800k um uh input token per minute, 30 input token per second. For me, that will be the pulse of the company, right? How many tokens you burn per second, you know, and you will see like uh maybe company will compare their agility, their ability to execute with actually the token they burn per second, right? like electricity, you know, it will be a bill like electricity, right? Maybe at some point we will have the business outcome per dollar under policy as the end metrics, but again API management is not made for that. Definitely not made for that. Okay, act seven. Uh I'll check the time here. Oh, I still have some time. Act seven, context management as we said earlier for me includes already API management. It's part of it's it's a feature of context management. API management is a feature of context management. So again let's imagine again that we have a class we have APIs that are you know business bounded uh in context but then when you will have a request to do workflow to do when you will have something to do you will just pick the right context you know context packet I call it to actually execute the task right you know you will not have to do all the calls and getting all the answers and everything you will be able to just pick and choose right so if we take an example for refund workflow just imagine you know the user ask a refund for a specific invoice then the agent will build a context will check what's available what are the tools what are the APIs what's the policy what are the evidence you know that actually there was an issue and actually I can prove it then they will evaluate you know so they will evaluate with reasoning based on the context and then they will act but the action will be made with APIs right so API is still there but again the management layer will be before when the context would be built when the evaluation will be made and then the feedback aspect will be important you know to reinforce the good behavior or not about the agent. So the agent will never receive the whole system or the whole response only the scoped context and permitted capabilities on the fly. So the context management is maybe what we have tried to reach on API level. you know the role based management you know we only have four methods like get post put patch delete five and link if you add six one but you know it was kind of quite uh discreet now it will be a lot more blurry that can be scary that can be an opportunity right some people think we're going back in the old days and some people believe it's the future so I call them microcontext they're like microservices for context you know yeah like how many times you had the debate about what's the size of a micros service h how big it should be how small it should be right there's one that I like is that a microser should be as small as possible but big enough to represent a full business context or a full business capability right you know so for me that's that's one of the definition I like uh yeah context should be the same the context should be as small as possible but as big enough to be able to full to make the full uh to give the full context for agent to achieve his task with the right information right with evidence with grounded capabilities you know the fact that we are guarantee that the execution is doesn't come from an elucination so from API endpoint management to capabilities management that's another one because of course API endpoints are just a a way to request and get and get response but we now with agent we need to express into capabilities because we're at the execution layer Now we're at the execution layer. So you know from classic endpoint catalog we may go to a capability registry. So we have to not erase what we did but we may have to think differently right you know think in terms of capabilities because now agents are able to think in terms of capabilities based on what APIs provide right capabilities are provided by APIs but completely changing the way we think right you know so all the work we're doing on specification and everything it will be important for agents but maybe on the business layer the execution layer wow menu standards may will probably And then we already have some standards there. You have the open API specification. We have the MCP the model context protocol. And now we see more agent tool registries. So we're really shifting from of course open API specifications. So path method schemas parameters response everything still there and agent love this. MCP adds a lot of things. All right. the the the prompt the the the the resource access but now we see many registries know organization wants to have agent registries to know the identity of agents the capabilities that are actually available right so agent can know what they can do right so it's not just the context it's the capability so again API management is not made for that definitely not made for that and you can see for example uh many many large organization actually are the cloud you know Google and Microsoft and Amazon are actually fighting to be the agent registry, the capability registry for organizations. There's a big fight. So again, for me, the things have shifted already. Okay, what does that mean? That means that agent experience is the new developer experience. You know, in API management, you have developer portals for documentation, for developer on boarding. Maybe that's over. Of course, for now, not now immediately, but the next onboarding will be onboarding agents, you know, being giving the tools, the right context, the right tools for the agent on the fly, you know, to be able to actually build the application it needs with the info he needs, right, and get all the all all the tools he needs actually to make it happen. So for now we still have developers but over and over more most of the platform will be made directly for agents to discover and and build directly on top of of systems and APIs. So AX is the new DX right? So that's uh that's how we call it. So even open API so we have open API maintainers here specification but open API may shift may go maybe in the future to be like a lot more having I don't know if it will be part of the spec or kind of an an add-on but at some point you we may need to definitely make it agent optimized you know you know for to avoid elucidation using more standard like JSONLDD context linking or more semantic description intent putting intent directly into the into the specs. We'll see, right? We'll see. But I remember a world where in the hotel industry, you know, hotels um travel industry, sorry, travel industry, they work with hotels, they work with flight companies. Hotels, you know, hospitality systems now, they they have been more into rest JSON over the last 15 years. Flight companies, their loss is still of so right. So I remember the time where companies were managing two different interface for two different industries. They were having their soap XML documentation for so people who wanted it and rest JSON documentation for industries that wanted rest JSON. Maybe we will do the same for a certain time. We'll have documentation for humans specs for humans documentation for agents specs for agents, right? I don't know the open API maintainers here what's what's there but guys you should do something okay and the grand finale is that actually I think context management is the new API management so and I put that into four pillars that and you will see that API management is is is uh reviving into this but uh uh what I call identity and intent business and domain knowledge and evidence execution and feedback The first one is identity and context. Of course, we need to know who is making the request. Are they allowed to make the request? Is the agent a known agent internal or external? Is the agent authorized to do this request? So, we will have this identity layer, right? And intent layer that we need to to figure out. So, that's the pillar, the first pillar of the context management. And again, identity and purpose, you know, are part of API management, but now they're completely completely changed, right? you know the policy aspect, the permission, the scope, oth, we will need the o for agents. Some people are working on it but it's not there completely standardized yet. The second pillar is maybe the one that is really familiar with what we have today. It's the business domain context. It's the APIs we know that execute specific capabilities right you know so that's still there and that will be part of context management. So APIs API management is there but in something else something larger. The third which is why I think API management is obsolete is that the knowledge and evidence context you know with APIs you only have really governed and structured um interfaces but what are the documents all the PDF all the non-structured documents in the organization that should be in the context you know that can give answer they are they don't exist in API management but they can exist in context management the docs the policies the wikis the you know the outdated uh confluence documents and last but not least is the execution and feedback context. So the tools that will you you will be able to call the the actually the the the decision how who is the organ person in the organization that is able to make a decision to actually say commit to the agent yes I can validate you you can commit to to this that will be part of the context you know where is the human in the loop so that will that how we can measure that so yeah APIs are not just called by the agent API response become the next context for the agent you As we said, you know, it's a it's a chain, right? Okay. So, what's the road map from shifting from API management to context management of still by API governance, but it's it's about tool exposure. What are the tools and capabilities that I can call by APIs, right? But to add to the context, what are my AI gateway controls? Because of course, I manage APIs, I need to manage models, how I can all of this is part of the context. what are my context contracts you know and like how do I manage the context and then what is the outcome governance that I want for my business right do I do can an agent do that if the price is good and if the policy enables it so the matching model so we had APIs non-managed then we had managed APIs then with MCP and other stuff we have managed tools tool coding and everything to feed context for agents then we have managed AI models. That's a shift. And then the end goal for me is context management which is the end goal with all of this. It actually it it use all of this use all of this but it's the end goal right for for for this. So I think I'm on time still have five minutes but there was a lot of things again there was a lot of things and again for me these are all uh let's say knife uh knife hit in API management practice as we know it for me to say that it will disappear right so will API management disappear I think yes it will disappear but the question is that API management is is API management that. So we checked in the tube stone. We checked on the G and there was nothing inside. There were nothing inside. Yes, it disappeared but maybe not dead. So maybe not dead. And and I just want to use a metaphor to finish about all what's going on, right? Is that I think API management will disappear like sugar disappears in the tea. You know so when you put sugar in hot tea or even cold disappear but now it lives everywhere you know it's actually everywhere the mindset of management authentication authorization rate limiting is there we just have to apply it to something else to models to tokens to context to whatever but it's still there it's still the same practice the mindset of the practice but just new way right you know so I think that's the same it's like a riding a horse or driving a car it's still moving you know you have you steer you give food or or gas or whatever but it's the same mindset right so yeah sugar and the tea lives everywhere and every drop every sip every spoon and actually reveal the taste but I have found another metaphor by a Persian poet called Roomie and another Middle East poet who khal jibran I don't know if you know if you know him um but uh so he said that actually maybe if I didn't say that about management but I use a metaphor that maybe API management will disappear like the river disappear into the sea, right? So that's his end goal. The goal of the river was to disappear in the sea, right? That was the end goal. It was there to do a path. But when something bigger was coming is just to was just to be diluted and and and there right so I will just finish by this poem right uh by Khalbran called the river cannot go back. So I I really I will read it out loud. So it is said that before entering the sea, a river trembles with fear. She looks back at the path she has traveled from the peaks of the mountains, the long winding roads crossing forests and villages. In front of her, she sees an oceanian so vast that to enter there seem nothing more than to disappear forever. You see the metaphor with life, right? But there is no other way. There is no other way. The river cannot go back. Nobody can go back. to go back is impossible in existence. The river needs to take the risk of entering the ocean because only when will fear disappear. Yeah. Because that's where the river will know it's not about disappearing into the ocean but of becoming the ocean. So API management this is what I think will disappear but to become something else that I call context management. So it still be there your practice is still there just have to think differently. Thank you very much. >> [applause] >> Yeah, I can answer some questions. >> Any questions? >> Thank you so much, Mi, for this talk and I think this is probably the first funeral I'm walking away excited and happy from. So, thanks for the stellar job that you did there. loved the notion of you know uh microcontext API AI gateways agent experience specifically the question I wanted to ask is in the space of AI gateways especially in the open source realm do you see anything interesting coming coming up which we should keep an eye on >> interesting companies or features >> AI gateways yeah >> yeah any new startups or any new you know open source >> so AI gateways again uh what do you call an AI gateway does an API gateway with AI manage >> features not Okay, so pure standalone gateway. >> So there are few ones. There is a pure pure LLM gateways that are actually too much LLM like LLM light or stuff like that. But two that I again um I'm sponsored by everyone so I can say whatever I want but no uh the the there's port key port key that has the idea of a full standalone um AI gateway you know so port and it's open source okay right uh and then I didn't check but the the kong split for the AI gateway I don't know yet how much they keep up open source how much is what's enterprise whatever but at least I would they've been really good on that It's really well adopted. I would I would check but I didn't check this one. Port key I would recommend. >> Again I would recommend others but you asked me the question. So >> thank you. >> Thanks VI. Uh just on the same context we are working with uh True Foundry. >> True Foundry. Okay. >> It's pure play of AI gateway and we keep the uh old API gateway intact. Yeah. So that one maybe you can >> port key true foundry and we need a third one uh you know to I don't know in India but in France we're not allowed to do publicity I we have to at least give three names so I need to find a third name so I said kong so >> yesterday >> standway >> yeah but I think it's still part of their API Sorry there >> very delighted talk like yesterday it was so great so just want to add not a question about that river sentiment so we have in office quoting Thomas Edison saying that river is not one by its speed but it's a relentless pursuit of forwardl looking so river becoming a ocean and our journey is uh expanding further. Huh. I think you gave a very good message. >> Yeah. So that's it. So there is also another message that I wanted to try but uh let's say in the it's a globe but people call it the west. You know the west we believe there is an end because there's a beginning and in more middle east or you know east Southeast Asia we believe there is a beginning because there was an end before right you know so you know let me think. Thank you m as nar said you have mixed of philosophy concepts technology everything together which is really super worked out very well. So my question is around the how the security needs to be evolved like what's the role of security in this transition. >> It's funny because I removed the three slides on security this morning because I didn't thought I would have the time to to to make it happen. No again security is is one of the arguments to say that API management is obsolete the way we know it because the security is completely different. you know the prompt injection you know hallucination is kind of a part I consider part of security in a sense that it can do harm to the user so I consider a part of a of governance and and security yeah it's a it's a new world and API management companies actually you know where they were not ready with so many the gateway it was not enough for many let's say attacks you know bola attacks you know or other type of business logic attacks or whatever the API gateways were not ready so even on API the gateways they were not ready for more complex attacks with LLM it's even a new realm so yeah it has to be something totally different it has to be the ocean and not the river right you know so so yeah but uh the the attack surface is completely different and most of API management companies are they're learning like everyone but they're their previous tools and gateways are not are not ready for that >> all right thanks a lot thank you mi for the wonderful >> [snorts]