What if meeting notes arrived during the meeting?

Most meeting notes arrive after the useful moment has passed.

They tell you what happened. They almost certainly list the actions. They produce a tidy summary. But they rarely help when it matters, when two people have quietly walked away from a meeting with different versions of what was agreed.

I wanted to test whether that could change.

Earlier this month, OpenAI launched a new generation of realtime voice models that can reason, translate, and transcribe as people speak. That made me wonder whether voice AI at work should be less about talking assistants, and more about helping a group of people keep track of what is becoming true as we speak.

So I built a local prototype called Signal Room to test this concept. You can watch a short demo that I posted on X.

The UI is deliberately not a chat window.

On the left, you see the transcript moving as the meeting happens. In the centre, there is a decision map. On the right, there is a meeting diagnosis that changes as the conversation develops.

As people talk, Signal Room starts pulling out the shape of the meeting: decisions, open questions, actions, risks, contradictions, and research needs.

The example that made the prototype click for me was simple.

In the demo meeting, the team agrees to aim for a May 20 private beta. A few minutes later, engineering says upload transcription QA needs until May 22.

A normal transcript records both statements.

Signal Room links them and flags the tension LIVE during the call.

Then it does the bit I care about most: it shows timestamped evidence, so you can jump back to the exact lines that created the contradiction.

That matters. I don’t want an AI meeting tool that sounds confident. I want one that gives the room something inspectable enough to correct.

In building this I wanted to set the prototype up as three tests, because I wanted to separate the product idea from the live voice plumbing - this was important to validate the concept first.

My first test is the sample meeting.

This uses controlled multi-speaker audio and prepared meeting events. That means I can judge the product properly: does the transcript, decision map, evidence linking, and diagnosis actually make sense when a meeting is unfolding?

My second test is transcript analysis.

Here, I can paste in a fresh meeting transcript and send it through OpenAI event extraction. Signal Room then renders the same decision map from new input: decisions, open questions, actions, risks, contradictions, and research needs.

This is the reasoning layer being tested without needing live audio.

The third test is the live AI setup.

This creates realtime transcription and operator sessions, which is the bridge towards proper in-meeting use. The next step is streaming browser audio into those sessions so the same meeting state can update while people are actually talking.

So no, I’m not pretending this is a finished app.

The point is to test the stack in layers: first the product surface, then the reasoning layer, then the realtime voice layer.

Can a conversation become a useful state model while people are still talking?

The more I work on this, the more I think the best voice AI products may not be the ones that talk the most.

They may be the ones that listen well enough to show us what we are actually deciding.

The Atomic Builder is written by Faisal Shariff, Human Productivity Lead at Tomoro AI. Views are my own.