Simon Griffiths

There is a growing narrative that AI agents, often coupled with things like Model Context Protocol, will replace APIs.

It is easy to see why that idea has taken hold. Agents can discover tools, reason about which one to call, and assemble workflows at runtime. That feels very different from the static integrations we have lived with for years, where one system calls another through a fixed endpoint, with a fixed payload, in a fixed sequence.

But the conclusion does not hold.

Agents do not replace APIs. They depend on them. What they really do is expose how fragile many APIs already are.

The Illusion of Replacement

Model Context Protocol and similar approaches change the control plane. They give agents a way to discover available tools, inspect descriptions, decide what looks relevant, and make calls based on inferred intent.

That is useful. It is also easy to mistake for something bigger than it is.

Underneath the agent-facing description, the work is still being done by the same kinds of things we already understand: HTTP endpoints, structured payloads, authenticated operations, services, data stores, and event streams. The agent may decide what to call dynamically, but the thing being called still has to behave deterministically.

This is the first important distinction. MCP standardises how agents find and call tools. It does not remove the execution layer underneath those tools. If anything, it makes that layer more important, because the caller is now less predictable.

Most APIs Were Never Designed To Be Open

The uncomfortable truth is that many APIs are not really general-purpose interfaces. They are backends for a known application.

That is not an insult. It is how most systems have been built for perfectly understandable reasons. A React front end needs data in a certain shape. A mobile app has a known journey. A partner integration follows a negotiated flow. The API evolves around those consumers, and over time the contract absorbs assumptions that everyone involved understands without needing to write them down.

The caller is known. The sequence is known. The context is shared.

That works well enough when the API is really part of a larger application boundary. It becomes much more brittle when the consumer is an agent that has not inherited the surrounding context.

An agent does not know which endpoint was built only for a particular screen. It does not know that a field is only valid after a previous call has initialised some state. It does not know that an operation is safe only because the front end normally prevents users from reaching it in the wrong sequence. It sees a tool, a name, a description, and a schema. Then it reasons from what has been exposed.

I saw this pattern directly on a modifyCustomer API I once worked with. It had originally been designed as a universal back-end operation: one customer modification surface that could be used by more than one channel. In practice, the contract was gradually shaped around the assumptions of a particular front end. The input model included fields only that front end had access to, and it relied on context that existed in the screen flow rather than in the API itself.

The result was an API that still looked universal from the outside, but could not be safely called from anywhere else. The contract had absorbed the assumptions of its first consumer.

That is where APIs that looked clean suddenly become fragile. Not because they were badly engineered in the narrow sense, but because they were designed inside a relationship of shared assumptions. Agents weaken that relationship.

Open APIs Are A Different Discipline

Designing an API that can be safely used by any caller is different from building an application backend.

The difference is not just documentation. It is the level of explicitness in the contract. A genuinely open API has to carry more of its own meaning. It needs operation names that reflect business intent, not just implementation convenience. It needs payloads that are stable and understandable outside the original client. It needs predictable behaviour, clear failure modes, narrow authority, and minimal reliance on hidden sequence or surrounding UI logic.

In other words, the API has to stand on its own.

That is much closer to building a platform surface than exposing the internal workings of an application. It is harder work, and it is one reason genuinely reusable APIs are rarer than most organisations like to admit.

We have often treated “API” as if it were a transport choice. Put JSON over HTTP, publish a schema, and the system has an API. But the transport was never the hard part. The hard part is whether the interface expresses enough meaning for an unknown consumer to use it correctly.

Agents Move The Burden Onto The Contract

Agents introduce probabilistic orchestration into systems that were mostly designed around deterministic flows.

That matters because the API can no longer rely on the caller behaving in the expected way. A human-written integration usually follows a known path. It was tested against the intended use case. It encodes a set of assumptions made by developers on both sides.

An agent composes at runtime. It may call tools in combinations the API designer did not anticipate. It may infer intent from an incomplete prompt. It may treat two operations as equivalent because their descriptions sound similar. It may be perfectly well intentioned and still be wrong.

When that happens, the burden shifts to the API contract. The contract has to be predictable enough, explicit enough, and narrow enough that misuse is either prevented or fails safely.

This is where common weaknesses become much more visible. Ambiguous names matter more. Overloaded endpoints matter more. Loose schemas matter more. Broad security models matter more. They were always architectural problems, but human developers often compensated for them with judgement, local knowledge, and testing. Agents remove much of that safety net.

What Actually Changes

The shift is not “APIs versus agents”. That is the wrong framing.

The real shift is from static integration to dynamic composition. Instead of a predefined workflow calling a known set of services in a known order, we now have systems where the choice of tool may be made at runtime. The orchestration layer becomes more flexible, but the execution layer still has to do the real work.

That execution layer remains APIs, services, data stores, queues, and event streams. Nothing about agents makes those responsibilities disappear. If anything, agents make the quality of those interfaces more important, because more of the system’s behaviour now depends on whether they can be safely understood and composed.

This is why the replacement narrative is misleading. It focuses attention on the agent framework, when the more important question is whether the systems underneath are fit to be called by something operating without the assumptions of the original application.

The Uncomfortable Conclusion

Agents are not a shortcut around architecture.

They are a forcing function.

They force us to confront weak API design, poorly defined data boundaries, inconsistent contracts, and security assumptions that depended too heavily on a well-behaved caller. They expose the difference between an API that works for a known client and an API that can be safely used as a general capability.

That distinction is going to matter more as agentic systems move from demos into real enterprise environments.

If you are building for an agent-driven world, the priority is not the agent framework. It is the execution layer behind it.

Because agents do not replace APIs. They make it impossible to ignore how good, or bad, those APIs really are.

But even if APIs remain central, the way we design them is starting to break. We have seen that pattern before, and the lesson is older than the current agent wave. It starts with SOA.