DEV Community

Mininglamp
Mininglamp

Posted on

What If AI Fact-Checked Your Meetings in Real Time? Inside Meeting-Time AI Skills

Someone says "the contract specifies a 90-day notice period" during a meeting. Nobody pulls up the actual document. The discussion proceeds on that assumption. After the meeting, someone checks — it's 60 days.

This isn't a catastrophe. But it happens constantly. A number, a deadline, a previously agreed conclusion — someone states it from memory, everyone treats it as fact, and the deviation is only discovered later. Not enough to derail things, but enough to make the foundation of decisions slightly unstable.

Current AI meeting tools handle the aftermath beautifully: transcription, summaries, action items. But they can't do anything about uncertain information spoken during the meeting. Mininglamp Technology built Octic around a specific question: what if AI could intervene during the meeting, not just after it?

Post-Meeting vs. Meeting-Time: Different Problems Entirely

The dominant AI meeting product architecture — record → transcribe → summarize → deliver — solves the documentation problem. It's a solved problem at this point. Otter, Fireflies, Granola, and a dozen others do it well.

But documentation and decision quality are different things.

A wrong number that goes unchallenged during the meeting becomes the basis for decisions. By the time the post-meeting summary arrives (however beautiful), the decisions are already made. Better records don't fix bad inputs.

This is why Mininglamp chose meeting-time assistance as the product focus rather than competing in the crowded post-meeting space. The two aren't on the same axis — one is about memory, the other is about judgment.

Why Meeting-Time AI Is Genuinely Hard

Moving AI assistance into the meeting isn't a matter of "doing the same thing faster." The constraints are fundamentally different:

The time window is brutal. Between one statement and the next response, there may only be a few seconds. If AI feedback arrives after the conversation has moved on, it's worthless regardless of quality.

Context must be continuous. It's not sentence-level analysis — the AI needs to understand the entire discussion arc. When someone says "that approach won't work," the AI needs to know which approach, why it might not work, and what alternatives have been discussed.

Restraint is a feature, not a bug. An AI that produces output every 30 seconds is worse than no AI at all. Most of the time, the right behavior is silence. The hard part isn't generating useful output — it's knowing when output is useful enough to justify the interruption cost.

These three constraints together make meeting-time AI a categorically harder problem than post-meeting processing.

The Design Solution: Personas × Skills

Octic's architecture separates the "when to speak" question from the "what to say" question, handling them through two independent mechanisms.

Three Personas Control Intervention Behavior

Instead of exposing dozens of configuration parameters, Octic compresses intervention behavior into three intuition-level choices:

Advocate — Actively supports the speaker. Surfaces supporting data, reinforces arguments, fills evidence gaps. Designed for proposal presentations and report-outs where the speaker needs backup, not pushback.

Challenger — Actively questions. Fact-checks numerical claims, generates counter-arguments, flags unsupported conclusions. Designed for investment decisions, risk assessments, and strategic debates where groupthink is the enemy.

Observer — Silent by default. Records and tags everything but produces no proactive output. Only responds when explicitly asked. Designed for brainstorming and creative sessions where any interruption kills flow.

Why personas instead of individual toggles? Because users can't predict before a meeting which specific capabilities they'll need and at what intensity. But they can easily answer: "Do I want AI to help me, challenge me, or stay quiet?" That's a single intuitive decision that cascades into dozens of behavioral parameters.

Seven Skills Define Capability Boundaries

Skills determine what the AI can say when it decides to speak:

1. Fact Verification — Cross-references claims (numbers, dates, attributions) against the user's own documents and meeting history. Not a web search — a check against information the user has already seen.

2. Counter-Argument Generation — When a conclusion lacks supporting evidence or shows confirmation bias, generates constructive opposing perspectives. Not antagonism — structured devil's advocacy.

3. Argument Reinforcement — When a speaker makes a point but lacks supporting data, retrieves relevant metrics or precedents from historical context.

4. Information Retrieval — Responds to in-meeting queries ("What did we decide last time?" "What's the budget for that project?") by searching the user's accumulated context.

