Your AI strategy is built on layers of API sediment

The API landscape is a mess

“The API landscape is a mess, and very few people understand it,” says API industry veteran Kin Lane. He argues that organizations don't replace old integration standards but accumulate them over time, creating a costly, risky layer of “API sediment.”

Lane, the founder of Naftiko, says he regularly hears from enterprise veterans who must manage decades of overlapping specs. “We still have EDI and WSDLs, a lot of Swagger and OpenAPI. We’re trying to do more Async API. MCP is popping up, and we’re looking at Agent Skills, but we have a global business to run, and it’s got to be stable.”

The evolution of competing standards

Lane sees competing standards as a consequence of vendor “land grabs,” where companies use specs to exert influence. The standards also reflect the architectural needs of their eras.

Web Services Description Language (WSDL) emerged from the Enterprise SOA movement of the 2000s. It was a verbose, XML-based contract language governed by the W3C but heavily influenced by IBM, Microsoft, and Oracle.

In the 2010s, REST APIs displaced SOAP, leading to lighter-weight specifications:

• Swagger, created by Tony Tam for his startup Wordnik, became the dominant standard. It balanced machine-readability for tooling with human-readability for docs. It was later moved to the Linux Foundation and renamed OpenAPI.
• API Blueprint, from Apiary, championed Markdown-based readability. After Oracle acquired Apiary in 2017, development switched to maintenance mode and community interest waned.
• RAML (RESTful API Modeling Language), backed by MuleSoft, emphasized modularity for large enterprises. “I think RAML is a better spec than Swagger,” Lane said, “but the MuleSoft people behaved so badly to others in the community that no one wanted to use it.”

As asynchronous patterns like event-driven architecture gained popularity, OpenAPI’s request-response model no longer fit. AsyncAPI emerged as a sister spec under the Linux Foundation, adapting OpenAPI’s structure for pub/sub and streaming patterns.

The cloud and AI create new fractures

A new shift came with protocol-agnostic modeling languages from cloud giants. Smithy (AWS) and TypeSpec (Microsoft) model services abstractly, then generate code or specs for various protocols.

Both are open source but lack truly open governance. AWS drives Smithy’s roadmap based on its internal needs. TypeSpec recently moved to a Linux Foundation working group, but Microsoft remains the dominant contributor. They are optimized for the problems AWS and Azure face, not necessarily for all enterprises.

These specs assume developers consume APIs through generated code. They are not built for the autonomous agents that LLM vendors are now targeting, leading to a new wave of AI-focused standards:

• MCP (Model Context Protocol), championed by Anthropic, defines how AI models discover and invoke tools. It focuses on what an API does for an agent and has seen rapid adoption alongside criticism over security risks and context window bloat.
• A2A (Agent-to-Agent), introduced by Google in April 2025, is an open protocol designed for interoperability between AI agents from different providers.
• Agent Skills, from Anthropic, packages capabilities with semantic descriptions optimized for LLM comprehension.

“Both MCP and A2A are very transactional, exciting, and in this moment,” Lane said. “They are also likely to give away all your value and data if you are not careful.”

The dangerous governance gap

The core challenge is bridging tactical team needs with enterprise-wide strategy and governance. Lane recalls seeing this at Postman with clients like John Deere, who struggled to reconcile decentralized Postman collections with centrally managed SOAP, OpenAPI, and AsyncAPI specs.

The API economy was built on treating APIs as products—with rate limits, usage tracking, and governance. “MCP, however, wants to circumvent all of that,” Lane said. “It wants direct access to your data and files... letting the agents have it without much accounting or governance.”

This poses a severe data governance risk. LLMs with broad access can surface and share sensitive information across departments in ways that violate intended controls. Nicoletta Curtis highlighted this in an interview, noting discoveries of “documents that were overshared or with open permissions” in basic systems like OneDrive and SharePoint.

Organizations often underestimate either the risk of data exposure or the operational burden of mitigation. Retroactively tightening permissions in legacy environments often breaks existing workflows, causing friction and resistance.

Mapping your way out of the mess

In a prior article, Lane described establishing API governance at Bloomberg. The process involved a methodical, business-outcome-first approach:

• Mapping the existing landscape by crawling internal sources for all API evidence.
• Standardizing everything to a single version of OpenAPI to get a complete account.
• Identifying team boundaries, domains, and ownership across business lines.

This foundation of comprehensive mapping and governance with established standards like OpenAPI is the best path for compliance and security. For newer or smaller organizations, Lane suggests it may be possible to skip the “baggage” and start with newer approaches like Agent Skills or MCP.

The critical takeaway is to resist a technology-first approach. The goal isn’t to adopt the newest spec, but to understand the business outcomes and the layers of sediment you’re building upon—or risk an agentic AI disaster.