Eight weeks before Nike After Dark Tour London, a night 10K at ExCeL London on Saturday 17 October 2026, thousands of runners signed up and started training. On day one of that training block we launched a coach in their pocket: an AI assistant that lived in WhatsApp, because that’s where people already are, and nobody wants to download yet another app for a race.
It wrote personalised training plans, it cheered people on, it gave them a nudge when they went quiet, and it replied properly to voice notes, screenshots, selfies and an awful lot of emojis. The idea was that it should feel like chatting to your mates, using everything WhatsApp can do, except one of your mates happens to know a lot about running and talks in Nike’s cheeky, slightly savage tone of voice.
I was the technical lead and the only developer on it at R/GA, working with a very small team: Johan, our creative in the London office, and Clem, the strategist whose research everything else ended up depending on. The team was, quite literally, smaller than the firing squad of Nike lawyers we had to stand in front of, more than once, to convince them to let this thing loose on the public.
Simple on the surface
You might look at it, like we first did, and think it’s easy: connect ChatGPT to WhatsApp, upload a few files about the race, job done. It turns out there’s a lot more to building something robust, secure, safe and legally compliant on top of a technology as unpredictable as AI.
WhatsApp handled the interface, and OpenAI’s Luna model did the thinking. We had to build everything in between. Every message goes through layers of guardrails before and after the model sees it: a jailbreak detector, a check that the runner is actually asking about running and not trying to make it say something daft, and a final read of every reply before it’s sent, which quietly regenerates it if it crosses a line. Each layer can be flipped between “block” and “just watch and log” at runtime, so we could see how it behaved with real people before letting it start refusing things. When it recommends a product, it searches the real After Dark product line rather than making one up, because an AI that invents a shoe, or tells someone with an injury to just push through it, is a brand problem waiting to happen.
Behind that sits an admin panel so the Nike team could steer it without me: the master prompt (versioned, with one-click rollback, because someone will always break it on a Friday), the product catalogue, libraries of images, voice notes and links the coach can send, the guardrail definitions, analytics, and a kill switch that takes the AI offline instantly without a deploy.
And a coach that only speaks when spoken to isn’t much of a coach, so the platform runs the outbound side too. It imports race registrations, builds audience segments and schedules broadcasts across the training block (“it’s week four, here’s your long run”). The rules for that were written into the system rather than left to anyone’s memory: nothing goes to runners until it has gone to an internal test group first, and STOP actually stops.
Then there’s the part nobody sees. Once real registrations were imported, every mistake became a mistake against a real person, so: only the public-facing piece can be reached from the internet, there’s a web application firewall in front of everything, personal data stays out of the logs, and there are backups with point-in-time recovery, a disaster-recovery plan and a retention policy. It went through a penetration test and Nike’s own information-risk review before launch. None of that is glamorous, but it’s the difference between something that impresses people in a meeting and something you can actually switch on. (It’s also the work I now do for other people as Prototype → Production.)
Dozens of dials
Inside all of those components there are a huge number of variables you can dial to change how the assistant behaves: tone of voice, how personal it gets, which topics it refuses, how often it broadcasts, how much each reply costs in tokens, how fast and how accurate it is, when it escalates to a human.
Take tone of voice. Johan is a master of it, and he knows better than anyone that every push you give in one direction gets you a pull in the other. Make it more savage and it gets less supportive. Make it chill and it stops being relentless. There’s a real art to nursing those characteristics, bit by bit, until the outputs start to feel right.
Hitting the wall
So I built Johan a tool that let him do the dialling himself. It started with tone of voice and ended up covering much more. He’d tweak the inputs, chat with the assistant, judge what came back, then go round again. And again. Endlessly. It drove him up the wall, and slowly, a little bit, insane.
That’s when we realised that testing and tweaking this way wasn’t going to work. We had a few weeks, a small budget and a smaller team, so we needed a different idea.
How do you test something with infinite paths?
We stepped back and defined the problem. With a traditional experience, say an ecommerce site, testing is linear: put something in the basket, go to checkout, hit buy. Did it work? Yes or no.
When AI is the experience, the possible journeys are endless, and every runner’s relationship with the coach drifts further from the shared starting point the longer it goes on. The same input doesn’t even give you the same output twice. You can’t click every path.
Enter the swarm
So we made an army of synthetic testers, thousands of them, each with their own persona. Clem and the strategy team had already done the research: we knew the range of people signing up, what they liked, what scared them, how much running they’d done before. With Claude’s help, we turned that research into people.
Sally, 28, from Brixton, has never run a 10K and is scared she’ll embarrass herself by not finishing. Jennifer, 35, is coming back to running six months after giving birth and wants to beat her PB. And so on, thousands of times over, across runners who are on track, who need a nudge, who are at risk of giving up, and who’ve already dropped off.
We built them a sandbox: a WhatsApp simulator, wired up to the real assistant, in which we could manipulate time. Eight simulated weeks ran in minutes. The synthetic runners talked to the coach, shared their fears, asked for encouragement, and, most importantly, found the flaws in our system: holes we needed to fill and dials that needed more tuning.
It ran itself
The first run was brilliant. We got a stack of reports and knew exactly what to fix. But then what? We’d need to run it again, obviously. So we turned it into a loop.
That loop ran continuously, not just in the run-up to launch but all the way through the live campaign. Once real runners were on it, their conversations went into the mix too and got scored for real, so we always knew what the coach was doing well and where it could do better.
Some of the improvements came from Johan reading the reports and using his very human judgement to keep turning the dials in the right direction. But a lot of what surfaced was housekeeping that didn’t need a human touch, and for that the system did the tuning itself. So, with a human in the loop for the things that mattered, it kept improving itself all the way up to race day.
How did we do?
Going in, because AI is unpredictable, we made sure Nike knew the coach wouldn’t get everything right every time. There’d be questions it couldn’t answer with confidence, and features people wanted that we hadn’t thought of. We did some research and set 80% as our benchmark for a successful request.
After the race we analysed every conversation from real runners. Across eight weeks live, the coach hit 97%.
The finish line
And a special shout-out to Clem, who laid the foundations of insight the whole system depended on, and then went and ran her first 10K on race night, with a little help in training from the cheeky, savage coach in her pocket. She loved it. So did the runners. And this is just the start line.
Building it with AI
The coach was built with AI, as well as being AI. I built it in Claude Code, Anthropic’s command-line coding agent, which did a lot of the typing while I kept the deciding for myself, which is how one developer covered what would normally be a backend developer, a frontend developer, a DevOps person and half a security consultant. It also makes it very easy to go fast in the wrong direction, so the habit that saved me was writing the rules down (what’s allowed in production, what needs a human to approve it, what must never be logged) and making the tooling enforce them. A hook in front of Claude Code refuses known-destructive commands outright and stops to ask me before anything that would change production or send a message to a runner, so neither I nor the AI could forget the rules at 11pm. (It’s a backstop, not a guarantee: passing the guard never meant a command was safe.)
Production broke twice along the way, both times for the same reason: I ran a data change before deploying the code that depended on it. “Code ships before the data operation that needs it” is now rule three of four, at the top of the README, in red.
I told this story at R/GA’s Creative Summit in New York in October 2026, as the “advanced” half of a talk on vibe coding with Nick Coronges. The point we wanted to land was that the swarm isn’t just a faster way of doing the testing we already did. It’s a way of doing something that, with a team this size, wouldn’t have been possible at all.