5. Topic Detection — Identifies important subjects that surface briefly in discussion but never get formally addressed. Prevents the "we should talk about that... anyway, moving on" problem.

6. Tone Monitoring — Detects escalating confrontation patterns and provides non-intrusive awareness cues. Doesn't intervene directly — just makes the dynamic visible.

7. Action Tracking — Recognizes task assignments and commitments in natural conversation ("you take this," "let's have it done by Friday") and structures them in real time.

Why These Seven?

Every low-quality meeting suffers from a predictable set of information gaps:

  • Wrong information treated as fact (→ Fact Verification)
  • Incomplete thinking (→ Counter-Argument + Argument Reinforcement)
  • Inaccessible information (→ Information Retrieval)
  • Lost information (→ Topic Detection + Action Tracking)
  • Process breakdown (→ Tone Monitoring)

The seven skills aren't arbitrary — they're a completeness argument against the failure modes of human group discussion.

Private AI Memory: Why Personalization Is Non-Negotiable

A generic LLM, no matter how capable, doesn't know that "Phase 2" in your organization refers to a specific product launch, or that your CFO's primary concern is always cash flow timing, or what was decided in last month's board meeting.

Without organizational context, meeting-time AI produces generic outputs that don't justify the interruption cost. The bar for "worth interrupting a meeting" is extremely high — only personalized, contextually relevant information clears it.

Octic's approach is continuous context accumulation from the user's own data: meeting recordings, documents, conversations in Octo (Mininglamp's AI collaboration platform). Over time, the AI learns:

  • Speech patterns: Auto-corrects ASR for names, terminology, and project codes specific to the user's environment
  • Attention patterns: Knows what each person cares about. Same meeting generates different emphasis for different roles — financial impact for the CFO, technical risk for the CTO
  • Knowledge gaps: Understands what's "known" to the user (no need to mention) vs. what's a "blind spot" (worth flagging)

Privacy by Architecture

Meeting conversations contain some of the most sensitive information in any organization — strategy discussions, personnel decisions, financial projections, competitive intelligence.

Octic's privacy model isn't policy-based ("we promise not to look at your data") — it's architecture-based: all data stays on-device. Memory accumulation happens locally. Inference runs locally. Raw audio never leaves the hardware.

This is a structural advantage of on-device AI. The privacy guarantee isn't a feature that could be removed in a future update — it's a physical constraint of the system architecture.

Hardware: Input Quality Determines Output Quality

Meeting-time AI is only as good as its audio input. No amount of algorithmic sophistication compensates for a noisy, reverberant signal.

Octic addresses this through purpose-built hardware for different scenarios:

Octic Note (MagSafe attachment) — Far-field pickup for conference rooms. Handles multi-speaker separation and room acoustics.

Octic Badge / Octic Pin — Vibration-based pickup for calls and 1:1 conversations. Bone conduction naturally rejects ambient noise.

These aren't just different sizes of the same device. They represent fundamentally different acoustic processing approaches, each optimized for its scenario. The design philosophy: solve signal quality at the source rather than trying to compensate algorithmically downstream.

What This Means for the Category

The meeting AI market has consolidated around post-meeting processing because it's technically safe and commercially proven. But it's also approaching a ceiling — once transcription and summarization are "good enough," there's limited room for differentiation.

Meeting-time AI represents the next frontier: AI as a participant that improves decision quality in real time, not just a recorder that improves documentation after the fact.

It's harder to build. It requires on-device inference, sophisticated intervention logic, continuous personalization, and purpose-built hardware. The engineering surface area is significantly larger than post-processing.

But if we accept that meetings exist primarily to make decisions — not to produce documents — then meeting-time assistance is where AI's highest-value contribution lies.

Mininglamp's Octic, with its 3-persona × 7-skill design, offers one coherent answer to how this can work. Personas solve the "when to speak" problem. Skills solve the "what to say" problem. Private AI memory solves the "how to be relevant" problem. Together, they define what it means for AI to move from post-meeting recorder to meeting-time advisor.

-

Top comments (0)