Better live events with agentic radio hosts?

Imagine for example a motorsport event with vs. without a strong voice that tells you what just happened, who is leading, when the next session starts, and what’s wrong with the car that just limped into the pits. Big televised competitions have exactly that — a commentary booth, a production crew, and a budget to pay for both.

Smaller events do not. A hobby event is typically run by a handful of volunteers who are already handling contestant registration, timing, rules enforcement and incidents at the same time. The competition day is long, often eight hours or more of action. And for most of those hours nobody is telling the story.

This is where the idea for an AI radio channel came from. The point was never to replace real radio shows or professional commentators. The point was to take the format of a radio show — two hosts, music, a continuous stream — and apply it as a utility: a low-cost layer of situational awareness and atmosphere for an event that otherwise has none.

Now, let’s describe an experimental project built around that idea, and the lessons it produced.

The pipeline is deliberately linear and each stage is a separate service:

Material sources fall into two categories. Static material is prepared before the event: series background, event information, rules, technical explainers, participant and team profiles. Dynamic material arrives during the event: live timing data, announcements and question in group chats, schedule changes, weather observations.

The producer agent is the editorial brain. It does not simply announce whatever arrives. Incoming events are batched by priority so that related things are discussed together instead of as a string of disconnected announcements — breaking news flushes in seconds, low-priority filler waits up to a minute to accumulate company. When nothing noteworthy is happening, the producer actively decides what to talk about next: which data source to pull, which team to spotlight, which prepared article is due. It then writes an instruction for the hosts, and a second stage turns that instruction plus the gathered material into an actual multi-host dialogue.

Text-to-speech synthesises each host’s lines individually with that host’s own voice configuration.

The mixer: a Liquidsoap instance — is responsible for everything the listener perceives as “production value”. Music plays continuously when nobody is talking. Priority queues ensure an urgent announcement can interrupt filler chatter, while a separate push-to-talk channel lets a human at the event take over the microphone at any moment with a signal beep in front of it.

Broadcast is an ordinary audio stream plus a web player, which means any phone in the area can listen without installing anything.

The separation matters more than it might appear. Because the producer, the speech synthesis, and the mixer are independent services, the voice provider can be swapped without touching editorial logic, and the editorial logic can be rewritten without touching the audio pipeline.

If one finding deserves emphasis, it is how much variation there still is between text-to-speech providers. The project has at some point run against ElevenLabs, OpenAI, Azure, Google Cloud, and Google’s Gemini models, and the differences are not marginal.

Quality equals money. ElevenLabs produces some of the best output available, but it is also comfortably the most expensive option for a continuous eight-hour show. At the time of writing, the Gemini models offered the best price-to-quality ratio for this use case by a clear margin — good enough to carry a full broadcast day without the cost becoming the project’s defining constraint.

Finnish is genuinely hard language. Many otherwise excellent models stumble on Finnish, and numbers are the worst offender. Finnish inflects numerals and requires different forms of the same number. A model that reads digits in a naive nominative form sounds immediately wrong.

Style instructions are a leaky abstraction. Each provider has its own syntax for style and tone guidance, and some of them interpret it rather too literally — there is a real risk that the instruction itself leaks into the audio and the listener hears the host describe their own voice characteristics.

Some models take liberties. A recurring problem is models that decide to improve the text: changing wording, substituting synonyms, or “correcting” the pronunciation of a proper noun that was deliberately spelled phonetically. For a radio show built on team and contestant names, this is not a cosmetic issue.

Dialog consistency is the tricky one. A single sentence usually comes out fine. The problem appears across consecutive clips: the same voice, generated twice a few seconds apart, can shift tone enough to sound like a different person, or swing from excited to melancholy for no reason the listener can infer. In a dialogue this is especially noticeable, because the mood has to survive being handed back and forth between two hosts.

Modern models now support generating multi-speaker conversations in a single request, which very likely addresses the consistency problem at its root — the whole exchange is produced in one coherent pass instead of being stitched together from independent fragments.

What is still missing is a standardised syntax to describe tone, mood, and vocal “gestures”. Every provider has invented its own vocabulary, and the result is that voice direction — arguably the most creative part of the work — is the least portable part of the system. One would hope this converges.

Content quality tracks data freshness almost perfectly.

