Why Current APIs Are Slowing Down AI Agents

When an AI agent fails to interact with an external system, the usual instinct is to blame the model or the orchestrator. But there's a thesis gaining weight among those who work daily with integrations: the bottleneck isn't in the AI, but in the systems it's trying to connect to. That's exactly what the AppFactor team argues in an article published this week, using as a concrete example how they redesigned their `GetProcInfo3` tool to be readable by agents.

The piece, picked up on Hacker News on May 29, 2026, starts from a simple premise: existing APIs were designed to be consumed by deterministic code written by humans, not by language models that reason in natural language and make decisions at runtime.

The Core Problem: APIs Designed for Programmers, Not Models

A classic API assumes that whoever calls it knows exactly which endpoint to use, what parameters to send, and how to interpret the response. That assumption holds when the consumer is a developer who has read the documentation. It breaks down when the consumer is an agent that needs to discover what it can do, infer which tool is relevant for a given task, and recover from semantic errors, not just syntactic ones.

What the AppFactor article describes is a process of semantic enrichment: adding metadata to the tool's responses that an agent can use to make decisions. It's not about changing the business logic, but rather making the API surface discoverable and meaningful for a language model. The team calls this "semantic discovery" and combines it with what they call "AI enrichment", that is, annotations that contextualize the returned data.

Why This Matters Now, with MCP and Claude Code

This debate isn't new, but it takes on concrete urgency in the current ecosystem. With Claude Code and the MCP protocol as the standard for agents to call external tools, the quality of that integration layer directly determines how useful an agent is in practice.

A well-built MCP server can expose rich descriptions of its tools, parameter schemas with examples, and interpretable error messages. But if the underlying system, a legacy API, a corporate database, or a SaaS service from ten years ago, returns opaque responses or requires implicit knowledge to be used correctly, even the best MCP server won't compensate for that friction.

AppFactor's approach suggests that the real work isn't just in writing the MCP wrapper, but in reformatting the semantics of what the system returns. That can involve:

• Adding descriptive fields alongside numeric identifiers or internal codes
• Structuring responses so the agent can reason about them without additional context
• Documenting the limits and error cases so the model can decide whether to retry, escalate, or abandon

Who This Is Relevant For

This reflection is especially useful for three profiles. First, platform teams that are exposing internal services via MCP and wondering why their agents keep failing even though the server is technically operational. Second, consultancies and integrators, like ourselves at ElephantPink, who work on connecting legacy systems with custom Claude agents: the investment in semantically enriching existing APIs is usually more productive than fine-tuning the agent's prompt. Third, developers of plugins and sub-agents for Claude Code who want their tools to be robust against ambiguous instructions.

What the article proposes isn't glamorous: it's solid plumbing work. But in practice, the difference between an agent that works in production and one that fails unpredictably usually lives exactly there, in that middle layer that nobody wants to touch.

That said, the article relies on its own case and has limited traction in the community so far, a single point on Hacker News and a comment at the close of this edition. It's worth noting as a methodological reference, not as a validated case study at scale.