It is difficult to think like an API consumer when you are an API producer. When I talk to anyone about what I am building at Naftiko, which is extremely API consumer centric, almost everyone I know stumbles while discussing API design, governance, and other considerations—only seeing things from an API producer mindset. The money is in producing APIs, and the real value is generated consuming APIs. APIs don’t exist until they are consumed, but vendors all sell towards producing APIs, so this in turn drives the conversation out on open waters.
As I work to define what is different when using Naftiko capabilities to design, document, govern, integrate, or any other things you are going to want to download with an API, I am obsessively focused on what is needed to consume APIs. I am kind of over the API lifecycle, API governance, and other leading API producer ideology produced by the markets and the most passionate API champions within enterprises. Don’t get me wrong. Don’t stop doing it. I am happy to talk about the finer pedantic details of producing APIs, but I’m more interested in us just using the APIs we already have in motion effectively. It feels like we don’t need to be creating more until we have a handle on the ones we already produce, but also consume.
A significant portion of the problems we experience with APIs on a daily basis is due to the market heavily focused on an API producer mindset. Learning to think like an API consumer, as well as specially learning to think like your API consumers, is a high value commodity. Doing it reliably over time isn’t easy. Seeing how the APIs you produce fit in with other APIs you don’t own or control is a rare thing to find. Many API producers have integration pages. Few API producers have meaningful workflow and capability pages based upon the most common ways in which their APIs are used with other APIs. This is the important work on the table right now with agents, but if you aren’t able to get out of your defensive API producer mindset and think more about what is needed across service providers and APIs, you are gonna miss a lot.
You can use Notion’s MCP server. You can use Figma’s MCP server. You can deploy your own MCP servers. Until you have a specific business capability, or set of capabilities in mind, I am guessing each of those MCP servers do not reflect what you need, and only reflect what each producer wants. For me, the questions really haven’t changed around why we need programmatic interfaces. The power is shifting from an API producer mindset to an API consumer mindset, which breaks us free from the boundaries of a single API producer and is something that reflects what we need across an API. This why Notion’s and Figma’s MCP or API will only get you so far, until you define exactly what resources, functions, tools, and context you will need to do what actually matters. I’m less excited about agents, than I am what the agentic conversation is doing to where power as accumulated over the years, and changing the perspective while also flatting boundaries in between the APIs we are using.
Possessing an interoperability mindset across the consumption of APIs is the definition of what agents possess. Agents consume. Agents default to the same boundaries you put around the public or partner APIs you produce. I am not advocating for agents. I am advocating for an API consumer interoperability mindset. Agents are just automation to me. The game hasn’t changed, just the scope and priorities have. I am guessing they will continue changing. Regardless, a lot of my API producer vocabulary has been failing since my Postman days, and I am seeing it continue to become lower on the priority list as I hustle and sell interfaces in an AI-charged market. I’ve long thought as an API consumer, cause it is primarily what I am. It’s just producing APIs was where the money was at if I was doing the startup hustle. But ultimately, I think the real value moving forward will be aligning the sprawl with business, and stop thinking just in terms of APIs, let along producing or consuming, and let many different services fade into the background as a prioritize business outcomes using Naftiko Capabilities.
