When AI Can Act, the Product Is No Longer Just the Interface

For most of the software era, the interface has been the clearest expression of the product. Users click buttons, complete forms, review information and make decisions. Even when sophisticated automation exists behind the scenes, the user generally remains the actor. The software provides the environment in which work happens. Agentic AI begins to change that relationship.

An AI system that can retrieve information, call APIs, send messages, update records, create tickets, change configurations or complete a multi-step workflow is no longer simply helping a user interact with software. It is beginning to operate the software on the user's behalf. That distinction sounds subtle, but it changes what product teams need to design.

The quality of the interface still matters. So do speed, accessibility, clarity and user experience. But once AI can take consequential actions, the product also includes the system of permissions, boundaries, approvals, logs, recovery mechanisms and escalation paths surrounding those actions. The interface may still be what the user sees. Increasingly, however, the product is also what the AI is allowed to do when the user is not directly controlling every step.

From answering questions to exercising authority

Generative AI initially fit comfortably into familiar interface patterns. A user entered a prompt, the system generated a response, and the person decided what to do next. That model preserves a relatively clean division of responsibility. The AI proposes; the person acts. .

Consider an employee asking an AI assistant to resolve an issue with a supplier invoice. A conventional assistant might summarize the invoice, identify the discrepancy and draft an email. An agent could potentially look up the supplier record, query the financial system, update a case, contact the supplier and schedule a follow-up. The value comes precisely from reducing how many individual steps the employee has to perform. But those same capabilities create product questions that cannot be solved by improving the chat interface.

Can the agent read supplier records but not edit them? Can it send an external email without approval? Can it update payment information? Which actions require confirmation? What happens if the AI misunderstands the user's instruction midway through a workflow? Can the user see what changed? Can the action be reversed? These are not secondary governance considerations attached after the product has been designed. They are part of the product itself.

The major enterprise AI platforms are increasingly exposing controls that reflect this reality. OpenAI's enterprise workspace agents, for example, support role-based access, auditability and approval requirements around actions such as sending, editing or deleting information. Microsoft's guidance similarly argues that the practical risk of an agent depends heavily on the tools and permissions it receives, because those determine what it can actually do in connected systems.

The industry's product architecture is therefore beginning to acknowledge something important: capability without authority is assistance; capability with authority is delegation. Those are different products.

Permissions become part of the user experience

Product teams have traditionally been able to treat access control as something implemented largely through application roles, administrator settings and security architecture. Agents make that separation much more difficult.

Imagine an AI assistant embedded within a customer relationship management platform. It may be useful for the agent to research an account, summarize correspondence and recommend a follow-up. Allowing that same agent to modify an opportunity forecast, issue a discount or send a message directly to a customer introduces progressively greater consequences.

A good product therefore needs more than a binary choice between enabling or disabling the agent. It needs an understandable model of delegated authority.

Some actions may reasonably occur automatically. Others should require explicit approval. High-impact actions may need to remain unavailable altogether. The appropriate boundary will depend on the workflow, user role, data involved and consequences of failure.

This is partly a security problem, but framing it only as security misses its importance to product design.

If approval prompts appear for every trivial action, users will stop paying attention. Anthropic has described precisely this problem in its own agentic products: its telemetry showed users approving roughly 93 per cent of permission prompts, contributing to a shift toward containing what agents are technically able to do rather than depending entirely on repeated human confirmations.

Human oversight is not effective simply because an “Approve” button exists. The product has to decide when human attention is valuable enough to interrupt the workflow. Too many interruptions undermine the reason to use an agent. Too few can allow consequential mistakes to move quickly through connected systems. The design problem is finding the boundary between useful autonomy and meaningful control.

Failure needs to be designed, not merely detected

Traditional software often assumes a relatively deterministic relationship between action and outcome. A user presses Save, the application validates the request, and the database is updated.

Agentic systems can operate differently. They may interpret an objective, choose among tools, execute several steps and adjust their approach as new information appears. That makes successful execution important, but it makes failure behaviour equally important.

Suppose an IT support agent is allowed to diagnose employee access problems. Reading logs, checking group membership and recommending a fix may represent relatively low-risk actions. Automatically changing identity permissions is different.

The important product question is not merely whether the agent can correctly resolve most access problems. It is what happens during the minority of cases where its reasoning is wrong, the underlying data is incomplete or the request itself is ambiguous.

Can the agent recognize uncertainty and escalate? Does the user know which actions have already occurred? Can an administrator reconstruct the workflow afterwards? Can a mistaken change be rolled back easily?

NIST's recent work on AI agents highlights similar issues from an identity and authorization perspective, focusing not only on what agents can access but also on identification, authorization, auditing and accountability when software acts autonomously.

For product teams, this means that observability and reversibility deserve the same design attention as completion rates. An agent that successfully completes 98 per cent of a workflow but leaves the remaining 2 per cent difficult to identify, explain or reverse may be a worse product than one with slightly less autonomy but significantly better control over failure. The metric cannot simply be how often the AI finishes the task. It also has to include what happens when it should not have finished it.

The product boundary is getting larger

Agentic AI ultimately expands what counts as product design. The product is still the interface where the user explains what they want. But it is also the integrations that give the agent access to other systems. It is the identity under which the agent operates. It is the permission model limiting what it can change. It is the approval mechanism that determines when the user must intervene.

It includes activity histories that explain what happened, escalation paths for ambiguous situations and recovery mechanisms when an action needs to be undone. This has practical consequences for how organizations build AI products.

Product managers will need to work more closely with identity teams because delegated authority affects the experience. Security architects will need to understand intended workflows rather than applying generic restrictions. Designers will have to communicate not only what the AI knows, but what it intends to do. Engineers will need to build controls that remain effective even when an agent's individual decisions are probabilistic.

Most importantly, teams will have to resist equating greater autonomy with a better product. Some workflows benefit enormously from autonomous execution. Others are valuable precisely because AI prepares the work while a human retains the final decision.

The appropriate level of autonomy should be determined by the consequence of the action, the predictability of the workflow and the organization's ability to recover when something goes wrong. That is a more difficult product problem than placing an AI assistant inside an existing interface.

As software becomes capable of taking actions rather than merely presenting options, product design increasingly becomes the design of delegated authority. The organizations that understand that distinction will be better positioned to build useful agents without confusing convenience with control.

When AI can act, what appears on the screen is only part of the product. What matters just as much is everything the system permits to happen behind it.