Hello, and welcome to API Evangelist Governance, or what I prefer to just simply call guidance. Because that is what governance should be—guidance. This newsletter is finding new life and has a evolving voice as part of work building my new startup Naftiko. This newsletter is crafted alongside the weekly Naftiko Manifest newsletter, but it is also overlapped and intertwined with my Naftiko work, providing a more raw and opinionated view of the work that went into the week, but both newsletters sharing a common goal.

Exploring Available Schema Tools
My team asked me for advice regarding what schema tooling they should be using, and specifically what is available when it comes to visualizing schema, making them more accessible. While there are a lot of schema tools out there, I wanted to find ones that fit into the most common aspects of working with schema. I am interested in the most common uses like editing and validation, but I am also keen to make them more visible when it comes to how they impact engineering and business operations.

Strolling the Specs Frontlines
I am finding the never-ending string of new AI-centered specifications fascinating. Creating a new spec seems to be the thing to do right now—echoing a similar interface explosion around a decade ago. It is how we battle for the bits that matter, compete for mindshare, and extract value when it comes to the relentless march forward of our collective digital experience, and in some cases lead the way. I am spending time playing with each spec that comes along, understand where it fits into the landscape, and consider what the creators motivation might be—I find these frontlines are full of lessons.

MCP Practitioners Learn About API Design
It is fascinating to watch all the MCP practitioners stumble into the reasons why we have been doing API design for over a decade now. I am seeing more stories about the need to have a plan behind the tooling and other building blocks of an MCP server. It reflects the various interpretations I’ve seen within API design, where some prefering to have their complexity at the path, parameter, or body levels, but with MCP design we seem to want to stuff our complexity at the server level. I will have to do some more writing about why this is, and thinking about how this response to this AI moment reflects other API moments like GraphQL, REST, and how we are going to do the accounting for the technical debt we are accruing in this moment as we chase our agentic dreams.

Accounting Before or After AI Transactions
The buzz around agents is pushing companies to move first and leave the accounting to somewhere down the road. MCP and A2A are very transactional in nature. They are task, skill, and tooling oriented. They aren’t resource, relationship, event, or graph oriented as REST, Hypermedia, Event-Driven, and GraphQL are. The AI economy demands transacting now, and accounting later. But this demand is coming up against the topology of the enterprise, and as MCP servers begin to integrate outside teams and domains, they begin to be shaped by the bounded context of our organizations. This is something we addressed with API design as part of domain-driven design ahead of time, but because of the demand AI is placing on enterprise to change, we’ve opted to not plan, and just spend away on the credit card—paying the bill further on down the road.

Agents. It Is All APIs. Nothing Has Changed
I love people waking up to the importance of APIs. I have to work hard not diminish people’s excitement for each wave of “application” of the value in which APIs deliver. People get very attached to each application wave, because it is what they can see, and it is often what they can see because it is what is being invested in. The web (Facebook). The cloud (AWS). The mobile app (Instagram). The device application (Nest). The artificial Intelligence (Wolfram Alpha/Watson). The bots (Twitter/Slack). The single page app (React). The artificial intelligence (ChatGPT). The agents (Anthropic). People get really excited about the value that APIs bring, and the incremental improvements to the API toolbox (Graphs, Events, Cards, Capabilities, Prompts, etc) that come with wave of investment. For me, I see the pipes behind, and I have been advocating for a balance of the machine-readable and human-readable bits ever since 2010.

I Do Not Do Agentic — I Do Interfaces
I keep hypothetically exploring what I would possibly use an agent for. I honestly can’t find a reason. I have CRON jobs that run on a schedule, executing deterministic requests to APIs that I have developed or depend upon. I have Webhooks configured to respond to a variety of events. I have many bookmarklets and email addresses I can send messages to to trigger many different things. I just don’t quite understand why I would want an agent representing what I do. I am happy to provide interfaces for agents, and solicit feedback from people developing and operating agents on what interfaces should do when they are applied as part of artificial intelligence agents. I get why people dream about agents. I get why investors are interested in the promise of agents. I also get why people have FOMO about agents. But, for me, I just do not ever think I would diminish the agency I have by handing over any decisions in the API Evangelist or Kin Lane domains to agents.

Notion Sandbox
One way I am looking to contribute to the agentic conversation is by providing 3rd-party API sandboxes for people developing agents to operate against as they work to do what they want to do. I published my first API sandbox recently, taking the OpenAPI for the Notion API and equipping with all of the examples needed to mock the API using Microcks, and leveraging Bruno as a client for working with the sandboxed API. As part of our Naftiko Signals work, I am looking to provide a rich suite of 3rd-party API sandboxes that enterprises can use to push forward their agentic AI work in a safer space, without leveraging live 3rd-party services. The Notion API sandbox is what I consider a service API sandbox, and I will be working on more domain and capability specific versions.

Baseline OpenAPI Rules For Governance of 3rd-Party APIs
Each of the APIs that I am turning into a sandbox will be governed by a set of API governance rules that I am using to establish a baseline of quality. The difference between this baseline set of OpenAPI rules and what is usually talked about when it comes to API governance, is I am approaching it from the API consumer perspective—where I have a lot less control. The is just a baseline, I am already expanding them based upon the diversity of examples I need to power the sandboxes, and the OpenAPI extensions needed to mock an OpenAPI in Microcks. I am looking to develop a robust set of rules that help me understand how sandbox ready an OpenAPI is, and how agent ready it might be for any single API, but also eventually cross APIs.

Governance Rules as Guardrails in a Strongly Typed Journey
I am always fascinated by how the same people who are TypeScript believers often become advocates against using a schema-driven approach anywhere beyond “the code”. I am a big fan of having a schema for all the words we use to describe what we do. It helps us get on the same page, stay on the same page over time, and help teams move forward more confidently in the same direction. In my work right now now, I am determined to help steer things towards more business alignment, and bring a strongly typed experience to how integrations are powering our businesses—doing for business stakeholders what TypeScript has done for engineering stakeholders.

Spotlight Rules
I am a big fan of what Spectral rules have become, yet they are still often seen as a configuration file for Spectral CLI, which was created by Stoplight, which was recently acquired by SmartBear. However, Spectral rules have been adopted by a number of services and tooling, and even forked by Vacuum to bring a high performance and creative experience to the rules format. I am a big fan of this. I like what Vacuum has done, as well as some of the other service and tooling makers. I want to shine a light on what everyone is doing with the rules format, from editors, to pipelines, to IDE extension. I want to shine a light on this work and encourage more investment in Spectral and Vacuum rules, adding new collective properties, and apply them beyond API design governance—to help shape this investment, I recently launched Spotlight Rules.

Social Networks - Building — Chaos — AI Perception
I was in a call with a bunch of startups on a sales call this week, where the conversation turned to LinkedIn, and the state of AI slop on the social network. Everyone had given up on using LinkedIn for natural posts, because of the AI noise, and perceived AI dominance in the storytelling. Everyone has a lot of anxiety about not just the noise, but the demise and shift in the quality of social networks these days when it comes to getting our message out there. I wouldn’t say I have anxiety about it, but it is definitely a concern. I am actually find it somewhat interesting and challenging to try and make sense of what is happening right now now. I am not sure what works anymore, and I am not convinced my approach or messages cuts through the noise, but I am confident that my personal approach can and will have an impact—just gotta keep up the drumbeat.

"In any given moment we have two options: to step forward into growth or step back into safety." - Abraham Maslow