“Web APIs today are broken.” A bold statement made by Microsoft’s Darrel Miller during his talk at the November 2025 A2ASummit. It’s a sentiment shared by many industry leaders.

The interfaces that we see as the glue holding the digital world together have become too brittle to support modern applications, especially those powered by AI. In this article, we’ll examine the core flaw behind the breakdown and several potential solutions to fix it.

Why Are Web APIs Broken?

Miller says that web APIs today are broken due to the tight coupling required to make them work. He further explains during his talk that while the web APIs we currently build enable machine-to-machine communication, clients must have familiarity with the service for it to work.

To instill that familiarity, many API developers use an OpenAPI document. In addition, they must navigate an ecosystem of tooling to help them create API documentation, generate clients, perform linting, and so on, which takes significant work.

“We keep coming up with the next great API technology to try and fix web APIs, but nothing has really hit the spot because nothing has really truly addressed the challenges around tight coupling between the client and the server,” Miller says in the presentation. “And we need better ways to communicate between software systems that can evolve and adapt.”

Chris Hood, author, CX and AI leader and strategist, tells Nordic APIs that Darrel Miller is spot on.

“Rigid, CRUD-centric designs enforce tight coupling, create versioning nightmares, and lead to brittle integrations that can’t keep pace with evolving technology and consumer needs,” Hood explains. While many agree on the symptoms like inconsistent designs, security gaps, poor discoverability, and high maintenance, he says, the interface concept still holds strong. “What’s urgently needed is an evolution of APIs.”

This issue of tight coupling has been around for more than two decades, so why has fixing this problem become more urgent? You can thank AI for that, specifically AI agents.

Traditional Web APIs Weren’t Meant for Autonomous AI Agents

Modern web APIs got their start in the early 2000s, powering early ecommerce sites, such as eBay and Amazon. They were designed for deterministic software systems where outcomes are known, predictable, and repeatable.

Today, we’re seeing the rise of autonomous AI agents powered by large language models (LLMs) that behave probabilistically (non-deterministic) by design. This behavior means that an agent can output different results even if everyone inputs the same prompts. In contrast, many API endpoints are designed to be idempotent, meaning making the same request multiple times should result in the same outcome as making it once.

A key functionality of every AI agent is tool calling — the ability to dynamically access external tools and perform actions using them. Most, if not all, of the tools called by AI agents use APIs to deliver data, services, or perform actions. Autonomous agents also need to understand at runtime the APIs they could consume. That requires the proper context and a mechanism for tool discovery.

Traditional web APIs (with one exception we’ll discuss later) only work when the client already knows the semantics of what the API will return based on the URL. They also don’t provide adequate context for tool calling or a way for agents to discover available tools. Add to that the problem of tight coupling, and you get APIs that fall apart when consumed by autonomous AI agents.

How Do We Fix Broken Web APIs?

While tight coupling is the primary flaw that leads to broken web APIs, the rise of non-deterministic AI applications has uncovered additional gaps. These traditional interfaces weren’t designed for the unpredictability of autonomous agents. Here are several approaches that could solve both problems.

Leverage Media Types Using an AI Protocol

In his presentation, Darrell Miller says the answer lies in looking more closely at how we use LLMs to write code for us. LLMs can translate human language into domain specific languages described by media types, and there are lots of registered media types available.

Developers could use AI protocols to help agents discover which media types are supported. Those same agents would then convert them into a valid machine-readable format. Miller suggests using the Agent2Agent Protocol (A2A) for this capability. However, you could also achieve the same with the Model Context Protocol (MCP).

“The key principle is that these data contracts have been defined independently of any one particular API, so they can be reused across APIs or in our case agents,” explains Miller, adding that one of the key REST principles in Roy Fielding’s original 2001 dissertation is self-description.

“When an API returns a response with a content type like text/calendar, the client has everything it needs to know to process that,” Miller comments. “It doesn’t need a JSON schema to figure out how to do it — and trust me, you’d never be able to describe iCal in a JSON schema.”

Instead of having every API endpoint define its own variant, you create an agreed-upon and reusable definition of domain concepts enabled by media types.

Kin Lane, the API Evangelist and Chief Community Officer (CCO) at Naftiko, tells Nordic APIs that:

“The Web runs on decades of investment in media types. As Darrel Miller suggests, we should be carrying those media types forward into the new specifications powering copilots and agents. But we must balance AI’s non-determinism with deterministic validation of every media type — regardless of format — because that rigor is what will make these systems reliable.”

Adopt an AI-Focused Interface Specification

Another potential solution comes from Chris Hood. He has proposed Agentic API, a specification initiative “focused on evolving APIs for the age of intelligent systems and AI agents.”

This initiative aims to have APIs become task-centric and intent-driven by replacing the outdated CRUD approach with expressive, custom methods that bake context and purpose directly into the operation, enabling richer semantic understanding for both agents and businesses.

Using Agentic API, custom methods would look something like this:

• SUMMARIZE /document
• CHECK /weather
• CHAIN /request

They serve as semantically meaningful alternatives to CRUD, making APIs more expressive and aligned with real-world workflows.

Hood further explains to Nordic APIs that, using this approach, the APIs also:

• Become dynamically discoverable at runtime (via endpoints like DISCOVER /actions).
• Can effectively spin up capabilities on-demand through real-time metadata and adaptive orchestration.
• Extend far beyond the limitations of standard HTTP methods like GET or POST.
• Support cleaner identification of agentic traffic via granular scopes and security models.

“This shift transforms static, fragile endpoints into flexible, resilient, purpose-aligned surfaces that empower AI to execute workflows with clarity, reduce errors, and unlock truly dynamic, context-rich interactions,” says Hood.

Move Towards HATEOAS APIs

Remember hypermedia as the engine of application state (HATEOAS)? That API design style and REST constraint that’s been around for more than two decades? Well, HATEOAS is loosely coupled by design, allowing developers to create self-descriptive APIs with embedded hypermedia links that clients can discover dynamically. Clients don’t have to know all the hardcoded API paths beforehand.

This architectural design style solves the problem of tight coupling. Plus, it helps AI agents overcome the challenges of tool calling, maintaining context, and managing runtime environments. HATEOAS also enables developers to create APIs that can handle the non-deterministic behavior of LLM-powered AI agents.

HATEOAS is a well-established approach that could make web APIs whole again and flexible enough for AI agents. However, developers need to take care in the design of their APIs so that they have some control over what agents can do when accessing its capabilities. This API style is complementary to the approach that leverages media types and protocols like A2A and MCP.

Rethinking API Design for AI Applications

Interfaces remain a critical part of connecting all the components of digital ecosystems together. However, AI is rapidly impacting how modern applications work, making them more non-deterministic and unpredictable. APIs must become more than the “glue” that binds technologies together — they must become an adaptable framework.

Providers need to rethink API design, creating loosely coupled APIs that deliver the context and semantic understanding AI agents require for successful tool calling. They need to ensure that their APIs are understood by human developers and AI consumers alike. Furthermore, providers must adapt their API rate limiting approaches to accommodate the unique traffic patterns of autonomous AI consumers.

On the flip side, developers building AI-driven applications should leverage protocols like A2A and MCP. These protocols can help prevent API tight coupling. In addition, MCP enables agents to better see and access available tools. A2A helps autonomous AI agents communicate and collaborate more efficiently.

With IDC estimating that more than 1.3 billion AI agents will be in operation by 2028, the industry must start preparing for that potential world now. And the first step is finding solutions that make APIs less like rigid dried glue and more like flexible elastomer.