From meeting outcomes to current context
The thesis
Conversations create decisions and commitments. A transcript can preserve what was said, but a later conversation can change what that statement means for the work. The useful question becomes: which decision applies now, who owns the next step, and what evidence supports that understanding?
Atntiv starts with reviewable meeting outcomes. Its longer-term thesis is meeting continuity: preserving the state of decisions and commitments as context changes. This paper separates the current workflow from the system we are developing.
When context changes
On Monday a team agrees to launch on September 12. On Wednesday an engineering dependency slips by a week. On Friday the launch date remains in the task list. Both meeting records can be accurate while the working plan is wrong. This is an illustrative example, not customer research.
Connecting those conversations requires more than another summary. A useful system must distinguish a new decision from a suggestion, retain the reason for a change, and make uncertainty visible. It must also let someone correct the interpretation.
Available today
Browser Listener starts from the application. For a web meeting, the user grants microphone access and selects a meeting tab with audio sharing enabled. The microphone captures the local speaker; tab audio captures the remote conversation. The browser capture prompt also requests a display stream, but the transcription path sends audio rather than screen images.
Audio is sent to the Atntiv API and forwarded to OpenAI for transcription. Web-meeting audio is processed in short segments. The current code also includes an in-person microphone mode with a final audio pass for speaker separation. This is audio processing, not a captions-only integration.
The web-meeting workflow is intended for Google Meet, Microsoft Teams Web and Zoom Web in a browser that supports tab-audio sharing. Native desktop meeting applications are not a supported direct capture source. Browser permissions and audio-sharing support determine whether capture works.
A user can instead upload an existing transcript in TXT, VTT, SRT or JSON format. Analysis produces structured results such as decisions, tasks and blockers. Generated output can be incomplete or incorrect, so the source transcript remains important when reviewing an outcome.
Review and confirmation in Meeting Memory
Extracted memory items begin as suggestions. Users can confirm or dismiss them and review source evidence. Confirmed items can be revisited, with editable ownership and status. Confirmation records a user’s review; it does not prove that the underlying statement is correct or still current.
Projects bring related meetings and their Memory together. The meeting results include a “What changed since the last meeting” comparison that groups items as new, changed, resolved or still open using text similarity, ownership and explicit status. Users can review these groups alongside the meeting evidence. This comparison does not itself rewrite the stored decisions.
Ask Atntiv can connect the selected meeting with recent project meetings, confirmed Memory, follow-ups and the comparison shown in the interface. This cross-meeting context is already part of the implemented workflow.
In development
The existing project comparison is a starting point for further reconciliation: proposing which earlier decision a new outcome supersedes, with evidence and a reviewable change to the saved state. That additional workflow is in development; project grouping, comparison and contextual questions already exist.
The homepage’s “Since you last met” illustration shows the direction of the experience. It should be distinguished from the existing “What changed since the last meeting” comparison in meeting results. The current comparison helps users review changes; it does not establish an authoritative current state automatically.
Team is offered as a founder-led pilot. Workspace membership and explicit project-sharing code exist, but access, deployment readiness and the pilot’s scope must be agreed with the founder. The pilot is an opportunity to test shared context and responsibility; it is not a promise of automatic team-wide intelligence.
Data flow and its limits
Capture permissions are meaningful: users choose when to listen and what source to share. Audio still leaves the device for transcription. The inspected API does not write audio chunks to its database, while transcript text, analysis and Memory are stored for later use. The in-person mode temporarily holds audio in the browser for its final transcription pass.
These implementation details do not establish a provider-wide retention period, a no-training guarantee or a complete deletion policy. Provider terms, hosting configuration and operational retention require separate verification. The privacy policy describes the processing workflow; it must not be interpreted as a promise that no audio is processed.
Share links and workspace project sharing are explicit access paths. People should review what they share and obtain the permissions needed to process a conversation. Plan history windows govern access; they do not establish when stored data is deleted.
What we need to learn
The next questions are practical: do people return to confirmed outcomes before the next meeting? Can they identify the current decision without reconstructing the conversation? Which proposed changes need human review, and what evidence makes that review useful?
We have not established quantitative answers in this paper. Future studies could compare decision recall with and without source-linked Memory, or examine how teams resolve conflicting meeting outcomes. Those are research opportunities, not published findings.
You can try the current capture, transcript, analysis and confirmation workflow now. Evaluate it on a conversation whose outcomes you can check. Discuss the Team pilot or the development direction with the founder.