GPTunneL Put Its Voice Assistant GROM on a Live Broadcast: What Broke in 3 Hours of a Hackathon

A voice assistant at a shared table is an easy idea to grasp, until it reaches a live broadcast. The GPTunneL team tested it at the "New Cities" hackathon at the "Big Fizteh": for three hours GROM listened to experts, schoolchildren and students who were designing a village of the future, and answered questions out loud. The result was far from perfect, but the post-mortem is an honest one.

How It Works

There was no wake word. Speech from the microphone was recognized, the system looked at the first word of each utterance, and if it was "Grom," the text went to the model. The reply was voiced by the synthetic voice of Philip, developed by the same team. At rehearsal GROM jumped into the conversation on its own and interrupted ideas, so for the broadcast it was switched to a "speaks only when called" mode.

The main difficulty is that people spend almost all their time talking to each other, not to the assistant. So that GROM would know what had been agreed, the broadcast was processed by a separate pipeline. vMix saved a video file every five minutes, Resilio transferred it to a second computer, a local Whisper produced a transcript, and Claude Sonnet updated a summary: who proposed what, what was decided, what remained open. The fresh summary was inserted into GROM's system prompt. Sonnet was chosen because the team had already checked its summaries many times.

Where Things Went Wrong

The first failure was fifteen lost minutes. When several files arrived at once, the handler took the newest one, and it had no queue. After the eighth file came the twelfth, and fragments nine through eleven had to be processed by hand.

The second was names. Whisper was not given a list of names, and GPTunneL turned into GPTanal. Speaker labeling turned out worse: numbering restarted in every file, so "Speaker 1" in adjacent fragments could be two different people.

The third was context. A long argument about whether the mentor would have a beard clogged the dialogue history. Nine minutes later, asked whether a person can live less without socializing, GROM started talking about the beard again. An engineer cleared the history live on air, while the decision about the character's appearance remained in the separate summary, so in substance the assistant lost nothing.

Takeaways

For developers the lesson is this: an assistant's long-term memory is not a large context window but a discipline. Keep the raw dialogue separate from the digest of decisions: the history can be cleaned, the summary stays. It is a cheap technique, and it worked on a live broadcast.

A pipeline built from chunks needs a queue, not a "take the latest" logic. Recognition needs a dictionary of names and terms before launch. Multiple speakers need end-to-end speaker identification: the team plans to test voice embeddings and compare the result with manual labeling.

The limitations are also visible. This is a pilot at a single event, there are no answer-quality metrics, part of the work was done manually, and the video model never generated the inscription on the airship; it was added during editing. Answers went on air unedited, so the unfortunate beard moment remains in the recording at 55:03.

The plans going forward: in November, return to offline events with a queue and a dictionary, connect the assistant to the Workflow editor so you can say "Grom, redo the evening scene," and look for resources to run on devices. This requires GPUs and hardware for testing, and the team is discussing it with investors. For product managers the conclusion is simple: the value of a voice interface in group conversation lies not in answering a question but in knowing the context of the entire meeting. That is the part worth building first.