Why AI agents need smaller, better-defined APIs

Consider an insurer whose claims process runs through a single operation called ProcessClaim. It was built for the insurer's claims application, where staff capture the details on screen and the system works through everything else in one sequence. For that purpose it does its job.

Now suppose the insurer brings in an AI agent to help with a claim that is missing some evidence. A sensible next step might be to check the policy or ask the customer for the outstanding document. Neither exists as a separate operation, so the only thing the agent can call is ProcessClaim.

If the same process is split into operations such as GetPolicy, ValidateCoverage and RequestEvidence, the agent can call them in whatever order the claim needs. Each operation still carries its own validation, permission checks and audit record, and changing the order of the steps doesn't remove any of them.

"A lot of the systems we look at were designed so that a person fills in a screen and the system does the rest," says Slankamenac. "That worked fine for the application they were built for. An agent, though, needs to be able to stop partway through, look at what it has and decide what to do next, and many of these operations don't give it anywhere to stop."

How agents use the operations available to them

Most enterprise software follows paths its developers set in advance. An agent works out its next step as it goes, based on what it has found so far. In a claims case it might pull the customer record, spot an outstanding claim and open a case, but each of those actions has to exist as an operation it can call.

An agentic system has several parts. The model does the reasoning, and context data gives it something to reason about. The operations it can call define which actions are possible, while identity and policy controls decide which of those it is allowed to take. Models get most of the attention, even though the operations and permission controls around them usually take longer to get right.

An agent also has to be able to discover which operations exist and understand what each one means in business terms. It needs to authenticate with an appropriate level of authority, and when a call fails it should leave a clear record of what it attempted.

Where business logic sits in most organisations

In many organisations, much of the useful business logic isn't exposed through APIs at all. It lives inside monolithic applications and stored procedures, and in batch jobs that run overnight.

Standards such as MCP give agents a consistent way to discover and call tools, but they sit on top of business operations that still have to be designed and exposed. Some API architects are also concerned about teams building the same logic twice, once as APIs for applications and again as MCP tools for agents, sometimes with further wrappers for individual agent frameworks. Enterprises have spent years cutting that kind of duplication out of their integration estates.

The effect of higher call volumes

A person completing a task through a user interface might trigger a handful of API calls. An agent can make hundreds in a short period, and nobody reviews each one. Weaknesses that rarely mattered with human users, such as an ambiguous operation name or a service account with more access than it needs, now get hit far more often. Operations that aren't safe to retry are a particular concern.

Assessing readiness

Before an agent pilot, pick one business process an agent could help with and write down each step it involves. For every step, check whether a system can perform it through a callable operation with its own permissions and audit trail. Any step that fails that test is a place where integration work is needed."When we walk through a single process with a client, step by step, the gaps usually show up quite quickly," says Slankamenac. "It's often two or three steps that only exist inside an older application or a stored procedure. We'd start there, before anyone spends money on the agent itself." 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 | This email address is being protected from spambots. You need JavaScript enabled to view it. | +27-84-458-4857