In-house programme

Designing agentic AI into your journeys.

Your organisation has decided to put AI agents into the product. What nobody has decided is where the agent belongs in the journey, when it should hand the user to a person, and what that handoff should feel like from both sides. This is a one-day, in-house programme that answers those questions against your own service, not a generic demo.

Enquire about training All in-house programmes

Who this is for

Built for teams already shipping agents.

This is not an introduction to AI. It assumes your team already knows it is building agentic features and needs to make specific design decisions about them.

•Established design teams shipping agentic features.
•Product managers and engineers designing agent behaviour without a designer in the room.
•Service and content designers whose journeys now include a non-deterministic step.
•Teams with a mature design system whose gap is upstream of the interface.

What the day covers

Six things you have to get right.

Run against your own live journey, not a hypothetical one.

Where an agent belongs, and where it does not

We map the journey first, then identify the specific steps where an agent genuinely reduces effort for the user, versus the steps where it adds a layer between the user and the thing they came to do. Not every step is a candidate, and treating them as if they were is the most common early mistake.

The handoff to a human

This is the central design problem of an agentic journey. What triggers the handoff, what context carries across with the user, how the user is told it is happening, and what the human on the other end actually receives. Handoffs that lose context on the way through are the most common failure we see, and the hardest to notice until a real user hits one.

Trust, error and recovery

What a user needs to see before they will trust an agent's output, how to design deliberately for the agent being wrong some of the time, and how a user takes back control of a task the agent has started.

Designing for non-deterministic behaviour

What changes when the same input can produce a different output each time. We cover how to design, write and review the states you cannot fully specify in advance, and how that changes the way a design is documented and signed off.

Testing an agentic flow

Usability testing assumes a system behaves consistently between sessions, and an agentic one does not. We cover how to structure tasks around that, what to measure instead of a single pass or fail, and how many sessions actually tell you something.

Making the case internally

The day's decisions only matter if they survive contact with stakeholders. We close by turning what you have decided into an argument you can take back into the business, with the tradeoffs made explicit rather than left implicit.

What you leave with

Artefacts, not just a good discussion.

•A mapped journey with the agent's role marked on it.
•A documented handoff design for at least one real flow from your product.
•A set of trust and recovery patterns your team agreed on together.
•A testing approach you can run without external recruitment.

Day, run against one of your own live journeys

Maximum participants per session

Delivered across the UK and internationally

£600

Per person for onsite, customised multi-day training

Common questions

Before you enquire.

When should an AI agent hand off to a human?

There is no universal rule, and part of the day is building one for your own service: usually the trigger is some mix of the agent's own confidence, the stakes of getting the step wrong, and whether the user has signalled they want a person. We work through your journey to decide where that line sits for you, rather than importing someone else's answer.

How do you test a flow when the AI gives a different answer each time?

You stop treating a single session as representative and design the test around a range of plausible agent responses instead of one script. We cover how to pick tasks that expose the range, how many sessions you actually need, and what to measure when "did they complete the task" is not a stable enough signal on its own.

Do our designers need to know how to build AI to take this?

No. This is a design and product training, not an engineering one. You do not need to know how the underlying model works to make good decisions about where it sits in a journey and how it behaves toward a user.

Can this be combined with UX research or service design training?

Yes. It is often run as a second day alongside a UX research day, since testing an agentic flow properly is itself a research skill. Tell us on the form below and we will scope both days together.

Get in touch

Enquire about this programme.

Tell us about your team, the journey you want to work on, and your preferred timing. We will get back to you within 2 business days.