APIs Were Built For Applications; AI Agents Change The Equation
Barry Bernstein is the managing director and COO of technology services at ViewTrade.
gettyGood API (application programming interface) design traditionally meant a few well understood things: document the endpoint, secure it with strong authentication, keep performance reliable and give developers flexibility to build what they need. That worked because calling the API was almost always a person or a program a person had built to follow a predefined path.
An AI agent is a different kind of consumer than what most APIs were built for. Unlike a conventional application following a predefined workflow, an agent can decide at runtime which tools to use, sequence actions on its own and keep working toward a goal without a person checking every step.
So, I’ve started thinking about an API differently. It’s not just a gateway to data anymore; it’s an execution surface. Giving an agent access means giving that agent the ability to act on your behalf.
Teams worry about an agent making an obvious bad call. What trips organizations up is more subtle: an agent making a call that’s completely valid from the system’s point of view and still produces an outcome nobody wanted.
Authentication, authorization and rate limits are still necessary, but not enough on their own anymore. An agent-ready platform also needs action-level permissions, current state, structured responses, protection against duplicate actions, complete audit trails and clear points where a human must approve something.
I see this in financial services, which is my field of experience and expertise. A “200 OK” response doesn’t tell the whole story. An event can execute successfully and still violate a restriction, duplicate an instruction already sent or process after a state change. For an agent, technical success and business correctness are two different things. Today’s APIs do not make that distinction explicitly.
The numbers back this up. A 2026 Salt Security survey of 327 security leaders found 48.9% of organizations lacked visibility into machine traffic and couldn’t monitor what agents were doing; 47% said API-security concerns had delayed a production release. Adoption is moving faster than governance, and I don’t think that gap closes on its own.
Previously, I would have told you good API design meant exposing functionality cleanly and letting developers build around it. I still believe that, but I now think it’s incomplete.
APIs should be designed backward from the business outcome, not outward from the underlying system function, communicating not just what action is available, but the current state, the conditions under which it’s permitted and how to recover if something goes wrong.
For a financial transaction, that might mean exposing transaction state explicitly, requiring an idempotency key so the same instruction can’t execute twice, and separating the permission to prepare an order from the permission to submit it. None of that is exotic, it’s the discipline that keeps a small mistake from becoming a real loss.
Documentation can’t be written for a human reader alone anymore, either. Schemas, permissions and what errors mean increasingly need to be structured and machine-readable, so an agent can interpret them correctly instead of guessing.
I don’t think every API needs to be torn down and rebuilt for this. Agents don’t make REST (Representational State Transfer) obsolete, and adopting a new protocol doesn’t automatically make a platform agent ready. If an API is consistent, deterministic, well documented and returns structured data with meaningful errors, an agent should generally work with it as-is.
Where I get concerned is workflows that change financial or legal states, depend on unwritten business rules or produce ambiguous outcomes, places where a human has always filled the gaps with context and judgment. Handing an agent an endpoint doesn’t hand it that judgment.
If I had a limited window to make a platform agent ready, I wouldn’t try to do everything at once. I’d inventory what agents could access, and classify those capabilities by consequence, read-only, reversible and actions carrying financial or regulatory weight, then pick one or two contained workflows where the value is obvious and the risk is manageable.
From there, I’d give every agent its own identity with narrowly scoped permissions, require human approval for anything high-impact and make sure the platform can confirm current state before an agent proceeds. I’d also invest in observability: audit logs, monitoring and a way to stop an agent immediately.
What I would not do is rebuild the entire API estate or launch a dozen use cases at once. That tends to create more risk than value.
The consequences go beyond any single technical incident. If an API can’t clearly communicate permissions, the state and outcomes, clients build extra reconciliation work around it, which slows down and raises the cost of every integration. Some will absorb that cost; others will just pick a provider that gets them to production faster.
I’ve also seen companies invest heavily in agents and still need people reviewing routine actions manually, paying for the complexity of AI without getting the efficiency it was supposed to deliver. Trust ends up mattering more than uptime in deciding which platforms get automated against, and which get left out.
My takeaway is that agents don’t require abandoning solid API fundamentals. They require extending them. Platforms that treat identity, permissions and auditability as part of the transaction itself, not bolted on afterward, will be the ones agents, and the people relying on them, can trust to act.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
