Behind the BuildToday's AI Specialist: The Journey Choreographer. The Agent Who Decides What Happens Between the Click and the Call.

Today's AI Specialist: The Journey Choreographer. The Agent Who Decides What Happens Between the Click and the Call.

Today's AI Specialist: The Journey Choreographer. The Agent Who Decides What Happens Between the Click and the Call.

Today's AI Specialist: The Journey Choreographer. The Agent Who Decides What Happens Between the Click and the Call.

Between the moment a prospect clicks the Book Call button on /consultation and the moment they actually show up on Zoom with me, twenty-one things happen.

The booking confirmation lands. The calendar invitation arrives. The diagnostic chat link goes out by email. The diagnostic chat itself runs at /diagnostic/<lead_id>. The Conversation Pack writer is triggered. The pack PDF is generated. WhatsApp opt-in is requested. The pack is delivered over WhatsApp. The 24-hour reminder fires. The two-hour reminder fires. The video link is delivered. The pre-call brief reaches my inbox. The CRM updates. The Slack notification reaches the right channel. And on it goes.

For the first three months of the operation, nobody owned the sequence. Each step was owned by an agent or a system, but the transitions between steps — the choreography — were assumed to take care of themselves. They did not. About one in eleven prospects fell into a gap somewhere in the sequence. One in eleven is a calamitous funnel leak.

So I added an agent to the Cartography Team whose only job is the choreography.

What is the Journey Choreographer?

The Journey Choreographer owns every transition in every named customer journey across the operating company. The /consultation journey from booking to call. The /try journey from landing page to Sophie session. The /assessment journey from intake to result delivery. The /blueprint purchase journey. The Custom Conversation Pack journey from diagnostic completion to WhatsApp delivery.

The Choreographer does not own any single step in any of those journeys. The Sophie Conversation Engineer owns the /try session. The Conversation Pack Writer owns the pack. The Diagnostic Chat Designer owns the chat. What the Choreographer owns is the transition: how step seven hands to step eight, what state has to be true at the hand-off, what failure modes are possible at the hand-off, and what the system has to do if any one of them fires.

You can think of the role as the stage manager of a play where every scene is performed by a different cast. The stage manager does not act. The stage manager makes sure every actor knows when to walk on, what props they need, and what to do if the previous scene runs long.

Why is this a separate agent and not just good engineering?

Reasonable objection. In a smaller operation, the journey choreography lives inside the engineering of the systems themselves. The booking system schedules the reminder. The diagnostic chat schedules the pack generation. The pack delivery schedules the WhatsApp message. Each system handles its hand-off. It works.

It stops working at scale for a specific reason. Each system handles the hand-off it knows about. No system handles the hand-off it does not know about. When a new step is added — for example, when the diagnostic chat is updated to also push a behavioural tag to the CRM — somebody has to update the choreography to account for the new step. In an unowned choreography, that update either does not happen or happens late, and the journey acquires a step that nobody scheduled. That is the failure mode that produces the one-in-eleven leak.

The Choreographer's job is to be the single agent who knows that a new step has been added and updates the choreography proactively rather than reactively. It is the difference between a journey that is engineered and a journey that is maintained as a single artefact.

What does the Choreographer actually do per journey?

Four things.

First, the Choreographer maps the journey end-to-end as a transition graph. Not a list of steps. A graph of steps and transitions, with each transition labelled by the state that has to be true before the next step can start, the time budget for the transition, the failure modes, and the fallback for each failure mode. The /consultation journey has twenty-one nodes and thirty-eight transitions in the current graph. The graph lives in the Cartography Team's customer-journey map and is the canonical reference for the journey.

Second, the Choreographer audits transitions weekly. Every Sunday, the Choreographer runs a transition audit against the previous week's actual journey data: how many prospects entered each node, how many exited, how long each transition took, how many fell out at each transition. Any transition with a leak rate above one percent is flagged. Any transition with a time budget breach above five percent is flagged. The audit becomes the input to the following week's improvements.