Preparation still pays off. A library of background articles — the rules, the history of the series, contestant profiles and stories about the participating teams — gives the hosts something substantial to fall back on during a quiet hour. And when all else fails, there is always the weather: live observations and forecasts are available from open data APIs, cost nothing and are reliably relevant at any outdoor event.

But prepared material is, by definition, not news. The most engaging content always came from the live sources:

• Live results— positions, times, lap counts, best laps and who has withdrawn from the competition. Pluggable analyzers watch that state and raise events worth discussion without having to loop the LLM for it.
• Event chat groups — a WhatsApp listener forwards messages from the organisers’ group straight into the pipeline as field reports. This turned out to be remarkably valuable: it is where the human observations live, the ones no timing feed will ever contain.
• Interactive event apps — modern events might use apps for interactive activity tracking. For example this project the pit stops and driver names are logged by contestants using an app, providing excellent material for the radio as well.

The general principle: anything the organisers are already maintaining for their own purposes is a candidate data source, and hooking into it is usually easier than thought.

Basic awareness comes from two places: the schedule and the event information. Knowing that it is 10:40, that qualifying ends at 11:00, and that the race starts at 12:30 is already enough to make the difference between a host who sounds present and one who sounds like a podcast recorded last week.

Beyond that, the project uses an explicit phase model. The event day is divided into phases and the phase propagates through the entire pipeline. It determines which commentary guidance the dialogue generator receives, which analyzers are active, and which data sources the producer is even allowed to consult. Live standings are simply meaningless before and after the competition.

The other half of awareness is memory. Hosts who forget everything they have said are exhausting to listen to, so the system maintains several layers of bookkeeping:

• An event diary of the day’s significant moments, which lets the hosts refer back to something that happened two hours ago.
• Per-team context and diaries, separating persistent background (who they are, their history in the series) from today’s data (current position, lap count, recent incidents, sampled position history). This is what allows a remark like “they have climbed back from a difficult grid position” instead of a bare position readout.
• Topic memory, a rolling log of what has recently been discussed, with time-based expiry.

Careful context handling is the single highest-leverage area in a system like this. The same model, given a well-assembled context, produces dramatically more interesting output than when given a raw data dump.

The hosts are configured in natural language. Each one has an identity, a role, and a personality description, plus per-provider voice settings. An entertainment-faced project benefits from hosts’ chemistry and simulated relationship. The overall tone of the show can be adjusted globally without rewriting anything, which makes experimentation cheap.

The hard part is not creating a personality. It is preventing that personality from becoming too irritating. Left alone, a model will find a turn of phrase it likes and use it every eight minutes. It will reuse the same joke structure, the same transitional phrase, the same enthusiastic opener, until the listener starts predicting the sentences.

The countermeasure is to remember not only what has been said but how it was said. Alongside topic memory, the system keeps a style memory of recently used rhetorical patterns, and a separate curation pass reviews each generated dialogue against that memory plus a configurable list of known bad habits. The curation stage is explicitly forbidden from changing facts, line counts, or speaker assignment — it only adjusts expression.

Are the hosts human? No, and most listeners work it out quickly. But they are frequently good enough, and there is an unexpected upside: when the jokes are bad, they are bad in a way that is genuinely entertaining. A slightly stupid joke delivered with total commitment by a synthetic radio host turns out to be a perfectly acceptable form of event entertainment.

The radio was run live at the Nissan Micra Endurance events throughout season 2026, which is a reasonable stress test: a long day, a volunteer organisation, tens of teams and a paddock area sprinkled with bluetooth speakers.

This is not the kind of industrial, carefully robust system Wapice usually builds, and that was much of the appeal. Building something whose success criterion is “was this fun to listen to” is a refreshing change of problem shape, and it exercises a different set of engineering muscles than a typical IoT system does.

Two practical conclusions:

It is production ready and it is cheap. The technology stack underneath — speech synthesis, speech recognition, LLM-driven content selection — is mature. An eight-hour broadcast day costs under 100 € in model and synthesis fees. That is a price point small events can actually reach.

The interesting part is the voice-based information delivery. Text-to-speech and speech-to-text have quietly become good enough that audio is now a viable primary interface rather than an accessibility afterthought. A radio channel is one application. There are countless others where the natural human–machine interface is a voice rather than a screen and a keyboard, and most of them have not been built yet.

If any of this sounds relevant to something you are working on — whether it is an event, a product, or an interface problem that might have an audio answer — feel free to get in touch.