DGDavies Ngwiri Gitau
Back to writing
AI agentsProductInterfacesSystems

We are moving from human interfaces to agent interfaces

Software is starting to serve two users at once: the human on the screen and the agent invoking capabilities behind it. That changes what good product and system design look like.

Editorial diagram showing a left-to-right shift from human-facing screens and forms to agent-facing capabilities, context, approvals, and traces.

What changes when software stops being designed only for humans and starts serving agents too?

Good systems need more than polished screens. They need invocable capabilities, structured context, permission boundaries, observability, and explicit points where a human can approve, redirect, or recover the workflow.

The interface shift

Left-to-right diagram comparing human interface software with agent interface software, showing delegation into capabilities, context, permissions, traces, and human approval.
The shift is not from humans to machines. It is from screen-bound workflows to systems that can be safely invoked, supervised, and reviewed.

For a long time, software mostly had one job: help a human do something through a screen.

So we built around screens.

We optimized for navigation, forms, buttons, table density, onboarding friction, and how quickly a person could move from one state to another. The interface was the product surface because the human was the only one using it directly.

That assumption is starting to break.

In From Human Interfaces to Agent Interfaces, the authors argue that software engineering is shifting from human-oriented interaction to agent-oriented invocation systems. Their framing is useful because it names the deeper change clearly: software is no longer only operated by humans. It is increasingly called, composed, and coordinated by AI agents through structured interfaces.

That does not mean screens disappear.

It means the screen stops being the only contract that matters.

The interface is no longer just the UI

An agent does not care whether your page looks polished. It cares whether the system can be invoked reliably, whether the tools are legible, and whether the outputs arrive in a form it can act on without guessing.

That is why I think a lot of teams are still using the word "interface" too narrowly.

If an agent is going to do useful work on behalf of a user, the real interface now includes:

  • the capabilities the system exposes
  • the structure of the inputs and outputs
  • the context that can be retrieved at run time
  • the permissions that define what can be done
  • the logs and traces that make the behavior reviewable

The paper above formalizes this with the idea of invocable capabilities and argues that agent-oriented systems need machine interpretability, composability, and invocation reliability. That is a much better starting point than simply adding a chat box to an old workflow and calling it agentic.

Capabilities matter more than pages

Human-first products often hide real system power behind a sequence of pages.

That works when the user is willing to click through the sequence. It breaks down when the caller is an agent trying to complete a goal across tools, policies, and time.

An agent-ready product needs capabilities that can be discovered and safely called:

  • fetch the relevant data
  • compare available options
  • execute a narrow action
  • return a structured result
  • surface confidence, failure, or the need for approval

This is one reason protocol work matters. The Model Context Protocol architecture describes a capability-based negotiation model where hosts, clients, and servers explicitly declare what they support. That is the direction I expect more products to move in, even when they do not literally adopt MCP.

The product becomes less like a maze of screens and more like a network of bounded, reliable abilities.

Context is becoming infrastructure

When a person uses software, they carry a lot of context in their head.

They know what they were trying to do. They can recognize when a step feels wrong. They can reinterpret a messy screen because they already understand the business task behind it.

Agents need that context to be supplied in a more deliberate way.

This is why agent interfaces are not only about actions. They are also about access to the right state, files, constraints, and history at the right moment.

You can see this pattern in current platform direction. Google's AI Mode announcement frames search as a system that can take harder questions, reason across them, and support follow-up exploration instead of only returning a ranked list. Their later multimodal AI Mode update explains that the system uses query fan-out to issue multiple queries about a scene and its objects. In other words, the interface is no longer just a single query box. It is a coordinated system deciding what information to pull together on the user's behalf.

That is an important shift.

The better your system exposes context, the less the agent has to infer by luck.

Permissions and approvals become part of the experience

As autonomy increases, permission design stops being backend plumbing and becomes a first-class user experience problem.

The user needs to know:

  • what the agent is allowed to do
  • what requires confirmation
  • what can happen automatically
  • what will be logged
  • how to stop, undo, or review the action later

This is where human interface design stays essential. It just moves.

The human-facing layer becomes less about pushing every button manually and more about setting delegation boundaries, confirming sensitive actions, handling exceptions, and understanding what happened.

If the agent layer is invisible, users will not trust it.

If the approval layer is clumsy, they will bypass it.

So the design challenge is not "replace the UI." It is "reallocate the UI toward oversight, trust, and recovery."

Observability is now part of UX

One of the strongest tells that a team is still thinking in purely human-interface terms is that they treat logs and traces as an internal engineering concern rather than part of the product's trust surface.

That view gets weaker once agents are doing real work.

If an agent can hand off tasks, call tools, retrieve context, and make decisions across multiple steps, then observability is no longer optional garnish. It becomes part of how the system stays debuggable and governable.

OpenAI's new tools for building agents make this explicit. The Responses API, built-in tools, and Agents SDK are not just about model calls; they also emphasize handoffs, guardrails, and tracing. That is the right instinct. Once software is acting across multiple turns and tools, a usable execution trace becomes part of the interface quality.

I increasingly think of this as the shift from:

  • "Did the screen help the user complete the task?"

to:

  • "Can the user and the team understand what the system attempted, why it did it, and where it failed?"

That is a different standard.

Human interfaces become thinner but more important

The human interface does not disappear in an agentic system. In some ways, it becomes more valuable because it is no longer carrying the entire workflow.

What remains for the human layer are the parts where judgment matters most:

  • setting goals
  • selecting tools or data boundaries
  • approving consequential actions
  • reviewing execution history
  • correcting the system when it drifts
  • stepping in when ambiguity or risk crosses a threshold

The interface gets thinner in terms of repetitive mechanics, but sharper in terms of responsibility.

That is why I do not think the future is "chat everywhere" or "UI is dead." I think the future is a split surface:

  • an agent interface for invocation, composition, and execution
  • a human interface for intent, oversight, approval, and trust

The strongest products will design both deliberately.

What I would want in an agent-ready system

If I were reviewing a product that claimed to be ready for the move from human interfaces to agent interfaces, I would want to see five things:

  1. Clear invocable capabilities with structured inputs and outputs instead of opaque, screen-locked workflows.
  2. Context access that is explicit, bounded, and relevant, rather than a model being forced to hallucinate its way through missing state.
  3. Permission and approval rules that make delegation visible and reversible.
  4. Strong observability, including traces, action history, and failure surfaces that humans can actually understand.
  5. A human layer designed for intervention, correction, and accountability, not just for legacy form entry.

Without those pieces, most "agentic" products are just fragile automation wrapped in new language.

Agent interfaces are a product design problem

The part I find most interesting is that this shift is not only technical.

It changes how we think about product boundaries.

When the caller is sometimes a person and sometimes an agent, the product is no longer just what happens on the page. It is the whole contract between intent, capability, execution, and review.

That means product design, system design, and trust design are starting to collapse into each other.

We are still early. A lot of the current tooling is immature. A lot of products are still pretending the old UI is enough. But the direction is visible now.

We are moving from software that waits to software that can be invoked.

And that means we are moving from human interfaces to agent interfaces.

Further reading

Keep reading or bring the problem in.

The writing is meant to be practical. If you want help applying the same thinking to a product, team, or delivery problem, that is exactly the kind of engagement I take on.