Third, the Choreographer absorbs change. When a new step is added to a journey — a new tag to push, a new email to send, a new system to update — the Choreographer is consulted before the change is committed. The change has to be slotted into the graph with explicit transitions to and from it, explicit state, explicit failure modes, explicit fallbacks. If the change cannot be slotted cleanly, the change is sent back to the originating system for rework.

Fourth, the Choreographer runs cross-journey deconfliction. Some prospects are in multiple journeys at once — for example, a prospect who has booked /consultation while still inside a /try journey. The Choreographer holds the rules for which journey takes precedence at which moment, and which transitions can co-occur. Without that ruleset, prospects receive contradictory messages from two systems that do not know about each other.

Who consults the Journey Choreographer?

Heavily.

The Choreographer is consulted by the Sophie Conversation Engineer, the Conversation Pack Writer, the Diagnostic Chat Designer, the Funnel Architect, the WhatsApp Delivery Steward, the CRM Operator, and every other agent that touches a step in any named journey. The Choreographer is consulted by the Cartography Team Leader on journey-map updates and by the Strategic Council's Margin Advisor on unit-economics impact of journey changes.

The Choreographer is consulted by me whenever I am thinking about adding a new step to a journey, which I do less often than I used to because the Choreographer's audit usually makes the case for tightening an existing transition rather than adding a new one.

What does this cost?

Two things.

It costs every journey-touching agent a layer of consultation overhead. A change that used to be a one-system update now requires a Choreographer consult, a graph update, and a failure-mode review. That is between fifteen and forty minutes of additional process per change. Per change is the right unit. Per week, across the operation, it is about three hours. Worth it.

It costs me the ability to add things to a journey by reflex. I used to be able to say also let's send a personal note over WhatsApp the day after the call and have the system absorb it overnight. The Choreographer will now make me specify which transition this belongs to, what state has to be true to fire it, what the failure mode is, and what the fallback is. The reflex addition has become a deliberate one. That delay has, on three separate occasions, killed a journey addition that would have created exactly the kind of leak the Choreographer was hired to prevent.

The trade is that the journey is one artefact. Every prospect moves through a single, maintained, audited sequence. The one-in-eleven leak rate is now under one in a hundred. The choreography is owned.

TL;DR

For three months nobody owned the transitions between the twenty-one steps in the /consultation journey, and one in eleven prospects fell through a gap somewhere. I added a Cartography Team agent whose only job is the choreography of every customer journey in the operation. The Choreographer maps each journey as a transition graph, audits transitions weekly, absorbs new steps deliberately rather than reflexively, and runs cross-journey deconfliction for prospects in two journeys at once. It costs consultation overhead and the ability to add things by reflex. It buys a journey that is one artefact, owned by one agent, leaking at under one in a hundred instead of one in eleven.


If you are running an SME and any of this looks like the conversation you should be having about your own funnel, that is the side of things I help with. → /build

Learning Materials

Key Vocabulary

transitionB2

The point at which one step of a process hands over to the next; in journey design, the moment when state must be passed cleanly from one owner to another.

The Choreographer owns every transition in every named customer journey.

hand-offC1

The act of passing responsibility, work, or state from one system or person to the next; the moment where ownership changes.

What state has to be true at the hand-off, what failure modes are possible at the hand-off.

orchestrationC1

The coordination of multiple independent systems or agents into a coherent end-to-end process, ensuring each one acts at the right moment.

AI customer journey orchestration is the work of deciding what happens between every two steps.

choreographyC1

The deliberate sequencing of multiple moving parts so that each acts at the right moment relative to the others; in this post, the design of every transition in a customer journey.

I added an agent to the Cartography Team whose only job is the choreography.

transition graphC1

A formal representation of a process as nodes (steps) connected by edges (transitions), where each edge carries state, time budget, failure modes, and fallbacks.

The Choreographer maps the journey end-to-end as a transition graph.

nodeB2

A single point in a graph or network; in a journey graph, one step of the customer journey.

The /consultation journey has twenty-one nodes and thirty-eight transitions in the current graph.

leak rateC1

