Connecting AI agents to company APIs one tool at a time stops scaling

The agent is a new client for old systems

Most large companies spent the last decade building API programs. An API is a controlled doorway into a system such as customer records, orders or pricing. Agents now need to use those doorways. How they get connected decides whether the old controls still apply.

Marco Palladino, CTO and co-founder of Kong, makes that case in a contributed InfoWorld piece. Kong sells API and AI gateway products. A gateway is the checkpoint that sits in front of APIs. So he has a commercial interest. The piece ran in InfoWorld's New Tech Forum, which takes outside contributors. Read it as an informed vendor view, not independent research.

Why one tool per operation breaks down

MCP, the Model Context Protocol, is a common format that lets AI agents call outside tools. Palladino describes a default habit. A team feeds an API's OpenAPI specification, its machine-readable list of operations, into a generator. The generator makes one agent tool for each operation. That suits a small API. A typical enterprise CRM or ERP system, he says, can expose hundreds of operations. An agent that touches a few such systems inherits hundreds of tool descriptions.

He lists three costs. The first is price. The model reads every tool description before it does any work, and each interim result passes back through it. A routine task, such as checking a customer, their open orders and a shipment, is billed in tokens at every step. The second is accuracy. Once the list grows long, the agent may choose the wrong tool among lookalikes, or use three calls where one would do. The third is delay, which users feel before anyone sees the bill.

Teams often respond by trimming the lists and splitting big APIs into many small MCP servers. Palladino objects that each agent use case then needs its own hand-maintained integration. That is the sprawl API programs were meant to end.

How code mode works

His alternative is called "code mode". The server shows an API as one interface, like a code library a developer would use, instead of a flat list of tools. The agent writes a short snippet against it. The snippet runs in a sandbox, a sealed environment, and only the final result goes back to the model.

The agent searches for the operation it needs, fetches that operation's schema when required, then runs it. Palladino's reasoning is that models have trained on a lot of code and little tool-calling syntax. One snippet can also chain several calls with loops and error handling, so fewer round trips pass through the model.

Kong ran its own test on one workflow. Using ordinary tool calling, it took about 120,000 tokens, the units AI models are billed in. In code mode, Palladino says, the same job took roughly 1,200. The piece does not describe the workflow or the method. Treat it as one vendor measurement.

Palladino also names a price for the approach. Because the agent writes the code, the company must trust the sandbox that runs it. It also needs a full record of which calls that code actually made.

The second problem is governance

In Palladino's account, shrinking the context load does not settle who controls access. Whenever an agent reaches a production API, it faces the same checks as any other caller: proof of identity, permission for the specific action, limits on volume, and a record of what happened.

He says many teams building agent integrations recreate those checks separately inside each MCP server. Credentials end up in server configs. Whoever wrote the integration sets the access rules. In those setups, he says, agent traffic bypasses the gateway, so it does not show up in the logs security teams already watch. He gives no data on how common this is. It is his assertion, and a plausible one, but unmeasured.

His remedy is to generate the agent interface from the specification and access policies the API platform already holds, then route agent calls through the same gateway. He also suggests scoping each interface to the agent's job. A support agent gets ticketing, CRM and shipping, but not payroll. He calls scoping both a security control and a performance control.

Code mode moves the audit question

This section is our argument, not Palladino's. Putting governance second is also our framing. He does not rank the two problems.

Code mode packs many calls into one snippet. If the gateway records only that a sandbox ran, it loses the detail an audit needs. Logging has to capture each underlying API call, with the agent that made it. The snippet can reach whatever the interface exposes, so the scope set for the agent decides what it can touch.

Hand-built agent connectors resemble the shadow IT of earlier years, where useful tools grew outside the controls meant to cover them. Palladino's rule is that the agent becomes one more governed client. That is sound. Our own view is that the sandbox case deserves extra care. The model writes the snippet, so no person reviews each call before it runs. A gap in access rules is then easier to use unnoticed.

Questions to put to your team

Ask how many MCP servers exist today, who owns each one, and which were built outside the platform team. Ask whether agent calls appear in the same gateway logs as other traffic. Ask where agent credentials are stored.

Ask what each agent can reach, and whether payroll-type systems are excluded by design. If a vendor offers code mode, ask what sandbox runs the code and whether the logs show every call it makes, not just the run. Test token cost on your own workflows rather than relying on a vendor's figure.

Palladino closes by saying most enterprises have already built the groundwork. If so, the job is to extend existing discipline to a new kind of client. The cheapest control is the one already in place, provided it can see the traffic.

Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: InfoWorld.