Meetings

Overview

Meetings turns transcribed meeting audio into a meeting workspace. The product infers when you are in a meeting using app, calendar, browser, accessibility, and audio signals, then lets you review a full transcript, generate an encrypted summary from built-in or custom templates, and extract action items grounded in what was said. Calendar data, where connected, enriches titles, times, and participants. Everything described here is oriented around on-device processing and your local store. The meeting-focused public beta does not persist screen images, UI snapshots, document rows, or video files.

How meeting detection works

Detection is heuristic, not a guarantee. Overshow combines signals so that ad-hoc calls and common tools are recognised without you starting a separate “record meeting” mode.

Signals that contribute

Signal type	Role
Application identity	Known meeting clients (for example Zoom, Microsoft Teams, Google Meet, and similar) strongly suggest an active call.
Accessibility/browser context	Recognised meeting controls, window titles, and URL patterns help when the call runs in a desktop app or browser tab.
Screen text (where enabled)	Builds with screen capture can use OCR keywords and UI chrome associated with calls, waiting rooms, and shared content.
Audio	Multi-speaker activity and meeting-like audio patterns support detection when video is minimal or off-screen.

No single signal is required in isolation; the product weighs what is available for each capture window.

Idle timeout

If meeting-like activity stops for five minutes, the session is treated as no longer active for detection purposes. That idle threshold reduces false “still in meeting” states when you leave a tab open or a client running after the call has actually ended.

Meeting lifecycle

A meeting moves through a small set of states that drive what you see in the UI and what background work runs.

Meeting states

State	Meaning
Detected / active	A meeting is recognised and treated as ongoing; capture within the session bounds feeds transcript and summary inputs.
Ended	The call has finished (including after idle timeout); the session is closed for live capture but may still be awaiting or completing summary work.
Summary pending	The meeting has ended (or you have requested a summary) and the summary pipeline is queued or running.
Summarised	A summary has been written and stored encrypted at rest; you can read sections, copy text, and review action items.
Deleted	The meeting record has been removed from your workspace; associated summary and UI entries are cleared according to product behaviour.

Lifecycle flow in practice

Expand: typical path from detection to summary

1. Detection combines app names, meeting controls, browser URLs, calendar presence, audio, and parser metadata to open a meeting session.
2. While active, transcribed audio accumulates; calendar metadata may attach title, start/end, and participants if you have connected a calendar.
3. When the call ends or idles out, the session moves to ended; if a summary is expected, state becomes summary pending.
4. The summary pipeline gathers audio segments aligned to the meeting window, then produces a narrative via an on-device language model or a baseline fallback if no LLM is available. Summaries are audio-only by default; screen and app text is included only when you turn on the optional screen-context setting, which is off by default.
5. On success, storage is encrypted at rest and the meeting is summarised; you can regenerate or delete from the meetings UI as needed.

Summary generation

What data feeds the summary

Summary generation is bounded by meeting start and end (including idle-driven end). By default it is audio-only and collects:

Input	Detail
Audio segments	Transcribed speech within the same time window grounds the narrative in what was actually said. This is the default and only source unless you opt in to screen context.
Template	Headings, prompts, and fields from the selected template steer structure and emphasis.
Screen text (optional)	Off by default. In the public Meetings build, screen capture itself is off, so this setting alone adds no frames — it applies only to builds where screen capture is also enabled. Where it is, enabling the optional screen-context setting adds screen and app frames; they are then scored for usefulness and the pipeline caps contributions so long sessions still manage cost and noise.

LLM versus baseline

Path	When it applies
LLM	Preferred when your build has a configured on-device or local language model available for narrative generation.
Baseline fallback	Used when the LLM path is unavailable or fails; you still get structured output, but phrasing and depth may differ.

Summaries and related artefacts are stored encrypted at rest like other sensitive meeting content.

Built-in templates

Built-in layouts cover common meeting shapes so you can start immediately and stay consistent across teams.

Template focus	Typical use
Sales calls	Outcomes, objections, next steps, and customer signals aligned to revenue conversations.
One-to-ones	Career themes, blockers, commitments between two people.
Standups	Progress, plan, and impediments in a short, repeatable structure.
Custom	User-defined layouts (see below); treated as first-class alongside built-ins in the selector.

Choosing a template per meeting

The template selector on the /meetings route applies to generation and regeneration. Switching template before generating changes section headings and prompts; it does not alter the underlying transcript. For recurring formats, pick the same template each time so comparisons week-on-week stay meaningful.

Custom templates

You can create, edit, and reuse templates that match how your organisation actually works.

Aspect	Behaviour
Structure	Define headings, prompts, and fields that the generator fills from transcript text and any optional screen context available in your build.
Storage	Preferences are stored locally; they are private to your device and account.
Reuse	Save once, apply to any detected meeting of that type; duplicate when piloting changes so you can roll back.

Action items

Action items are extracted from transcript content. commitments, follow-ups, and tasks implied or stated explicitly in speech.

Mode	Description
Standard extraction	Included in the main summary pipeline where the template and model surface tasks alongside narrative sections.
Dedicated pass	When enabled, a separate pass focuses specifically on action items for higher precision on noisy or long calls.

Always review extracted items before sharing; speech recognition and inference can merge speakers or mis-hear dates.

Transcript view

The transcript presents full meeting text with speaker labels where diarisation or speaker identification is available. Use it to verify summaries, copy quotations, and spot names or numbers the summary condensed.

Transcript versus summary

The summary is abridged and structured; the transcript is the verbatim (as transcribed) record. For compliance or editorial workflows, treat the transcript as the source of truth and the summary as an aide-mémoire.

Pre-meeting briefs

Pre-meeting briefs are an internal dogfood surface and are off in the meeting-focused public beta while the feature matures. In builds where pre_meeting_briefs is enabled, Overshow watches for calendar events starting soon, then generates a brief from relevant past captures. It is not generic advice.

Element	Source
Topics and context	Retrieved from your local index around titles, participants, and related apps.
Timing	Tied to upcoming event windows so briefs appear when they are actionable.

Connecting Google Calendar or Microsoft Outlook is described in Calendar integration; when briefs are enabled, quality depends on both calendar accuracy and historical capture for the same workstreams.

Calendar enrichment

When a calendar is linked, event titles, start and end times, and participants can be added to meeting context. That improves list readability in the meetings UI and gives summarisation clearer anchors than raw timestamps alone.

Meeting-scoped search

Search and answer flows can be restricted by meeting_id so that results draw only from material associated with that session. Use this when you want evidence inside one call without pulling unrelated days or applications.

Desktop meetings experience

The /meetings route is the hub for meeting history and actions.

UI area	Behaviour
List	Meetings are grouped by date for quick scanning.
Detail	Opening a meeting shows summary sections, transcript access, and metadata.
Generate summary	Explicit control to run or re-run summarisation after a meeting ends or if the first pass failed.
Delete	Removes the meeting from your workspace per the deleted state above.
Real-time updates	Live messages report summary progress so you are not left guessing while the pipeline runs.

Tips

• Align custom template sections with how your team already writes notes so adoption is frictionless.
• For long sessions, scan the transcript first, then read the summary to confirm nothing material was dropped.
• Use meeting-scoped search when stakeholders ask “what did we agree in that call?” rather than searching the entire index.
• Keep calendar and meeting-client settings honest so detection and titles match reality. In builds where briefs are enabled, the same metadata also improves brief quality.