I am giving two talks at APIDays NYC this week. On paper they look like two different topics — API governance on Wednesday, OpenAPI examples and tags on Thursday — but they are really one argument from two sides. Governance does not belong on the producer side, hoping every team behaves. It belongs at the consumption layer, where AI agents and copilots are about to become the dominant API consumers, and where the metadata an OpenAPI spec carries (or doesn’t) determines whether that consumption actually works.
If you are at the conference, here is what I will be covering and when.
Talk one — Wednesday, May 13, 10:05 AM, Morgan Forum 1 + 2 + 3
API Governance at the Agent Consumption Layer: Governing 405 Operations Across 36 APIs Without Changing Team Behavior
I have been doing API governance work for fifteen years and I’ll be honest — most of what our industry has built around governance does not work the way we pretend it does. We lint specs in CI pipelines. We write style guides. Then we look at what actually ships, and it’s the same story: teams doing their own thing, acquisitions bringing their own conventions, and the style guide collecting dust in a wiki nobody reads.
For this talk I did an exercise that changed how I think about the problem. I took all 36 of Palo Alto Networks’ public APIs, extracted all 405 operations from their OpenAPI specs, and wrapped each one in a Naftiko capability that enforces a standardized Spectral ruleset. The result was 405 governed MCP tool capabilities presenting a consistent interface on top of APIs that were never designed to be consistent with each other.
What I found across that portfolio is what happens to every large platform that grows through acquisition over fifteen-plus years. Path casing all over the place. timeType vs start_time vs stime for the same concept. Pagination done three different ways. Authentication fragmented across four different patterns. Every large enterprise has this problem.
The traditional answer is to rewrite the APIs. I have watched that movie enough times to know how it ends. It is expensive, it is slow, and it rarely works at scale because the incentives across the producer teams are not aligned.
So we did something different. We analyzed all 36 specs to find the dominant patterns already present — evidence, not opinions. We authored 43 Spectral rules from that analysis. Then we generated capabilities that preserve the original API contracts while exposing a governed MCP tool interface. timeType becomes time_type. /Objects/Addresses becomes /objects/addresses. Pagination normalizes to offset/limit everywhere. The APIs do not change. Governance happens at the consumption layer.
This matters more now than it ever has because AI agents are becoming primary API consumers. When a human developer hits an inconsistent API, they adapt — they read the docs, they figure it out. When an agent hits search_from/search_to in one API and offset/limit in another and nexttoken/maxresults in a third, it struggles. Agents need a standardized interface to work reliably across a portfolio. Consumption-layer governance gives you a uniform, predictable surface that agents can consume without needing to understand the historical quirks of each API behind it.
The bigger argument I will make in the talk: most of API governance has been about governing the engine producers build, when what we actually need to govern is the consumption of those engines by humans, copilots, and agents. The conversation I had at Bloomberg with eight Canadian banks who had come together to lobby for the change I was working to deliver internally was the moment this clicked for me. The consumers were already organizing around what they needed. I left to build Naftiko because that is where the leverage lives.
Talk two — Thursday, May 14, 3:40 PM, Johnson Studio
OpenAPI Examples and Tags Are the Missing Link Between Your APIs and AI Agents
If the Wednesday talk is about what to do at the consumption layer, the Thursday talk is about the upstream metadata that decides whether consumption-layer governance even has anything good to work with.
Your OpenAPI specifications already describe what your APIs can do. The question is whether they describe what those operations mean to the business. With MCP servers and AI agents consuming APIs at scale, the gap between technical API definitions and business-domain understanding is becoming a real problem for context engineering. OpenAPI 3.2’s enhanced tags and the often-overlooked examples object are how you close that gap.
At Naftiko we have been building OpenAPI-first sandboxes for third-party APIs like GitHub, Jira, Notion, and Figma. Each spec is designed around business use cases, not just endpoint coverage. We use the OpenAPI examples object to define realistic, scenario-driven request and response payloads — then deploy them as fully functional mock HTTP APIs and MCP servers using open-source Microcks. The result: AI agents and copilots can explore real business workflows safely, without touching production.
Examples alone are not enough. OpenAPI 3.2 tags bring the business and domain alignment that has been missing. By organizing operations around business capabilities rather than resource paths, tags give AI agents — and the humans configuring them — a shared vocabulary for discovery and intent. I will walk through how we use tags to group operations by domain (project-management, code-review, design-feedback), how this improves MCP tool discovery, and why this matters as AI integration moves from single-API calls to multi-API orchestration.
The headline I want people to walk out with: examples are the mock data, tags are the routing layer, and together they are the metadata that turns an OpenAPI spec from a contract for engineers into a contract for agents.
The through-line
These two talks are deliberately stacked.
The Wednesday talk says: stop trying to govern producers. Govern at the consumption layer where the agent actually lives. Build governed capabilities on top of whatever specs already exist and let the underlying APIs be themselves.
The Thursday talk says: but if the spec is the substrate the capability is built on, then the spec carrying rich examples and meaningful tags is what makes the capability good. A capability built on top of an OpenAPI spec with no examples and no tags is a thin wrapper that hands the agent the same problem in a different shape. Examples make the capability mockable, testable, and safe to explore. Tags make it discoverable by intent instead of path.
Producer-side hygiene plus consumption-side governance is the combination. Neither half works alone.
This is the thesis I keep coming back to as I build Naftiko: API governance does not move enterprises forward by changing the producer side of the equation. It moves them forward when the consumer — the agent, the copilot, the integration team — gets a standardized, governed, business-aligned surface to consume regardless of what the producer shipped. The producer keeps shipping. The consumer keeps consuming. The governance lives in between, where it can actually do its job.
Come find me
Both talks are short — 25 minutes each — and I will be in the hallways the rest of the time. If you work on API governance, build MCP servers, run an agent program, or are wrestling with how to make a portfolio of inconsistent APIs usable by AI agents without rewriting any of them, I want to hear what you are seeing. The 405-operation Palo Alto Networks exercise was one company. I am collecting more.
- Talk one: Wednesday, May 13, 10:05 – 10:30 AM, Morgan Forum 1 + 2 + 3 — API Governance at the Agent Consumption Layer
- Talk two: Thursday, May 14, 3:40 – 4:05 PM, Johnson Studio — OpenAPI Examples and Tags Are the Missing Link Between Your APIs and AI Agents
See you in New York.