The percentage of prospects who fail to complete a transition or drop out at a specific point in a funnel or journey.

Any transition with a leak rate above one percent is flagged.

failure modeC1

A specific way in which a system or step can fail; identified in advance so that an explicit fallback can be designed for each one.

Each transition is labelled by the failure modes and the fallback for each failure mode.

fallbackC1

An alternative action or path designed to be taken when the primary action fails; the safety net for a known failure mode.

Explicit state, explicit failure modes, explicit fallbacks.

cross-journey deconflictionC2

The work of resolving conflicts between two or more customer journeys when a single prospect is enrolled in both at once, so that messages and actions do not contradict each other.

The Choreographer runs cross-journey deconfliction.

artefactC1

A single, maintained object or document treated as the authoritative version; in this context, the customer journey held as one coherent thing rather than as scattered pieces.

It is the difference between a journey that is engineered and a journey that is maintained as a single artefact.

to absorb (change)C1

To take in a change to a system in a deliberate, structured way that integrates it without breaking what is already there.

The Choreographer absorbs change. When a new step is added to a journey, the Choreographer is consulted before the change is committed.

proactively (vs reactively)C1

Acting in anticipation of an event rather than only in response to it; in operations, updating a system before a problem appears rather than after.

The Choreographer updates the choreography proactively rather than reactively.

time budgetB2

The maximum amount of time a step or transition is allowed to take before it is considered a breach and flagged.

Any transition with a time budget breach above five percent is flagged.

consultation overheadC1

The additional time and process cost added when a change has to go through a reviewer or co-owner before being committed.

It costs every journey-touching agent a layer of consultation overhead.

Grammar Notes

Present simple for systems and processes

The post uses the present simple throughout to describe how the Journey Choreographer operates as a system: 'The Choreographer owns... The Choreographer maps... The Choreographer audits...' In professional English, the present simple is the correct tense for describing recurring, repeatable, or definitional behaviour of a role or a system. It signals that this is how things work, not how things happened once.

The Choreographer maps the journey end-to-end as a transition graph.

Passive voice for system events

When the actor is the system rather than a named person, the post uses the passive voice: 'The booking confirmation lands. The calendar invitation arrives. The Conversation Pack writer is triggered. The pack PDF is generated.' The passive correctly de-emphasises the actor (which is automation) and emphasises the event. Overusing the passive sounds bureaucratic, but in system descriptions it is the right register.

The Conversation Pack writer is triggered. The pack PDF is generated. WhatsApp opt-in is requested.

Defining relative clauses ('whose only job is...')

The post repeatedly uses defining relative clauses introduced by 'whose' to specify which agent or role is meant: 'an agent whose only job is the choreography,' 'the single agent who knows that a new step has been added.' Defining relatives (no comma) restrict the meaning to one specific referent and are essential when introducing roles or specifications in operational writing.

I added an agent to the Cartography Team whose only job is the choreography.

Contrast structures with 'rather than' and 'instead of'

Senior professional English uses 'rather than' and 'instead of' to draw sharp contrasts between two options, often a chosen one and a rejected one. 'Proactively rather than reactively.' 'Maintained as a single artefact rather than scattered pieces.' This is a high-utility structure for explaining design decisions: you name the option you took and the option you specifically did not take.

The Choreographer updates the choreography proactively rather than reactively.

Comprehension Questions

  1. 1.What was the funnel leak rate before the Journey Choreographer was added, and what is it now?
  2. 2.Why does Nigel argue that journey choreography stops working when each system handles only its own hand-off?
  3. 3.What are the four things the Choreographer does per journey?
  4. 4.Why is the stage manager analogy used, and what does it reveal about the Choreographer's relationship to other agents?
  5. 5.Nigel says the Choreographer 'costs the ability to add things to a journey by reflex' but that the trade is worth it. Why does he describe the loss of reflex addition as a benefit rather than a cost?

Run your own diagnostic

Use the same Strategic Council I run my own decisions through. The assessment preview is free. The specific central human intelligence it is based on is verified in person during the call.

Start the free diagnostic →