Machine-Usable Interfaces

The idea

An AI agent acts through whatever interfaces it can call. If ordering stock, changing a policy or approving a refund can only be done by a person in a screen, an agent can only imitate that person, by scraping pages or driving a browser, which is slow, brittle and hard to secure. A machine-usable interface exposes the capability directly: an API, an event or a tool definition that is documented, permissioned and kept stable.

The precedent is older than AI. In a 2011 post meant for colleagues at Google, Steve Yegge described a mandate he said Jeff Bezos issued at Amazon around 2002: every team would expose its data and functionality through service interfaces, teams would communicate only through them, no back doors, and every interface would be designed so it could be opened to outside developers. Yegge's account is the main public source, and he gave it from memory. Today the Model Context Protocol is an open standard for exposing tools and data to AI applications, so one well-described capability can serve many agents.

Why it works

Agents are bounded by what they can reach. Model quality matters less than access. An enterprise whose functions live in screens caps its automation at whatever brittle screen-driving can manage.

Interfaces carry meaning that screens hide. A good interface names the operation, its inputs, its errors and its side effects. Agents, like developers, choose and combine tools far better when that is written down.

Permissions belong at the interface. A capability exposed as an API can enforce who may call it, for which records and with which limits. A screen reached through a person's session inherits all of that person's rights.

Where it applies

• AI transformation roadmaps, to decide which capabilities to expose before which agents to build.
• Legacy applications whose only entry point is a UI, often duplicated across business units.
• Integration platforms, where fragmented point-to-point links can become a catalogue of governed capabilities.
• Security reviews of agents, to check that each tool grants only what that agent needs.

How to apply

1. Map capabilities, not applications. List the business operations agents need, such as "check stock" or "issue refund", and find where each really lives.
2. Expose one owner's interface per capability. Wrap the system of record once, rather than letting every AI project build its own scraper.
3. Describe it for machines. Write clear names, schemas, examples and error meanings, and publish them as tool definitions where agents will look.
4. Permission narrowly. Scope credentials per agent and per operation, log every call, and require human approval for irreversible actions.
5. Version and keep promises. Treat agents as consumers: announce changes, deprecate slowly, and expect them to depend on observable behaviour.

Example scenario

A retailer launched an AI assistant for store managers. Stock levels, transfers and supplier orders lived in four applications, two of them reachable only through screens. The first version used browser automation to read them, broke whenever a screen changed, and ran with a manager's full rights.

The architects stopped building agent features and exposed three capabilities instead: query stock, propose a transfer and raise an order, each owned by the system's team, documented as tools and limited to the agent's own credentials. Orders above a threshold needed a manager's approval. The same tools were later reused by a replenishment workflow and by the online channel.

Questions to ask

When not to use it

• Rare, low-value tasks where a person doing the work is cheaper than building and governing an interface.
• Systems about to be retired, where an interim wrapper may be enough.

How it misleads you