Dariel says most enterprise APIs were designed for human developers rather than autonomous AI agents, creating reliability and integration challenges as agents increasingly interact directly with business systems. According to Jurgen Roos, organisations need to make existing APIs more machine-readable, precisely documented and tightly permissioned so AI agents can use them safely and reliably without human intervention.
Enterprises love to call themselves API-first. Almost none of them are ready for what's about to start calling those APIs.
Eighty-two percent of organisations now describe themselves as API-first, according to Postman's 2025 State of the API Report. It's a comfortable number to cite in a strategy deck but, according to Jurgen Roos, Team Lead in the office of the CTO, Dariel, it's a much less comfortable number once you ask what "API-first" was actually built to survive.
For most of the last decade, it meant something modest: publish a spec, put it behind a gateway, let a developer read the docs and build against it. That's a world away from being ready for an AI agent to call the same API on its own, chaining it into workflows nobody signed off on, at a speed and volume no human reviewer was ever built to 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 possible caller. The other 76% are still building for a person, one that Roos says is patient enough to read a wiki page, forgiving enough to work around a clumsy error format, and judged enough to stop when a response looks wrong.
Take that reader away, and every shortcut the industry has quietly taken for years stops being a shortcut. It becomes the 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,” says Roos.
Most enterprise APIs built over the past ten years were never really designed for machines. They were designed for careful humans, with automation layered on top, and it worked, because a person was always one step away, ready to catch a mistake. A basic agent doesn't open a dashboard. It doesn't ask a colleague. It won't notice a number looks off unless it's specifically built to notice. Left with nothing but the API's response, it acts on whatever that response says, consistently, tirelessly, and without the judgement the architecture has been leaning on the whole time.
That's the bill coming due on a decade of assuming someone patient would always be reading the response.
Why the pilots keep stalling in the same place
Anyone running agent pilots right now will recognise the pattern, and it usually isn't the model. An agent reasons its way to a sound decision, calls an API, and the API silently returns the wrong thing, or needs three undocumented headers a developer just "knew" to send. The failure looks like a model problem. It isn't. It's an old architecture decision, showing up ten years late.
Raising the bar, not lowering it
None of this is a case for tearing anything down or bypassing security. Most existing APIs don't need replacing. They need to become legible to something that isn't a person: described precisely enough for a model to call correctly without guessing, the exact problem protocols like MCP are trying to standardise an answer to, and permissioned tightly enough that a wrong guess doesn't matter.
"An agent with broad, unscoped access isn't composable, it's a loaded gun with nobody confirmed to have their finger off the trigger,” says Roos. “Composability raises the bar on governance. It doesn't lower it.”
The test that actually matters
If your organisation has an agent initiative on the roadmap, the question worth asking isn't which model you're evaluating. It's whether the API calls that agent depends on what would work today, unsupervised, against a live system, with nobody standing by to notice if they didn't.
For most enterprises, the honest answer is no. Not because the agent isn't ready. Because the APIs it's meant to use were built for a reader that's about to stop being the only one asking. Ends.
About Dariel
Founded in 2001 on the principle of delivering solutions right, the first time, Dariel bridges the gap between human ingenuity and technology. Our strong client partnerships reflect a commitment to excellence and our consultative approach to software engineering makes us a trusted partner for innovative and sustainable tech solutions. Proudly independent, Dariel is part of the JSE-listed Capital Appreciation Group. https://www.dariel.co.za/
For more information:
Samantha Hogg-Brandjes | GinjaNinja | samantha@ginjaninja.co.za | +27-84-458-4857