Essay: Designing The Agentic Interface

Why APIs aren’t the interface agents need

We’ve learned this lesson once already.

There was a time when APIs were shaped too closely to the systems behind them — thin layers over databases, service boundaries leaking straight through. It worked, but it made those APIs harder to use and tightly coupled to how things happened to be built underneath.

Over time, we shifted. APIs became something you design for consumption, not something you inherit from implementation. Something similar is starting to happen again.

As teams expose capabilities to AI assistants and agents, many are reaching for what already exists — projecting their APIs outward as tools. Often, it’s a near one-to-one mapping. It works. The model can call them.

But it doesn’t feel like the right interface. It's probably lazy. Because the consumer has changed. APIs were designed for software. Agents operate differently, they reason over intent, select actions, and compose outcomes. And that changes what a good interface looks like.

If the consumer has changed, then the interface has to change with it. What we’re starting to see is the emergence of a different kind of surface — something that sits above existing APIs, but isn’t shaped like them. I’ve started thinking about this as the agentic interface. Not a new system, and not a replacement for APIs, but a different layer, designed specifically for how agents consume capability. Because an API and an agentic interface are solving different problems.

APIs expose capability. Agentic interfaces enable delegation. That distinction is subtle, but it matters. APIs are often shaped around system boundaries, resources, entities, and operations that reflect how the platform is built. They assume a consumer that can orchestrate multiple calls, manage state, and assemble an experience step by step.

An agent doesn’t approach the system that way. It starts with intent. It looks for a meaningful action. It tries to produce an outcome. And that creates a different kind of pressure on the interface.

What’s starting to emerge, quite naturally, is a kind of one-to-one mapping. Existing APIs are being exposed directly as tools, endpoint by endpoint, operation by operation. If the platform has fifty capabilities, the agent gets fifty tools. If the APIs are granular, the tools are granular.

It makes sense. It’s the fastest path to “having something working.” But it carries the shape of the system straight through into the interface. And that’s where things begin to strain. Because the agent now has to navigate a surface that was never designed for it, a large set of low-level actions, loosely connected, often named and structured for internal clarity rather than delegated intent.

We’re already starting to see the effects of this. Tool catalogs growing quickly. Interfaces becoming increasingly chatty. More back-and-forth between model and system to complete what is, from a user’s perspective, a single task. Context Windows getting crowded.

There’s also a broader conversation emerging around context pressure, large tool definitions, verbose schemas, and expanding interaction loops all competing for space in the model’s working context. Whether that becomes a hard constraint or not, it’s pointing to something important.

When the interface is fragmented, the model has to do more work. More selection. More orchestration. More stitching together of partial steps into something coherent. And the fastest way to create that fragmentation is to mirror your APIs directly.

If the interface is being designed for delegation rather than assembly, then the shape starts to change.

Instead of exposing many small, mechanically accurate actions, the interface begins to offer fewer, more meaningful ones — each representing a coherent unit of work. Not every capability needs to be directly exposed. Not every internal step needs to be visible.

In most cases, what matters is the outcome. So rather than asking an agent to:

• Retrieve a customer
• Retrieve their orders
• Retrieve their subscriptions
• Retrieve their payment history

And then reason across those pieces… you might offer something closer to:

• Smmarise this customer
• Identify any risks or issues
• Recommend the next best action

The underlying APIs haven’t changed. But the interface has. It’s been shaped around intent. This doesn’t mean everything becomes a single “do everything” tool. There’s still structure. There are still boundaries. But those boundaries tend to follow tasks, not tables. They reflect:

• What a user might reasonably delegate
• What an agent can safely execute
• What can be understood and selected in context

Rather than how the system is internally decomposed

That often leads to tools that:

• Bundle internal orchestration
• Gather and shape their own context
• Return outputs that are already useful for reasoning or presentation

Instead of pushing that work back onto the model. There’s also a subtle shift in what you choose to hide. In traditional API design, transparency and composability are often prioritised, exposing smaller pieces so that consumers can combine them as needed.

In an agentic interface, over-exposure can become a liability. Every additional tool:

• Increases selection complexity
• Expands the decision space
• Competes for attention in the model’s context

So part of the design work becomes:

• What should be visible?
• What should be bundled?
• What should be handled internally?

Not to reduce capability, but to present it in a way that’s usable through delegation.

Seen this way, the agentic interface isn’t a thin wrapper over your APIs. It’s a translation layer. Your APIs remain the capability layer. Your agentic interface becomes the delegation layer. And the quality of that layer is defined less by how completely it exposes your system… and more by how effectively it allows an agent to do something useful with it.

There’s a lot of attention right now on how to expose capabilities to agents — which protocols to use, how tools should be registered, how systems connect.

MCP is emerging quickly as a dominant pattern in that space. That said, it’s easy to focus on the transport and miss the design question sitting underneath it. Because regardless of how those capabilities are exposed, the shape of the interface still matters.

If the agentic interface is just a projection of existing APIs, we inherit the same issues we’ve seen before — surfaces that are technically complete, but harder to use, harder to reason over, and more tightly coupled to internal structure than they need to be.

We’re already seeing early signals of that strain. Larger tool catalogs. More fragmented interactions. Growing pressure on context and orchestration. Maybe those constraints shift over time. Context windows will expand. Tooling will improve. But the underlying principle is unlikely to change.

Interfaces work best when they’re designed for how they’re consumed. APIs evolved when we stopped shaping them around databases. This feels like a similar moment. Not a replacement of APIs — but the emergence of a layer above them. One that’s shaped around delegation. One that reflects how agents actually operate. The protocol will matter.

But the interface will matter more.