On 6 November 2026 GitHub flipped @GitHub in Slack and Teams to general availability. The changelog is short and practical: mention the bot in a thread, it identifies the repository from context, investigates a bug report, drafts an issue or a change, and can open a pull request. In Teams you also get a Canvas view that shows the plan, the diff, and a preview next to the conversation. Attribution is explicit—issues carry “Created from a Slack/Teams conversation with @username”. Onboarding got tighter; follow-up messages are less likely to drop.

That is a clean product surface for typed chat. The moment the source material is speech—an interview, a stand-up, a customer call, or a multilingual review—the pipeline lengthens by everything that sits between the microphone and a clean, structured transcript. Cloud agents are happy to consume text. They are not responsible for the 30–90 ms of shared-mode WASAPI buffering, the communications enhancements, or the VAD that decides when an utterance actually ended.

Sound wave frequency and amplitude

The local capture path still owns the first 100 ms

A typical Windows desktop capture stack for a call or interview looks like this:

  1. Endpoint (USB headset, Bluetooth HFP/A2DP, built-in mic, or WASAPI loopback).
  2. Windows Audio Engine shared-mode mix plus any APO (communications enhancement, spatial, vendor noise suppression).
  3. Your client’s period and buffer (practical range 10–40 ms before you see a stable frame).
  4. Local VAD (Silero, a tiny ONNX model, or energy + hangover).
  5. Streaming or chunked STT (GGUF, ONNX, or a quantized Whisper/Parakeet/Qwen-ASR variant).

The numbers that never appear in cloud benchmarks are the first three steps. Recent Coval measurements put Qwen3-ASR 1.7B variants around 35 ms time-to-final segment and Soniox STT RT v5 at 47 ms—those assume the samples have already left the capture device. On a modern laptop the engine + client contribution is commonly 30–90 ms before the first sample reaches your process. Exclusive mode can shrink the engine part by bypassing the shared mixer and APOs, but then you fight device exclusivity and the rest of the desktop.

If your local model finishes inside the remaining budget, end-to-end from speech end to on-screen text can stay under a couple of hundred milliseconds without shipping the audio off the machine. That transcript is what you can feed to a local agent loop or, if policy allows, to a cloud endpoint such as the GitHub agent.

Turning a transcript into an actionable issue without another round-trip

Once you have clean text, the useful work is deterministic extraction, not another free-form prompt. A minimal Python sketch that turns a short meeting snippet into a structured payload looks like this:

import re from typing import Dict, List def extract_actionable(text: str) -> Dict: # crude but deterministic; replace with a small local classifier or regex set  bugs = re.findall(r"(bug|issue|fails|broken|crash)[^.!?]*", text, re.I) steps = re.findall(r"(step|when|if|then)[^.!?]*", text, re.I) return { "title": (bugs[0] if bugs else text[:60]).strip(), "steps_to_reproduce": steps[:3], "raw": text, "language": "en" # or detect from the STT language id  } # feed the dict to a local agent or POST to GitHub Issues API payload = extract_actionable(transcript)

The point is not the regex. The point is that the extraction happens on the machine that already owns the audio, before any network hop and before any rate-limit bucket on the GitHub side is touched. You can attach the original audio segment hash, the STT model identifier, and the capture timestamps so the issue has an audit trail that does not depend on the cloud agent’s memory.

Trade-offs are concrete:

  • Local STT + local extraction: lowest latency, zero audio leaves the box, model quality is bounded by what fits in VRAM or CPU cache. Q4_K_M GGUF of a 1.7B ASR model is under 1.4 GB and runs on CPU for short turns.
  • Cloud STT + cloud agent: higher accuracy on noisy accents, but you pay the full network + queue + inference round-trip and you ship the raw audio.
  • Hybrid: local capture and VAD, cloud STT only on the final utterance, then local structuring before the GitHub call. Keeps the hot path short and the expensive model call rare.

Architecture notes for a Windows overlay that feeds agents

A practical layout that stays out of the way of the call itself:

  • WASAPI shared-mode capture client in a background thread, period 10–20 ms.
  • Ring buffer of the last 5–10 seconds so you can re-process a turn if the VAD fires late.
  • Streaming STT that emits partials for the overlay and a final hypothesis on endpoint.
  • Small local model (or even a pure ruleset) that tags the final hypothesis as bug / feature / question and emits a JSON payload.
  • Optional BYOK path that posts the structured payload to the GitHub Issues or the agent endpoint only when the user confirms.

The overlay itself should draw with low-latency composition (DirectComposition or a layered window with DWM) so the text appears without adding another frame of delay. Any extra GPU composition tax shows up immediately in the end-to-end number the user feels.

Sine wave diagram

GitHub’s GA of the Slack and Teams surface makes the downstream side of the loop easy. The upstream side—getting a clean, timestamped, language-aware transcript out of a Windows audio session without adding 200 ms of hidden buffering—is still the part that decides whether the agent sees the real discussion or a laggy, incomplete version of it. Local capture, deterministic parsing, and a short local model loop keep that decision on the machine that is actually in the call.

I'm building Talkaside, a Windows app for job interviews and calls in another language.
Drafted with AI assistance from this project's code and logs.