Blog

Human-centered and user-centered design are about to mean different things.

For most of my career, “user-centered” meant putting a person at the center: someone with a goal, limited time, and little interest in learning how our software works. We used human-centered and user-centered almost interchangeably.

I believe that’s about to change. As agents take on more work inside software, the person who wants an outcome and the user operating the system won’t always be the same.

The human is still the reason the work matters. But the human may no longer be the one using your product.

By “agent,” I mean AI software that takes actions on someone’s behalf. You explain what you need to an assistant. When that assistant uses another product to get the job done, it becomes that product’s user.

1. The signals are already here

The plumbing for agent users is being built. The Model Context Protocol, which lets AI systems connect to tools and data, now sits under the Linux Foundation’s Agentic AI Foundation, and was reported as adopted by more than 10,000 servers at launch (Campus Technology). Instacart launched a full grocery app inside ChatGPT, built on the Agentic Commerce Protocol from OpenAI and Stripe (eWeek, Digital Transactions).

Your product may not have agent users yet. But you can start asking what they’d need to use it successfully.

2. One grocery order, two experiences

Imagine telling an assistant: “Plan five easy dinners for two. Use my pantry list, keep it under $100 including fees, and ask before buying.” It replies with five meals for $94 and asks if that sounds good.

For you, that’s a conversation: review, adjust, approve. Underneath, the agent has a different experience. It has to find products, interpret quantities, check availability, and prepare an order.

Then the questions begin. Does “quantity: 1” mean one banana, one bunch, or one pound? Is the price current? Was the item reserved or just added to a cart? If checkout times out, did the purchase fail or succeed silently?

A person might clarify the quantity by looking at a product photo, or check a confirmation email before trying checkout again. An agent needs a dependable way to find those answers, too. A polished storefront can still be confusing for the system trying to shop there.

3. Isn’t this just API design?

Partly, and good API design is the foundation. Engineers already handle things like clear errors and safe retries. What UX adds is the whole-journey view: what the agent is trying to accomplish for the person, where its understanding breaks down, and how that breakdown affects the human it serves.

This isn’t only a consumer story. Picture a buyer’s agent reordering supplies from your vendor portal, or a support agent reading your help center to resolve a ticket. If pricing, status messages, or permissions are ambiguous, the agent stalls, and so does your customer.

4. Agent success isn’t human success

An agent could complete checkout while choosing meals the person dislikes. It could stay under budget by buying too little, or cut interruptions by deciding things the person wanted to approve.

Humans still have to define what a good outcome is, whose interests the system serves, and which decisions need a person. Agents will likely help test and refine these experiences too, but defining success stays human work.

An experience can work perfectly for an agent and still fail the person behind it.

5. The business questions

Agent users change the economics, so these need answers:

• Incentives: an agent may complete the job without browsing the screens where you show ads, upsells, or promotions. If revenue depends on that attention, what happens when the human delegates?
• Trust and risk: how do you authenticate agents, set permissions and rate limits, and decide who is liable when one misbehaves?
• Measurement: track agent task completion and recovery alongside your human metrics.
• Ownership: who owns the agent experience? Product, engineering, or design? Or one AI-enabled role? My bet: tomorrow, that role could belong to sales.

Start small. Pick one high-value flow and ask: if an agent used it tomorrow, where would it get stuck first? Look for ambiguous units, unclear status, and actions that aren’t safe to retry.

In my last post, I argued that the human interface will shrink as software takes on more coordination. This is the other side: the interactions underneath will expand.

So we’ll need to ask two questions every time we design a system. Who is using it? And whose life is supposed to improve when they do?

Image by Growtika on Unsplash.