Introduction
I attended apidays India 2026, held in Bengaluru, India (Conrad Bengaluru) from August 19 to 21, 2026. The reason I went traces back to a conversation with Claude about NASEBANAL's future business direction — specifically, an agent-driven approach to supporting in-house app development. That conversation touched on Specmatic, the open-source tool behind Contract-Driven Development, something I've written about on this blog before, and its Founder & CEO Naresh Jain was also organizing this event — a good occasion, I figured, to go and meet him in person.
apidays is a global event series, and this was its second year running in India. This year's theme was set as "Powering Humans and Agents Alike."
Below, I'll walk through what the event was like and what I took away from the sessions I attended.
What apidays India 2026 Was Like
The venue was Bangalore (officially Bengaluru), the capital of the southern Indian state of Karnataka. It's known as "the Silicon Valley of India" thanks to its dense concentration of domestic and international IT companies and deep-tech startups. For me, Bangalore has always been tied to Thomas Friedman's *The World Is Flat* (2005), a book that shaped my own career, and — being a big fan of curry — I'd been looking forward to this first visit for a long time.
The event was sponsored by companies deeply invested in APIs — Postman, IBM, Specmatic, Akamai, and Kong — and drew more than 1,000 attendees, with 88 speakers from 11 countries.
It seemed unusual for a Japanese visitor to show up at an event like this, and a lot of people came up to talk to me in a genuinely friendly way — it was clear they held a positive impression of Japan, which was a nice surprise. At the same time, the speakers spanned every age and background, and the positive energy from both presenters and the audience was itself something I found energizing.
Below are the sessions that stood out to me most.
"AI and the state of APIs in 2026" (Shrey Pasricha)
I'll start with this one, since Gartner's research on the state of AI and APIs offered comprehensive coverage of where the current landscape — and the conversation around it — stands.
The talk opened with a point worth noting: while AI adoption draws most of the attention, the API-related business is also clearly expanding — according to Gartner's research, the API management software market is projected to grow roughly 10.2% year over year from 2024 through 2029. This aligns with what I heard at KubeCon: an agent should handle the probabilistic part of a task, while the actual action should be carried out by a deterministic API, acting as the agent's hands and feet — and demand for that kind of deterministic API isn't going to shrink just because agents become more widespread. I agree with that view.
The talk also listed the AI tools currently in use for API development in 2026. Several sessions independently touched on the same topic — API discoverability from an agent-experience angle: how should an agent recognize and correctly call an available API going forward? Given that tooling for API catalog management already exists (Kong's Developer Portal, for instance), this may be less a technical problem than a governance one within the organization. At the same time — and as comes up again later in this post — discussion has also started around the Arazzo Specification, a spec for workflows that bundle multiple APIs together, so how to achieve API discoverability for agents may well remain an ongoing topic of discussion.
On the interface side, alongside MCP — which exposes APIs to agents as tools — there was also discussion of agent-to-agent (A2A) communication. Several protocols, A2A among them, were proposed early on, but in practice MCP has become the protocol the market has settled on. I hadn't realized that agent-to-agent protocols had already been proposed and discussed even before MCP was released.
The talk then turned to how API gateways and AI gateways should be structured going forward. Kong, a well-known API gateway vendor, keeps its API gateway and AI gateway management separate, and Gartner's own reference architecture draws the same separation — further splitting the AI gateway into an MCP gateway, an agent gateway, and an LLM gateway. On discoverability, the point I took away was that not all traffic to the MCP gateway necessarily goes to an MCP server — some of it gets routed to ordinary REST-style API services instead.
At the Cast AI session I attended at KubeCon, there was talk of choosing among LLM models on a price-optimized best-mix basis (FinOps), with an LLM gateway to control which engine gets used. That's clearly one axis worth thinking about, but once you frame it as an "AI gateway," it goes further than the LLM gateway alone — the idea that MCP and agent gateways belong in the same conversation was a genuinely new realization for me.
Against that backdrop, the talk noted that a new business layer is emerging: MCP marketplaces built on top of MCP gateways. I hadn't picked up on this movement at all, so it was a real learning moment. Whenever a new protocol like MCP appears, the need for a gateway to normalize traffic grows, and a new market tends to form around it — catching that kind of dynamic early is, I was reminded, exactly what keeps an IT organization competitive.
The talk closed by tying it all together: going forward, it will matter to establish new API standards with AI integration in mind — API discoverability for agents being one example. The whole talk built its argument from context to conclusion in a way that felt very close to the Japanese sense of *kishōtenketsu* narrative structure — a genuinely well-constructed presentation.
"Restoring Trust in AI-Native Development" (Naresh Jain)
Next up: Naresh Jain, Founder & CEO of Specmatic and the reason I made this trip in the first place, who also organized apidays India 2026.
His talk was titled "Restoring Trust in AI-Native Development."
The core argument was built around the Toyota Production System — could the same concepts apply to agent-driven software development? As the mechanism for making that real, he introduced Specmatic-based testing.
In monolithic systems, function-level integration used to be caught at compile time; in a microservices architecture, that loose coupling means consistency issues no longer surface the same way. Contract testing closes that gap by automatically detecting the mismatch — the demo showed exactly that. Running contract tests was framed as the equivalent of *jidoka* (autonomation) in the Toyota Production System.
As a concrete *poka-yoke* (error-proofing) example: specifying a field as a plain string lets an invalid value pass straight through, whereas specifying it as an enum lets the contract test catch the error. Running that contract test automatically is the *jidoka*, and mapping the resulting error to a CI pipeline failure was framed as the *andon* — the visual signal that stops the line.
Finally, Harness Engineering — a framework for safely operating coding agents, drawing on an article by Birgitta Bockeler published on martinfowler.com. Incidentally, quite a few speakers at this event besides Naresh Jain were affiliated with Thoughtworks, and Birgitta Bockeler appears to be one of them as well.
Harness Engineering, as presented here, splits broadly into two categories of action for controlling how an agent behaves: guides (feedforward), and sensors that check the agent's behavior (feedback).
A guides/sensors harness alone isn't enough, he argued next: the fuller picture adds Executable Intent, which turns plain English into an executable spec, and Executable Architecture, built from specs like Arazzo, as its foundation. Applied to API development, that maps to API specs + examples as the guides, and spec-based runtime tests as the sensors — with continuous monitoring of that loop proposed as Continuous Governance, an effective approach whose realization, he noted in closing, Specmatic makes possible.
That way of putting the specification itself — rather than the contract — at the center of guiding and verifying agent behavior is what Naresh calls Spec-Driven API Development with Executable Contracts, and he frames it as where Contract-Driven Development goes next in the agent era.
"Open API Track: Welcome and Open API in the Age of AI" (Erik Wilde)
Next, a session I found genuinely interesting was the Open API Track, organized by Erik Wilde of the OpenAPI Initiative. It opened with an introduction to the Initiative's work. The OpenAPI Spec's predecessor was SmartBear's Swagger, donated to the Linux Foundation's OpenAPI Initiative in 2016, and the spec has been developed as an open standard ever since. Erik Wilde, along with Frank Kilcommins — who presents the Arazzo Specification later in this recap — both work at Jentic while also contributing to the OpenAPI Initiative; spec discussions happen openly on Slack, with the final decisions made by the core members.
The membership slide gave a sense of who's involved: Jentic (where Erik Wilde and Frank Kilcommins work), SmartBear, and a handful of other major companies — though it didn't look like a small set of large vendors keeping a tight grip on the process. There was also an introduction to the various SIGs; the Arazzo Specification discussed later, it turns out, comes out of the Workflow SIG.
The session then walked through pitfalls in how APIs get called from MCP. The first case covers calling an API directly from an LLM or MCP client: relying on the OpenAPI spec alone doesn't carry enough context for an effective call, which is where this connects to the Arazzo Specification discussed later — the spec that formally defines a sequence of API calls as a Workflow.
The second pitfall involves embedding custom code into the MCP layer. This resolves the first problem — a bare API exposed through MCP — and can look like it improves the agent experience. But that approach is what gets called "MCP washing": it splits logic away from the API that's supposed to own the deterministic action, which is bad practice from a service configuration management standpoint. The better path is to implement the logic in the API that actually owns the function, and keep MCP free of heavy logic.
In other words, real "AI readiness" means implementing the API correctly first, then building the mechanisms that extend agent capability and improve agent experience on top of it — and Jentic has published an app that scores exactly that, across six dimensions:
- FC: Foundational Compliance
- DXJ: Developer Experience
- ARAX: AI-Readiness & Agent
- AU: Agent Usability
- SEC: Security
- AID: AI Discoverability
This felt like it was a step ahead of where the market conversation is today.
"Beyond Open API: Workflows That AI Agents Can actually Execute" (Frank Kilcommins)
Also on the Open API Track, Frank Kilcommins — like Erik Wilde, at Jentic — presented "Beyond Open API: Workflows That AI Agents Can actually Execute."
Frank Kilcommins is a co-author of the Arazzo Specification, the OpenAPI Initiative's answer to defining Workflow, and he introduced the characteristics a Workflow needs as follows: in this context, a workflow defines a sequence of API calls, is a declarative implementation, and is characterized by reproducibility.
That "why workflow matters" argument is what the Arazzo Specification, currently being developed within the OpenAPI Initiative, sets out to answer.
It's positioned as a spec meant to serve both human-readable and machine-readable needs at once.
The text on this next slide is probably too small to read, but in short: like the OpenAPI Spec, it's defined in YAML, and it expresses a chain of workflow steps.
Throughout the event, the conversation kept shifting from developer experience to agent experience — and this felt like a concrete answer to "so what do you actually do to improve agent experience?", expressed as a spec. If tooling and services built on the Arazzo Specification catch on, there may well be a growing business around improving agent experience.
Arazzo is also still a relatively young spec, and it's being actively revised. Version 1.0.0 shipped on May 29, 2024, and v1.1.0 followed on May 17, 2026, adding — among other things — AsyncAPI support and specs for chaining workflows together and passing parameters between them.
Broader protocol support is expected going forward. You can find the full detail on the Arazzo Specification at the OpenAPI Initiative's official site.
Closing
Coming away from apidays India, my overall impression was how practical most of the sessions were.
Some of that is probably down to Bengaluru itself — most attendees were either actively building software or managing teams that do, so there wasn't much in the way of generic project case studies. Most sessions instead walked through the background and goals behind a company's own open-source solution, then introduced the solution itself.
The event also included a panel discussion among Indian entrepreneurs — Specmatic's Naresh Jain, Postman co-founder Abhijit Kane, Anoop M D, founder and CTO of Bruno (an open-source API client in the same space as Postman), and Peter Thomas, co-founder and CTO of Karate Labs (which provides unified API, UI, and AI test automation), among other leading Indian founders. Their stories from experience made for a genuinely engaging discussion. Even as an audience member, I could feel the atmosphere of a community pushing and inspiring each other to grow.
And in the keynotes, the mid-to-long-term framing of how APIs need to change in an agent-driven era — agent experience, API discoverability, and how to bridge probabilistic agent behavior back to deterministic, verifiable systems — came up again and again, always with a clear problem-then-solution arc. I came away having learned a great deal.
Every solution I saw also took a spec-first approach, and having members of the OpenAPI Initiative run their own track at the event was genuinely valuable. The thread running from the agent-experience discussion straight into the Arazzo Specification discussion felt smooth and well-earned. (I spent most of my time on the Open API Track, though GraphQL and other tracks were running in parallel.)
I also had the chance to sit down separately with Naresh Jain, Founder & CEO of Specmatic and the organizer of this event, for an interview. That conversation, along with a closer look at Specmatic's technology, will be published as separate posts.
Between apidays India itself and the fresh discoveries I made even on the way to the venue, this turned out to be a genuinely rewarding trip to India. Thank you to Naresh Jain for making this post possible, and to everyone else I met there!
For the record, this is not a work product of the AI agents this event's theme was all about.