The Last Interface

A speculative essay on software in the age of AI agents

For the past fifty years, software has been designed around the assumption that somewhere, on the other side of the screen, there is a human.

Every design decision follows from this premise. We obsess over navigation bars, buttons, forms, dashboards, onboarding flows, and empty states because we assume that a person will click through them. That assumption made the interface inseparable from the product.

Now the assumption is beginning to fail. Large language models are becoming the primary operators of software itself, a consequence that may prove more important than their ability to generate text.

Today, millions of people already ask ChatGPT, Claude, or Codex to write scripts, automate workflows, query databases, analyze spreadsheets, and build small applications. What used to require learning a dozen different products increasingly requires only describing an intention in natural language.

This trend has fueled predictions of a "SaaS apocalypse": if an AI can build exactly the software I need, why would I continue paying for generic software built for everyone?

The interface may stop being the center of how people use existing software.

Software has already gone through at least two major eras.

The first was software built for computers. Early operating systems, assembly languages, and command-line interfaces expected humans to adapt themselves to machines.

The second was software built for humans. Personal computers, graphical interfaces, smartphones, and SaaS products all revolved around making computers adapt to people instead.

AI agents suggest a third era, one in which software is designed for agents to operate. The human remains responsible for the outcome but moves one step away from execution.

Instead of opening ten different applications, navigating ten different interfaces, and manually transferring information between them, the user delegates the task to an intelligent agent.

The agent becomes the immediate consumer of software.

An agent needs a reliable way to discover available capabilities, understand their required inputs, take an action, and verify the result. That can mean creating a customer in a CRM, retrieving an invoice from an accounting platform, or updating the status of a project task.

A graphical interface presents those capabilities in a form a person can navigate. An API or an MCP server presents them in a form an agent can discover and call.

For decades, software companies competed by building better user experiences.

Clicks, intuitive navigation, and visual clarity remain important for humans. Agent operation adds a different set of requirements. Capabilities need clear names and predictable behavior. Each action needs enough context for the agent to use it safely. Errors need enough structure for the agent to understand what failed and whether it can recover. The actions also need to compose into larger workflows without relying on hidden steps in a graphical interface.

The people who choose a product still evaluate it. Now the agents acting on their behalf may evaluate its behavior on every call.

APIs and MCP servers are part of the product surface because they expose what an agent can see and do. An API provides access to the underlying functions. MCP can give agents a standard way to discover tools, resources, and prompts and to invoke tools, often backed by those same APIs.

The graphical interface becomes one client among many, and in some products it may be a secondary one.

This inversion feels strange because it challenges decades of software thinking.

A graphical interface translates computational capabilities into menus, labels, controls, and feedback a person can understand. An agent-facing surface translates the same capabilities into tool descriptions, input schemas, permissions, structured results, and errors another system can act on.

This also changes what it means to build a software company.

Today's SaaS products spend heavily to attract and retain human users. They may also need to be legible to the agents acting on behalf of those users.

Being the easiest product for an AI to understand, trust, and orchestrate could become as important as being the easiest product for a person to learn.

Documentation, schemas, authentication, permissions, semantic consistency, and machine-readable capabilities become part of the customer experience. An agent relies on them to decide what it can do, what it may do, and whether the result can be trusted.

This is why I suspect the phrase "SaaS apocalypse" misunderstands what is happening.

Software is unlikely to disappear.

Businesses will still need payments, accounting, scheduling, databases, identity management, logistics, analytics, and communication.

The assumption that these capabilities must always be consumed through a graphical interface is more likely to disappear. Some interactions will stay graphical, especially when a person needs to judge, review, or approve an action. Others will collapse into a call made by an agent. The interface becomes one path into the product, alongside direct access to its capabilities.

That leaves software teams with a practical design problem. They still have to build good screens for people while making the underlying capabilities equally clear to agents: stable APIs, well-described MCP tools and resources, explicit permissions, predictable outputs, and failures another system can understand and recover from.