From UX to AX: Designing Products for the Age of AI Agents

There is a phrase you hear more and more often in product workshops: “We could add an AI agent here.”

On paper, the idea sounds simple. An input field, a chat interface, a few automated actions, and the product feels like it has moved into a new generation. The demo works. The “wow” effect comes quickly. For a few minutes, everyone can picture the scene clearly.

Then the questions arrive.

What is the agent allowed to do? Which data does it work on? Can it send an email? Edit a customer record? Generate a sales recommendation? Trigger an approval? Who reviews it? Who owns the mistake? What gets kept in history? What do we show the user when the agent is unsure?

That is often the moment the topic leaves the realm of the demo and enters the realm of the product.

Digital products are changing roles. They still display, guide, and organize journeys, of course. But part of their value is shifting toward assisted action: reading a situation, proposing a next step, preparing a decision, sometimes executing a task within a given frame.

The interface then becomes a passage point between a human intention and a chain of more or less automated actions.

This shift profoundly changes the way we design a product.

When the interface starts to act

For years, UX mainly sought to make journeys more legible: reduce friction, clarify buttons, simplify forms, prioritize information.

That work remains essential. A confusing product with AI becomes a confusing product with more power.

With AI agents, a new layer appears. The user arrives with an intention, sometimes expressed in natural language, sometimes inferred from their context. The system must help them move from that intention to a sequence of understandable actions.

In a sales tool, this might take the form of an agent that prepares a customer summary before a meeting. In a back office, it might spot incomplete files and suggest the next step. In a SaaS platform, it might analyze a drop in usage, formulate a hypothesis, then prepare a re-engagement plan.

Design then becomes a matter of delegation.

This shift is subtle. It forces us to describe what the user entrusts to the system, what the system can do on its own, what it must ask before acting, and what stays explicitly human.

I like to talk about AX, for Agent Experience. The term is mostly useful as a working compass: how does a user collaborate with an intelligence that can act inside the product?

Delegation has to be designed

The classic trap is to start from the model. You pick an LLM, plug in two APIs, write a prompt, then go looking for use cases.

In well-framed projects, the path starts from the field.

Take a performance dashboard. Many teams dream of an agent that can answer a question like: “Why has my conversion rate been dropping for three weeks?”

A useful answer depends on many things that are less visible than the model: data quality, tracking plan, business rules, compared periods, commercial events, campaign changes, statistical limits. It also depends on how the agent exposes its reasoning.

A useful answer might look like this:

What matters is the structure of the reasoning. The user sees what was compared, the signals used, the limits of the analysis, and the next possible action. They can challenge it, complete it, validate it.

An isolated prompt rarely produces this level of reliability. It takes an architecture around it: clean data, permissions, an action log, confidence criteria, failure scenarios, and the ability to take back control.

It is less spectacular in a workshop. It is what makes the product usable after the demo.

Trust is built in the details

Trust in an AI product is built in very ordinary elements.

• A “validate before sending” button.
• A history of actions.
• A source shown beneath a recommendation.
• A visible level of certainty.
• An “undo” option.
• A clear message when the agent lacks information.
• A clean separation between suggestion and execution.

These details seem modest. Yet they decide adoption.

In a classic interface, a design mistake usually creates friction. In an agentic product, it can create a loss of control. The user must feel that the agent works within an understandable frame, with legible limits. As soon as the system acts too fast, too far, or with too little explanation, trust drops.

Transparency must be designed as a product function, not as a layer added at the end of the project.

This becomes even more important in the European context. The AI Act’s transparency rules will push companies to make certain AI uses more explicit. Products that have built in this requirement from the design stage will have less need to patch their experience at the last minute with poorly placed legal notices.

A user trusts when they have footholds: sources, hypotheses, limits, possible validation. Without those footholds, they are left with a black box behind a nice interface.

A usable memory

AI agents raise another, more discreet problem: memory.

An agent working on a complex task accumulates context. It reads documents, interprets signals, proposes options, receives validations, executes part of the work. If nothing is structured, that memory stays trapped in a conversation.

A few weeks later, no one really knows why a recommendation was followed.

This is a subject we often underestimate. Companies already struggle to keep a clean memory of their product decisions. With AI, that weakness can grow. Exchanges multiply, versions pile up, hypotheses travel fast.

The answer lies in a simple practice: materialize the important steps.

This vocabulary may sound very operational. Yet it is central. A serious agentic product must allow reconstructing what happened. To preserve control, but also to make maintenance, auditing, training, and handover to another team easier.

In a business tool, this can take the form of a legible activity feed: “the agent analyzed this data”, “it proposed these three actions”, “the user validated this one”, “the system executed that operation”, “this point remains to be checked”.

This memory becomes a piece of the experience.

The return of framing

AI gives an impression of speed. It sometimes encourages bad habits: building before understanding, automating before framing, adding a smart layer on top of a fuzzy process.

Product work becomes more demanding.

Before designing an agent inside a platform, you have to go back to the basic questions:

• Which user intention are we really serving?
• Which task deserves to be delegated?
• What level of autonomy is acceptable?
• Which data is reliable?
• Which actions must stay under human validation?
• What risk do we accept in case of error?
• How do we measure the quality of the result?

These questions seem simple. In a workshop, they quickly reveal the blind spots.

A team may discover that the CRM data is incomplete. That an approval process varies by region. That no one knows who decides when business and tech disagree. That the agent imagined in the demo actually assumes three integrations, two legal trade-offs, and a redesign of the permissions plan.

That moment is valuable.

It avoids turning an appealing intuition into a fragile project. It makes it possible to define a first useful scope: a bounded task, a clear data source, an identified user, a visible human validation, a success indicator.

A robust agent often starts there: a precise, well-bounded delegation, with visible value.

What to look at before launching

If I had to audit an AI product before launch, I would first look at a few very concrete points.

Data first. Is it clean, accessible, governed? An agent fed unstable data will produce unstable answers with a lot of confidence.

Permissions next. Can the agent read, write, send, delete, edit? Every verb counts. Reading a customer file and emailing the customer do not carry the same weight.

Human validation. At what point does the user take back control? A recommendation can be automatic. A committing action often deserves explicit validation.

Traceability. Can we replay what the agent did, with which sources, which hypotheses, which human decision? If the answer stays fuzzy, the product will be hard to maintain.

Measurement, finally. An agentic product must be evaluated on something other than usage volume. You have to look at the quality of recommendations, the acceptance rate, human corrections, errors avoided, time actually saved, and team satisfaction.

Product architecture takes a very concrete place here: it organizes rights, data, decisions, guardrails, and evidence. It lets the agent work within a useful, legible, and maintainable frame.

The coming months will bring many interfaces “with AI”. Some will impress in a demo. The most useful ones will have been designed with patience: clear intention, reliable data, explicit roles, visible guardrails, continuous measurement.

The rest will probably make for nice demos.