AI and the state of APIs in 2026 | apidays India 2026

I'm Shrea a Gartner analyst with a focus coverage on integration APIs and the impact that AI is having on those domains. Over the last couple of years, I have had the opportunity to speak with close to about a thousand end user organizations. And a key theme that has become apparent to me is that organizations are obviously very excited about Agentic AI, but they're equally confused by it. They've obviously heard bold claims of agents transforming enterprises and they're putting forth some key fundamental questions. Do agents make applications less relevant? Do they replace integration platforms and APIs? Do APIs still even matter? So today I've put together this session to try and separate the hype from the reality and discuss the state of APIs in 2026 and more importantly also discuss where Gentic AI is making an impact and how should your strategy evolve in respect to that. So let's start off perhaps with an analogy here that kind of captures the misunderstanding that I see in this space. So imagine you walk into a restaurant. The owner comes up to you and says that we've gotten rid of all our service stuff with AI. Now you would probably think that's pretty impressive and pretty cool. But then the owner continues and says that we got rid of the kitchen as well. Now that is where the conversation turns a little bit absurd and funny because nobody actually goes to a restaurant because of the service stuff. The kitchen is actually where the value is created and the service stuff is just an interface to access that particular value. So that kind of captures the misunderstandings that I often hear around agentic AI as well that people are so focused on what it replaces and what it does not that they often forget that agents are not the business capability yet. They are the interface to the business capability and the kitchen still needs to exist and in an enterprise setting that kitchen is going to be your ERP, your CRM platforms, your data platforms, your business services, your operational workflows and APIs would remain a crucial mechanism to access all of that. And you don't have to just take my word for it because the market is kind of reflecting the same pattern because if you look at some of the statistics that we have, according to Gartner's software engineering survey, 95% of organizations stated that they still rely on API design and development skills to meet their current business goals. And commercial adoption isn't slowing down either because the API management software market is slated to reach a predicted value of 4.8 8 billion US in 2026 with a compounded annual growth rate of 10.2% predicted through 2029. So that does not seem to me like a market in decline. It still remains a foundational capability, but it is a market that's preparing for a new type of consumer. So that's what brings me to the three key issues that I want to discuss today. Are API still relevant? We've already established some of that, but I'd like to look at that a little bit more closely. what do some of these emerging agent communication protocols like MCP and A2A actually change? And the third that's probably the most important is how should your API strategy evolve in respect to Gent AI. So let's take a look at the first one because it's the main executive concern that I see coming through. Now whenever a major technological shift occurs, somebody somewhere will always predict the death of technologies that came before it. and APIs are probably no different in that regard as well. So that is why it's important to understand the relationship of APIs and AI perhaps through two different lenses. The first one is APIs built using AI and the second one perhaps the more transformative trend is APIs being consumed by AI. Now we'll look at them both closely but let's start off with the first one APIs built with AI. So if you're a software engineering leader, an IT leader or a product leader that's leading teams or teams of teams, I think productivity boost is probably at the top of your mind for your engineers. And that's where what we're seeing is from a core software engineering perspective, there are three types of tools that are coming through that are accelerating how you create, design, test, document your APIs at this point in time. The first one that we see coming through are VIP coding platforms or also known as application generation platforms. Not everyone likes the term wipe coding. We're not necessarily endorsing it. Um, but these are tools like lovable, bold. This is where you just describe the intent in terms of what application you want to build and they can build out some simpler software applications pretty fast. The second type of tools are AI coding assistants, right? These basically are integrated or embedded within the ID that you work with, but they bring the chatbased experience a little bit more closer to the development workflow for generating, modifying, or explaining code. But this category is being outpaced by a new category which is AI coding agents. Now these are tools like plot code, openAI codeex, cursor. Gartner has recently published a magic quadrant and critical capabilities on this. We have the author in the room as well. So this is a very fastmoving uh market at this point in time. But these can execute complex development workflows with greater autonomy at this point in time. But the key thing to understand is you're not necessarily prompting these tools to create an API. You're probably prompting them to create a software. And APIs are generated as a byproduct of that because APIs are embedded in the architecture to make the application more responsive, more composable, and easier to integrate with other frameworks frameworks like React and others. So the key takeaway is that regardless of which approach you use, all of these tools are actually accelerating API creation and the amount of interface that you will have to manage after this. Now coming to the second trend here, which is API consumed by AI. So over the last couple of years, we've all been in the insight era of AI where AI was primarily used to generate text documentation, summarize documentations, draft emails, give recommendations. But now we're quickly moving into the action era of AI. This is where AI just stops being an adviser. It starts doing some tasks. And to do some tasks, it's going to need some tools. Now, in regard to tools, surprise, surprise, your APIs are going to have to become those tools at the end of the day. So without APIs, AI can be a very intelligent advisor, but with APIs, it can be become an operator. Now this brings me perhaps to the most important prediction that we have in this presentation which is by 2029 30% of all AI usage will come from AI agents. This is up from roughly 1% today. So that is definitely a dramatic shift. Some of you may say that that's a very low ball number and I would try and agree with you but you still have to take into account that we still have a lot of mobile apps out there, a lot of pre-built software out there that depends on consumption of API. So those aren't going away and obviously a lot of the newer software that's going to be coming through is going to be agentic in nature and that's going to comprise of the percentage that you see on the screen. But I'd be very happy to break this barrier because we are seeing other trends come through. Uh next trend that we also see coming through that's driving up API consumption from AI is headless. Right now headless isn't something new. It has been around in terms of headless search and headless commerce for ages. But now agents are driving this trend very upward. Right? And as you can see there are big platform enders like Salesforce and service now that are also endorsing this trend. But the premise is simple right? You expose the platform via APIs and MCP. So the agents can use the capabilities directly through those services. Right? Now let's take a look at headless for a minute here. So if you look at the traditional base layers, right? You obviously have your systems of record at the bottom. You have systems of engagement at the top. The systems of engagement are where essentially you have a UI that is where humans, employees, consumers engage with the UI to perform some tasks and execute actions. But now if you introduce agents into the mix this so the traditional user interface kind of changes right it becomes more conversational in nature and the application that had the interface gets relegated to a backend system that becomes the SAS application as just another backend system but you still need some kind of an interoperability mechanism. So that is where you have your APIs, MCP, CLI, tools, skills, all these bits coming through. But your context layer would still be very important because this is the secret source of your organization. Your policies, your approval workflows, um your guardrails coming through. And there's a big battle right now that's going on on the context layer where the SAS applications don't want to just become another system of record. So they're trying to kind of build as many capabilities there. While the agent platforms themselves are also building context management capabilities, right, to try and dominate the space. But whoever wins this race, APIs would remain that connective tissue. So they aren't going away. So think of headless is just another way of saying API first. Now there's a practical reality that we are faced with right now, right? most app like we would anticipate that most applications the rich functionality that you see on the user interface is also exposed through APIs but that's not the case because that's why technologies like RPA and browser automation have long survived and now we have an AI equivalent of this which is called as computer use so think about a scenario where I trigger an agent to go and fetch me some stock price information right so it kicks off if it finds an API it'll probably get that information pretty quick But if it doesn't find an API, it'll probably scrape something like Yahoo Finance and give me that information. So computer use actually works, right? But it's highly inefficient. There have been reports of it consuming 45 times the amount of tokens that it would have taken a structured API call to get that information. So APIs are always questioned and always questioned that they would probably meet their doom and that is mostly because of poorly designed APIs or non-existent APIs for functionalities that computer use and RPA try and fail. Right? So because this is 2026 if you're not APIs are not designed for agents in mind they are going to get bypassed and computer use type technologies are going to take over. So that brings me to what the evolution in your API strategy should be. That essentially means that you have to move from developer experience to agent experience. Now everyone's heard the term just like you would want your developers to find, consume, test your APIs, you would want the agents to do that. But not everyone actually implements it in that particular regard. So I'm proposing a few very high level steps, right? Obviously you need to be very diligent. But the way that this would work is the first thing you want to ensure is that you have discoverable documentation, machine readable specifications, right, with as much context as possible. Second thing is ease of access. So if I'm an agent looking for some information, right, and I stumble upon your API and to get access to your API, I first need to go through a sales channel, schedule a meeting, then get an API key. I'm probably bypassing that for sure, right? So what we're seeing is organizations are setting up sandbox environments where you don't need production keys to be able to kind of get that level of information. So think about how do you make it as easy to access an API if you were trying to make the agent the consumer. The third one is MCP support. Now it doesn't mean just stick a facade of MCP in front of your API. What it essentially means is you have to think about permissions, scoping, tooling, composition, all the necessary things just to build a very effective MCP server, right? So you have to provide comprehensive support and MCP kind of a mention of it here is a good segue into our next section which is what do agent communication protocols actually change. So if you look at the logical anatomy of an AI agent, right, it needs a goal. It needs to integrate with an LLM. It requires some memory capabilities short-term, long-term. It needs to have access to tools, but uh it also needs some embedded orchestration to orchestrate against an LLM, the tools as well as the memory. Now, since we're at an APIs conference, I will show some bias and say that tools are perhaps the most important component here. And that's where MCP is essentially playing a big part at this point in time as a standardized mechanism to integrate agents with its resources in the environment. Now without MCP you're obviously going to have to build a lot of these custom agent to tool interactions have that classic M&M problem and MCP is obviously um sorting that out but it doesn't really replace APIs. It's a complimentary mechanism in most scenarios. What I see coming through across organizations is that it's actually helping agents discover and use APIs more effectively. But access to resources is only half the problem. What we also see coming through is if your ambition is to build multi- aent systems whereby you need agents to interact with other agents. That's where A2A as a protocol is coming through at this point in time. Right now bear in mind both of these are complimentary plat protocols at this point in time. But MCP and A2A are protocols in a very long list at this point in time. We at Gartner kind of dissect this in two ways. One is context oriented, one is inter agent oriented. There are obviously other protocols. There's bunch of other protocols that are not listed here on the screen, but this is a fastmoving space at this point in time. But what I can bring to you is from my conversations in those thousand end user organizations that I've spoken to, it's mostly the context oriented stuff that people are focusing on at this point in time trying to get agents integrated with their ecosystem and that's why MCP is playing a big part and the hype behind it is rightly justified. Now there are obviously other protocols like UDCP coming through. I don't see any client interest adoption whatsoever at this point in time. Some vendors also position Arabzo. But the other space that you look at which is inter agent oriented that's even a funnier space at this point in time because obviously A2A is backed by most of the vendors right in the room as well as maybe on the shop floor. But what we're noticing is there's a bunch of other protocols two types of ACP NANDA coming through but none of them have any meaningful production adoption at this point in time. So these are just interesting protocols. So you'd absolutely have to keep tabs on this space and what gets adopted as the foundational protocol. But in my opinion, the reason for that is nobody's actually operating agents at a distributed scale through diversified stacks that they need to interoperate with each other. Right? Now this brings me to how does APIs actually intersect with this space right of communication protocols. A lot of organizations ask me okay should we reinvent the stack? Should we build an entirely new architecture? Now, my argument to them is that you built an API infrastructure for about a decade or more or less depending on when you started and you've built well- tested, well-governed and wellsecured APIs. So, rather than reinventing the stack, what you should essentially try and do is augment the capabilities that you have present so that you can try and force some of the agent traffic through that. So essentially what you want to do is build extend your API ecosystem to become an AI toolkit. Now the lowest hanging fruit in that case is going to be obviously try and build an MCP bridge on top of your existing APIs, right? Just because it can act as a translation layer. But the way that that would essentially work is that you would have some kind of an agent coming through with an intent, right? So suppose I send that intent saying update a customer record for me, right? So the agent would reach out to the MCP servers it has access to at design time and once it kind of does that it gets the context on what tools it can call. So once it decides okay this is the API tool that I want to call it gets routed through an API gateway hits the backend call. The API gateway does what it does best which is essentially security traffic management routing and the backend only sees a govern API call coming through. So essentially you want to be forcing your existing agent traffic through your existing enterprise controls is the main premise. But now it may seem rosy, right? Let's adopt MCP servers. But with any new protocol, any new interface management capability coming through, there's going to be a bunch of governance challenges, right? And we're already starting to see some of these come through. So these are mostly associated with governance challenges if you do it in an unmanaged fashion. So the four bucket of categories that I see emerging is first is obviously the control plane risks. This is not having a universal policy enforcement or an overarching governance layer that can basically help with policy enforcement. The second part is operating model gaps. Just like APIs, MCP servers would require some kind of ownership, accountability, and life cycle management. Without that, you're basically going to have a lot of resistance in your ecosystem. Design execution risks are very much about poorly designed MCP servers. And we see sometimes cost escalating to about 60 to 70% of the time, right? if you just build very bad MCP servers. The fourth one is portfolio ecosystem risks. Too many MCP servers without any governance is going to lead to some kind of sprawl. But then again, can you also justify the business value of the MCP servers that you're building? That's often something that nobody tends to focus on and it's something that I would recommend doing because everything is going to be attributed to token cost eventually. So because of the governance risks we outlined, I think this brings up the right the last section pretty neatly is how should your strategy evolve. In my opinion, the API strategy right now is going to be all about governance. So now if you look at some of the existing reference architecture from a technological perspective, this reference architecture is very much about human clients coming through and using your API. So nothing unfamiliar. You have an API gateway, you have your control plane, your portals and some micro gateways coming through. But now this is getting augmented by a lot of organizations to try and account for machine identities and machine consumers coming through. And this is where you will see the concept of AI gateways taking a hold in the market. So AI gateways are a new type of technology that are essentially coming through to interact to attribute for the interaction pattern. So for example, if I'm an agent, I need to call out to a tool. That's one interaction pattern. If I'm an agent, I need to call out to an LLM. That's one interaction pattern. And if I'm an agent calling out to another agent, that's the third interaction pattern. So AI gateways are essentially coming through to mediate and observe all those three interaction patterns at this point in time. But there's a lot of confusing techn terminologies out there. Some would call it LLM gateway, model gateway, MCP gateway. You obviously have API gateways. But think of all of these as a feature of an umbrella term called as AI gateway. And you don't necessarily need best of breed for each of these capabilities. A single vendor approach would work appropriately as well, right? But as I said, you want to be investing in these capabilities. The AI gateway banner could cover API gateway although that's an op optional element but LLM gateway, MCP gateway and agent [music] gateway for the three interaction paths that we talked about are going to be essential as part of your strategy. So coming to the next slide right because the we would try and discuss some of the vendor landscape here. So for example MCP gave are probably the more emerging trend at this point in time. Now there are different vendor categories at this point in time. Some of these vendors are obviously here on the conference as well. So if you look at the topmost segment of this you have vendors like gravity, Google, Kong, IBM, Solo, Microsoft. Now these are vendors very much from the API management stack that have extended their capabilities to also provide an MCP and an AI gateway essentially. Then you have vendors like True Foundry and area. Now these are AI development platforms with an embedded AI gateway capability but they're broader than just gateway itself right then you have vendors like portkey light LLM very pure play vendors purpose-built for the AI gateway space but there are obviously emerging standards around the registry which we do have an official MCP registry out as well our recommendation is don't try and use anything from there at this point in time you still want to have an internal MCP registry of your own and that MCP registry is generally often very tightly integrated ated with the gateway offering that you have right the A2A space is very much nent I would say not as much movement as you must see in the LLM and the MCP space at this point in time there are obviously some vendors that are going to be overlapping with the category that we discussed previously as well but obviously not a registry standard as of now around this most of this is going to be dictated by the primitives that the gateway platform can handle from your end right but now this is very much about the technology You also want to think about leveling up your enterprise API standards because governance is not only a technological problem. It's an operating model problem. So the things you want to take into account are obviously bringing discovery to the forefront cataloging semantic descriptions. Um ensuring that you account for new types of identities coming through agents right want to use oath beha on behalf of tokens but machine identities are going to be important to consider. Then you want to have as much context from a payload and error perspective as well because that's going to determine a lot of the interactions that go back and forth. And last but not the least, this is going to be perhaps the most important aspect of this is dynamic cost aware throttling. Now a lot of the capabilities around gateways are also being labeled as token management and cost management. So because everything boils down to how much tokens it takes for the LLM to get a response out, it would be very important for you to use these gateway controls to limit people from actually burning as many tokens as possible. Right? You don't want to be token maxing all the time unless there's actually an ROI that you can attribute to it. Now my second last slide over this before I provide some recommendations is perhaps the biggest challenge that I'm seeing coming through at this point in time. It's about discovery. And discovery can have two different meanings. One is essentially you want to house all your APIs, MCP agents in one place so other agents can discover it. But the bigger challenge that I'm anticipating right now and already seeing in organizations is that they don't have an existing inventory of what's what is going on in their ecosystem, right? For example, they don't know what APIs are running free. They have a lot of shadow AI usage that's happening. people have built agents that are integrating directly with LLMs and other MCP servers. So I feel the discovery challenge is going to become even larger and you have to be as much proactive about this as as and when you start this particular journey right so think about how will you catalog your MCPs your agents your LLMs provide that golden path for discovery for people to happen to to know which things to consume but then you also want to think about security and endpoint management practices to try and prevent shadow AI as much as possible. So now wrapping this up, I would just leave you with three recommendations that kind of synthesize the insights that we covered here. First of all, try and treat your APIs as strategic capabilities for AI. These will remain foundational for the future. This is what your agents are going to consume and take action on. The second thing is move from developer experience. Don't move from there. I mean optimize that, but also try and think about agent experience at this point in time as well. So make your APIs discoverable. MCP compatible, machine readable because it's the year of agents. The third last one, and that's going to be all about governance. You've heard about API governance for years now. Now is the time to invest in it if you haven't done it already, and you want to be extending that to agent governance as much as possible. And what that essentially means is you want to extend the principles and practices that you learned as part of API management, evolve and extend them now to apply them to MCP servers, agents, skills, tools, whatever primitives are right now being uh floated around. So that was the last slide. Thank you so much for taking the time to attend this session. Hopefully I've given you an answer and [applause] uh hopefully you have a great conference ahead >> as a futuristic outlook of the agentic solution. Um what is your take on human in the loop and on the loop? Do you still see that there will be a need for a human governance somewhere or is is the agentic is going to overtake that aspect as well? I would say for the entirety of you know what we're seeing right now I think there's definitely going to be a need for human in the loop because the tool sets aren't as accurate at this point in time to just do anything autonomously. It would take a while before the technologies evolve to a point where we can trust them a little bit more but that's like a four to five year outlook from here on I would say. >> Thank you. >> Any other questions? Hello. >> Yeah. >> Yeah. Sorry. >> So, uh right now we have many uh SDKs, right? Open AI and open source like lang chain, langra, deep agent, create agent, many things are there. So, what is the trend how people are embracing uh you know agentic flows through those SDKs and APIs? >> So, it depends right. I think people are using all sorts of technologies at this point in time. It's not a single vendor approach or a single framework approach that people are taking, right? You just need to be mindful about tailoring [music] the technology to the skill set of the people, right? They're going to be people that are going to need low code, no code ways of building this stuff out. They're going to be people that's going to need pro code ways of building this stuff out. So, we're not necessarily seeing organizations centralized on a single stack. It's going to be distributed stacks depending on the type of people. But what you want to be ensuring is the orchestration and the governance layer needs to be centralized. That's going to be either your agent gateway or your MCP gateway. So try and harmonize some of the assets that you can centralize upon but distribute where you need to distribute because of skills. >> Thank you. >> Yeah. Yeah. >> Sorry, I can't. >> Is it web scraping that you're referring to? >> Yeah, it's like screen scraping essentially. Yeah, it can be. What do you meant when you said computer? >> So computer used there's also category of computer use agents coming through which can basically basically take over your computer and treat it as like a capability that it can work on in itself. Right. But it is an alternative to like screen scraping web scraping but it's the same exact concept. >> Exactly. It's the same exact concept. >> Yeah. >> Yeah. Yeah. I mean there's a link to that I'll share across but yeah it's mostly embedded in the deck. >> [snorts]