Agentic Experience Design
Designing for systems that act on their own
- Role
- AI Lead, framework author
- Scope
- Global design studio, position on agentic AI
- Output
- Autonomy scale, design process, adoption plan
Every AI feature we shipped was a tool waiting to be asked. The next generation will not wait. It sets goals, plans, acts, and adapts. Our design practice had no language for that, so I wrote one.
AI Agent
A software worker that uses AI to do a task when asked.
This is what most products ship today. The human decides, the tool executes, the loop closes immediately.
Agentic AI
A system that sets or interprets goals, plans multiple steps, acts, and adapts with minimal micromanagement.
The human no longer operates it. The human supervises it, which is a different job and needs a different interface.
UX optimises how humans operate tools. AX optimises how tools act in the world, with the human as supervisor.
The autonomy scale
Assistance and autonomy are not two states. They are five, and a product can sit at a different level in each of its flows.
Teams kept arguing about whether a feature was "agentic", which is an unanswerable question. The scale replaced it with a usable one: at which level does this flow operate, and what does the interface owe the user at that level. Each step moves a decision from the human to the system, so each step has to give something back in exchange: visibility, control, or a way out.
L0 Manual
User
Has full control.
Agent
Not involved.
L1 Preview
User
Drives the action and makes all decisions.
Agent
Executes requests and highlights improvements.
L2 Execute
User
Approves a plan and delegates.
Agent
Runs the full sequence once validated, reporting on each goal.
“Print this webpage double sided.”
L3 Managed
User
Defines policies and oversight conditions.
Agent
Acts inside those rules, handles exceptions, escalates when needed.
“You manage all document printing this month. Budget $25. No colour unless urgent.”
L4 Adaptive
User
Sets goals and observes outcomes.
Agent
Learns from results and adjusts long term behaviour within constraints.
“Reduce printing costs this quarter without hurting output.”
Why MCP changes the brief
A protocol decision that turns out to be a design decision.
Model Context Protocol is an open standard that lets AI models connect directly to data, tools, and systems. Without it, a model only knows its training data and whatever you paste into a prompt. With it, a model can fetch live data, call APIs, reach devices, query databases, and trigger actions in other systems.
That is a plumbing detail until you notice what it does to the brief. The moment a product exposes itself through MCP, it stops being something a person opens. It becomes something other software can operate, at any hour, without a screen. Designing the screen is no longer enough. You are designing the behaviour, the limits, and the record of what happened.
T.R.A.C.E.
A design process for work that happens without anyone watching.
Our process assumed a user present at every step. Agentic work is not like that: it runs while nobody is looking, and the design question moves from "what does this screen show" to "what does this system owe the person who is not watching". T.R.A.C.E. gives five stages, and a design responsibility at each one.
Target
- Purpose
- Define user goal and context
- Agent
- Understand desired outcome and constraints
- AX Design
- Define how the agent interprets goals, context and constraints. Establish initial guardrails and permissions.
Route
- Purpose
- Propose a strategy
- Agent
- Suggest steps, sequence or approach
- AX Design
- Shape how the agent presents its plan and explains decisions. Design checkpoints and safe confirmation moments.
Act
- Purpose
- Execute plan
- Agent
- Carry out steps, interact with systems
- AX Design
- Ensure the agent can act safely: pause, cancel or rollback when needed. Provide real time feedback to keep users aware.
Capture
- Purpose
- Report outcome and traceability
- Agent
- Log what was done, when and why
- AX Design
- Define how the agent records and shares what happened. Design transparent logs, outcomes and receipts.
Evolve
- Purpose
- Learn and adapt over time
- Agent
- Use feedback to improve and adjust
- AX Design
- Use captured data to refine behaviour and adapt guardrails. Keep adaptation transparent and controlled.
Each stage carries a design responsibility, not just an engineering one.
What it looks like in practice
Three everyday flows, redesigned as agentic experiences.
Receipt to expense
The user photographs a receipt. The agent reads it, checks it against policy for caps and duplicates, then creates and submits a draft claim with the image attached, logging IDs and costs, with a short rollback window.
Card to CRM lead
The user photographs a business card or handwritten notes. The agent parses the contact and company, de-duplicates, creates the lead, and offers to send a templated intro, with a grace period to cancel.
Monthly budget snapshot
At month end the agent reads bank feeds in read-only mode, summarises spend against goals, saves a one page PDF, prints one copy, and shares a link, pausing on anomalies.
The pattern repeats in all three. The agent does the work, but every one of them carries a policy check, a record of what happened, and a way for the human to undo it. Those three things are the design work. Without them the feature is not trustworthy, no matter how good the model is.
Five moves to make the practice real rather than theoretical.
Map what exists
Audit current experiences against L0 to L4 and T.R.A.C.E. Find the missing capabilities and the gaps in autonomy.
Design the guardrails
Define feedback loops, checkpoints, permissions, recovery paths, and rollback policies. Autonomy is only safe if these exist first.
Open the products
Expose devices and services through MCP and APIs so they are reachable by models and external agents.
Design agents as roles
Give each agent a role, tasks, boundaries, and a recovery strategy. Treat them as personas, not features.
Prototype for real
Build and test agentic scenarios against real products and real customer needs, not slideware.
Framework, autonomy scale and T.R.A.C.E. process written by me, and presented to design and product leadership.
Product specifics have been left out of this page. Happy to go deeper in conversation.
