Interfaces 2026

Something I've been thinking a lot about over the past few weeks is interfaces, and specifically how software is accessible to humans, other programs, and, increasingly, agents. This post is a visual walk-through of some of these thoughts. It includes examples of interfaces worth considering when building software today.

I'll use one of my side projects, AiPod - answer engine, a Perplexity-inspired answer engine grounded in podcasts, as a toy example to showcase what kinds of interfaces you could build around it.

Interface examples

The sections below show interfaces, broadly defined as surfaces through which a product gets used. They make AiPod accessible to humans, programs, and agents. It is important to mention that these are not mutually exclusive, and many are in fact complementary and built on top of each other. For example, the web app will use the underlying API, and the agent plugin bundles skills and MCP servers. I should also note that this list is not exhaustive, and only covers the interfaces I think are most relevant for the AiPod product I use as an example here.

For each of the sections below, I have included a brief description of the interface itself, and then shown how it could be applied to AiPod.

API

Application Programming Interface (API) is an interface programs use to interact with each other and exchange data. In our example, exposing the API with thorough documentation would enable other developers and agents to build new podcast products and services on top of AiPod.

CLI

Command Line Interface (CLI) is an interface for interacting with software via commands in the terminal. In our example, making AiPod available through CLI enables humans and agents to easily interact with, and integrate AiPod into workflows.

MCP

Model Context Protocol (MCP) is an interface for agents to connect to external systems. In our example, having an MCP server would enable AI applications built on top of agents, like ChatGPT, to connect to AiPod and give podcast-episode grounded answers.

Web application

A web application is an interface for humans to interact with software in the browser. In our example, developing a web application would enable users to go and visually explore the data in the AiPod index via a browser.

Skill

A skill is an interface for sharing a set of instructions, resources, and scripts with agents for a specific task. In our example, creating different AiPod skills would enable users and agents to get specific podcast-related tasks solved, by invoking the skill when relevant.

Agent plugin

An agent plugin is an interface for bundling multiple skills and MCP servers to share with agents — both to connect to external systems and provide relevant context. In our example, sharing a plugin via an agent marketplace would enable humans and agents to fully integrate AiPod capabilities into agent workflows.

Things I'm still figuring out

I am still learning and experimenting with the interfaces above, and here are some open questions I'm still working through:

• MCP vs. CLI. It's still unclear to me if MCP is the protocol that works best for agents in the long run. On the one hand, I am seeing more and more companies starting to integrate their product via MCP, but on the other hand, Peter Steinberger and others argue for CLIs over MCP.
• CLI and MCP from API docs. I don't yet have a good intuition for how much of the CLI and MCP interface can be generated from an OpenAPI spec. My hunch is that both CLI and MCP need to have some custom use-case logic around them to create value.
• Skills as a product. I have recently been very impressed by the leverage one can gain from using gstack by Garry Tan and Matt Pocock's skills, which are essentially repos of nested skills. Having these skills available enables new development workflows and supercharges average coding agents. I think packaged skills could become a product in their own right.
• Evaluating skills across models. When making your own skills, how do you evaluate them rigorously, especially when they're used across different models that may already have pre-filled context windows.

Final notes

Just like with all product design, thinking about who you design for is a good starting point before exploring the solution space. I think that when it comes to software in the age of AI, having a good interface for agents will only become more important, and a real differentiator for your product. I look forward to exploring these interfaces in more depth in the near future.