Agent Experience Design, since March 2025

I was writing about AX Design in March 2025, before it became a job title. Practicing it since then taught me what the original post could not have known.

On March 13, 2025, I published a post on emerging UX specializations. Agent Experience Design was first on the list. My words at the time were: “AX designers focus on creating experiences FOR these AI agents rather than humans. Think about it: How does an AI agent ‘experience’ interfaces? What feedback mechanisms work best? How do we design for entities that think differently than humans?”

The date stamp shows something narrow and useful: I was treating AX as a design discipline worth practicing before “Agent Experience Designer” appeared as a live job title anywhere I could find one. Seventeen months later, companies are hiring for the title. The more interesting story is what sustained practice since March 2025 taught me.

What the term meant, and what practice required

The easy version of Agent Experience Design is “design the UI an agent uses.” That is not wrong, it is just small. The real version turned out to be an operating model question: when you hand real work to something that drafts fast and does not inherently know when it is wrong, where do you put the checkpoints, who owns the correction, and how do you keep speed from quietly outrunning accountability?

I learned it building a five-agent product team that shares one vault as its memory. Maren does user research: she processes interview notes and labels every theme by signal strength, strong at three or more sources, moderate at two, weak at one. Reid is the strategist, tracking hypotheses as untested, testing, validated, or invalidated, and weighing research signal strength over stakeholder loudness. Ava is the product designer, forming design positions and translating decisions across research, strategy, and engineering. Kai is the project manager, tracking delivery risk and dependencies. Syd is the engineer, building from spec and flagging ambiguity instead of quietly redesigning around it.

Five lenses instead of one blended assistant sounds like a small choice. It is not. It is the same design decision restated five times: do not let a system generate confident, plausible answers to questions it was not built to answer.

Signal maturity gates and the disagreement protocol

Two mechanisms did more to define Agent Experience Design in practice than anything I could have written in a single post.

Signal maturity gates require a design decision to cite at least one moderate or strong research signal before it can be accepted. Sprint scope needs its key assumptions to be testing or validated, not just asserted. Engineering handoff waits until the design decision behind it has passed the gate. This slows down the right thing: decisions built on vibes instead of evidence.

The disagreement protocol is the part I would point to first if someone asked what Agent Experience Design looks like day to day. When two agents disagree, the system does not quietly average their positions into something smooth and wrong. It surfaces both, logs the conflict, and asks me to make the call. Disagreement is not a failure state. It is the place where judgment becomes visible, which is the point of putting a human in the loop.

Proof at executive stakes: the AI-native SDLC

The five-agent product team is where I built the discipline. The AI-native SDLC case study is where I ran it at a stake that mattered. When Tebra was weighing a platform migration, I did not just draft a position and hand it up. I drafted a claim, handed it to independent AI agents whose only job was to break it, one auditing every citation live and one steelmanning the strongest opposing read, and adjudicated the conflict into a hardened document before it reached leadership.

Over six days that produced at least fifteen adversarial and validation reports. In one pass, 38 external URLs and 31 quotes were checked live, and a fabricated quote got caught and pulled before it reached an executive-bound export.

That is Agent Experience Design applied to my own arguments, not just to a product surface. The autonomy gates I helped define for that migration, agents never deploy to production, every run gets a typed contract and a mandatory dry-run, every applied change leaves an audit trail, and browser verification is required before the work counts as done, are the same instinct as the disagreement protocol in a production engineering context. Speed never outruns the ability to check the work.

The most recent proof point: a blocker caught before ship

This week I built ds-canon, a design-system-of-record MCP server, with parallel builder agents working the implementation at the same time. That is the unglamorous half of Agent Experience Design: give each agent a clear lane and let them move in parallel instead of serializing everything through one thread.

The part worth writing about is what happened before it shipped. The build came back with green tests and a clean integration run, and then adversarial challenger agents reviewed it with no job other than to find what was wrong. They caught a real one: a fuzzy-matching routine with no input bound, which meant a single oversized lookup could freeze the entire server. Green tests never would have surfaced it, because nobody writes a test for the input they did not imagine. It got fixed in an automated pass before the repo went public, along with six more findings serious enough that I would not ship without them.

This is a small, current, verifiable instance of the same discipline running end to end, from a five-agent product team to an executive-stakes migration decision to a design-tooling artifact. Different stakes, same operating model.

What I would tell March 2025

The term was right. What I did not know yet was how much of the discipline would turn out to be about catching my own claims before anyone else had to, not about the agents at all. Seventeen months of practice taught me that Agent Experience Design is not primarily about designing what the agent sees. It is about designing what happens when the agent, or I, gets it wrong, and making sure that moment is loud, logged, and reviewable instead of quietly smoothed over.

Spotting a discipline gets you a sentence. Operating one produces months of decisions nobody sees unless you write them down. This is me writing them down.