Flavio Lamenza · 2026

Beyond UX

AX
Designer

Agentic Experience - The Business Detective

Every mature technical field eventually splits in two: one role that owns the investigation and judgment, one that owns the execution and craft. AX hasn't named its investigation role yet. It will. And the organisations that hire for it now will be ahead of the ones that wait for the field to define it.

Scroll

The argument

The agentic experience ecosystem will grow exponentially in the following years. This is how the AX Design fits into it.

01

Every field that scales eventually splits.

It always happens the same way. A new technical capability emerges. Early practitioners do everything, the thinking and the building. Then the field matures. The thinking and the building separate into two distinct roles, because the skills required are genuinely different. One role owns the investigation and judgment. The other owns the execution and craft. Neither is lesser. But they are not the same job.

Back end + Front end Data scientist + Data engineer DevOps + Developer Researcher + Designer Strategy + Operations UX + UI ← AX Designer + AX Engineer ←
02

The value in AX Design is not in the tool. It's in the investigation.

A business implementing an agentic strategy doesn't fail because the technology isn't good enough. It fails because nobody formally asked: which processes are actually worth automating? What are the implicit rules governing this workflow, the ones that live in someone's head, or in a confluence document? Those are starting questions. And they have to be answered before a single agent is built, not discovered after it breaks.

03

The AX Designer is the person who asks those questions.

Not the engineer building the agent platform. Not the consultant selling the transformation. The person embedded in the business who investigates processes, surfaces implicit rules, specifies what correct execution looks like, and designs the evidence trail that proves it's working. The same way a UX Designer investigates human experience problems, the AX Designer investigates business process problems. Same underlying skill. Different crime scene.

The pattern

Pairing is common ground.

In every pair, the investigation role is harder to hire for, harder to evaluate, and slower to produce visible output. That's why it gets absorbed or ignored when a field is young and moving fast. It's also why the organisations that explicitly protect it end up with better outcomes.

Investigation & Judgment
Execution & Craft
UX Designer
UI Designer
Data Scientist
Data Engineer
Researcher
Product Designer
Strategist
Operations
Product Manager
Tech Lead
AX Designer · The Business Detective
AX Engineer
There are unicorns who do both. They are rare, they are expensive, and they usually end up doing one better than the other anyway. Most organisations are better served by naming both roles explicitly and hiring for them deliberately.

The methodology

What the investigation actually involves.

Every business process an agent might automate has the same underlying structure: there are implicit rules governing it, a human executing it slowly and expensively, and an open question about whether an agent can do it reliably at scale. The AX Designer's job is to answer that question rigorously, before the agent is built.

Step 01 - Observation
Map the process as it actually exists
Not as the documentation says it works. Not as the manager thinks it works. As the people doing it every day actually run it, including the exceptions, the workarounds, and the rules that live in someone's head. The implicit rules are where agents fail.
"What happens when a required field is missing? What's the edge case you've never written down?"
Step 02 - What's the problem?
Determine if automation is the right answer
Not every process should be automated. Some are too variable. Some carry legal or ethical weight that requires human judgment at every step. Some are cheap enough that automation cost exceeds the gain. The first question isn't "how do we automate this?" It's "should we?"
"What are the failure modes we haven't anticipated? Who is accountable when the agent gets it wrong?"
Step 03 - Mapping it out
Agent journey maps
What the human delegates and where they retain oversight. For agent-only flows, a showcase of what the agent perceives, decides, and acts on, including ambiguity points, fallback paths, and escalation conditions. This is what gets the everyone on the same page before anything is built.
"At which point does the agents need a human? What happens when it doesn't know what to do?"
Step 04 - Prototype governance layer
Specify the solution
Before building or optimising anything, someone has to make the opportunity visible with a document, a flow, a before/after, and/or a business case with a clear picture of the end state. That's the artefact that gets the organisation aligned and gives the agents something worth building.
"How do we make the unknown known?"

What I bring

The skills aren't new. The context is.

The AX Designer role requires a specific combination of capabilities. I've been building them for over a decade under a different name, in a different context. The translation is direct.

🔍
Business process investigation
7+ years of UX research taught me how to extract implicit rules from complex systems, interviewing stakeholders, mapping journeys, finding the gap between what people say they do and what they actually do. That's the core AX skill.
📊
Evidence-based judgment
I led a Data Guild initiative that connected every design decision to measurable business outcomes. I know how to build the case for a decision and how to design the evidence trail that proves it was right. Data levels the playing field and removes subjectivity.
🏗️
Systems thinking
I've steered work across TV interfaces used by 3M+ customers, where a single decision in one area creates consequences in five others. I'm trained to see the full system.
💬
Stakeholder translation
I bridge business goals and technical execution running workshops, writing specs, presenting to C-level. The AX investigation is worthless if it can't be communicated. I've spent a decade making complex decisions legible to the people who need to act on them.
⚠️
Failure-mode thinking
The 1M contact centre calls case study is a masterclass in what happens when implicit business rules aren't formally specified. I mapped it, worked with research, built the evidence, and changed the outcome.
🧭
Design vision
I don't just describe problems, I workw with the team to propose what great looks like. From the Golden Journey prototype to the Sports framework, I helped frame the opportunity and make the vision tangible. The team needs to see the flag in the sand.

The position

"The organisations that move first won't just have better AI. They'll have someone who asked the right questions before the agent was built. Direction is more important than speed."