Jurgen Roos | Team Lead | Office of the CTO | Dariel Software | mail me |
Enterprises love to call themselves Application Programming Interface (API)-first. However, almost none are ready for what is about to start calling those APIs.
According to Postman’s 2025 State of the API Report, 82% of organisations now describe themselves as API-first. It’s a comfortable number to cite in a strategy deck. However, that number becomes far less comfortable when we ask what “API-first” was actually built to withstand.
For most of the past decade, the concept meant something modest. Teams would publish a specification, place it behind a gateway, and let a developer read the documentation before building against it. However, that approach falls far short of preparing for an Artificial Intelligence (AI) agent to call the same API independently. The agent could chain it into workflows that nobody approved, operating at a speed and volume no human reviewer could match.
The reader you’ve been quietly relying on
The same Postman report found that only 24% of developers design their APIs with an agent as a potential caller. The remaining 76% still build for people. Roos says these users are patient enough to read a wiki page, forgiving enough to work around a clumsy error format, and sensible enough to stop when a response looks wrong.
Remove that human reader, and every shortcut the industry has quietly taken for years stops being a shortcut. Instead, it becomes the very thing that breaks. Composability was always the actual job, not a ‘nice to have’. What let most teams skip it was a human downstream, absorbing the rough edges.
Most enterprise APIs built over the past ten years were never truly designed for machines. Instead, developers designed them for careful human users and layered automation on top. This approach worked because a person always stood one step away, ready to catch a mistake.
A basic agent does not open a dashboard or ask a colleague for help. It also will not notice that a number looks wrong unless developers specifically build that capability into it. When an agent relies solely on an API’s response, it acts on whatever that response says. It does so consistently, tirelessly, and without the judgment that the architecture has relied on all along.
That is the bill coming due for a decade of assuming that someone patient would always read the response. As enterprises embrace enterprise APIs and AI agents, they must reconsider the assumptions that shaped their existing architecture.
Why the pilots keep stalling in the same place
Anyone running agent pilots today will recognise the pattern. Usually, the model itself is not the problem. An agent reasons its way towards a sound decision and calls an API. However, the API silently returns the wrong information or requires three undocumented headers that a developer simply “knew” to send.
The failure looks like a model problem, but it is not. Instead, an old architectural decision resurfaces ten years later. As organisations expand their use of enterprise APIs and AI agents, these hidden weaknesses can undermine otherwise promising projects.
Raising the bar, not lowering it
None of this means organisations should tear down existing systems or bypass security. Most existing APIs do not need replacing. Instead, teams must make them understandable to systems that are not human. They must describe APIs precisely enough for a model to call them correctly without guessing.
Protocols such as Model Context Protocol (MCP) aim to standardise an answer to this challenge. Teams must also restrict permissions tightly enough to ensure that a wrong guess does not cause harm. An agent with broad, unscoped access isn’t composable; it’s a loaded gun with nobody confirmed to have their finger off the trigger.
Composability raises the bar on governance. It doesn’t lower it. Consequently, organisations must treat governance as a core requirement when preparing enterprise APIs and AI agents for production. They need clear descriptions, controlled permissions, and safeguards that account for autonomous actions. Without these measures, greater automation can amplify existing weaknesses rather than resolve them.
The test that actually matters
If your organisation has an agent initiative on its roadmap, the most important question is not which model you are evaluating. Instead, ask whether the API calls that the agent depends on would work today, without supervision, against a live system. Could they do so with nobody standing by to notice if something went wrong?
For most enterprises, the honest answer is no. The problem is not necessarily that the agent is unready. Rather, the APIs it must use were built for a reader who is about to stop being the only one asking questions.
