\n\n\n\n Meeting Notes That Never Phone Home - AgntAI Meeting Notes That Never Phone Home - AgntAI \n

Meeting Notes That Never Phone Home

📖 4 min read•799 words•Updated Oct 10, 2026

TechCrunch’s framing of the release is the part I keep turning over: the same Google team that shipped an AI-powered dictation tool running on local models back in April has now put out a Granola competitor called Google AI Edge Foresight. Not the Gemini team. Not a cloud product with an offline mode bolted on. An edge team, shipping a Mac app that works without a network connection, using an on-device model named EmbeddingGemma 2 at 740 million parameters.

My first reaction was not about the product. It was about the model choice, because that single detail says more about the architecture than any feature list Google has published so far — and Google has published very little. The sources don’t cover platforms beyond the Mac app, the full feature set, or how this gets paid for.

An embedding model is a strange heart for a note-taker

Here is what gives me pause. Embedding models don’t write. They map text into vectors so you can compare meaning numerically. That’s retrieval machinery, not prose machinery. If the headline model in a meeting note-taker is an embedding model, the system’s center of gravity is probably search and structure rather than generation.

Two readings of that, both interesting:

  • There’s more in the pipeline than has been disclosed. Transcription needs an acoustic model. Readable summaries need something generative. EmbeddingGemma 2 would then be the memory layer, with other components doing capture and composition. Google simply hasn’t detailed them yet.
  • The product is deliberately retrieval-shaped. Segment the transcript, embed every chunk, cluster by topic, surface what matters, let the user query their own meeting history semantically. Less “write me a summary,” more “give me the parts that count.”

I’d put real weight on the second reading being at least partly true, because retrieval-first design is a far better fit for the constraints of running on a laptop. Generation is where on-device models fail most visibly. An embedding model that returns slightly imperfect neighbors degrades gracefully. A small generative model that confidently invents a decision nobody made does not.

Why 740 million is the number to notice

For an embedding model, 740M parameters is generous. Plenty of production embedding models sit well below that, in the one-to-three hundred million range, precisely because they’re expected to run cheaply over large corpora. Choosing something this size for a desktop app reads as a deliberate quality bet: the team wanted retrieval good enough that users trust it, and they decided a Mac’s unified memory could absorb the cost.

That tradeoff is the whole story of local-first agent design. You pay in resident memory and warm-up time to buy privacy, offline capability, and zero marginal inference cost. On Apple Silicon, where CPU and GPU share a memory pool, a model in this class is a reasonable tenant alongside a browser and a video call. On a mid-range Windows laptop with discrete graphics and tighter VRAM, the same bet looks harder. Mac-first here may be less about audience taste and more about which hardware makes the architecture work.

What local-first actually changes about the agent

The interesting consequence isn’t privacy as a marketing line. It’s where the agent’s memory physically lives.

Cloud note-takers keep your vector index on their infrastructure. That index is the asset, and it’s the reason switching tools feels like amnesia. A local-first design moves the index onto your disk. The agent’s recall becomes a local artifact you own, back up, and in principle migrate. For anyone thinking about long-horizon agent memory, that’s a meaningful structural difference — the memory layer stops being a service you rent and becomes a file you keep.

It also shifts the hard problems. No server-side index means no cross-device sync unless the app builds it, and building it without shipping embeddings to a server is genuinely difficult. Cold start costs real seconds. Model updates mean redownloading hundreds of megabytes rather than flipping a flag in a datacenter. These are the unglamorous constraints that decide whether a local-first tool feels fast or merely principled.

The pattern worth watching inside Google

Two local-model products from the same team in roughly six months — dictation in April, meeting notes now — looks like a sustained bet rather than an experiment. Google already sells cloud AI in nearly every product surface it owns. An internal group shipping desktop apps where inference never leaves the machine is a different strategic logic running in parallel.

The honest caveat: without disclosed details on features, platforms, or business model, most of what I’ve written here is inference from one model name and one parameter count. That’s thin evidence. But model selection is rarely accidental, and an embedding model with 740 million parameters sitting at the core of a note-taker tells you the team was thinking about memory and retrieval first. In agent design, that’s usually the right order.

đź•’ Published:

🧬
Written by Jake Chen

Deep tech researcher specializing in LLM architectures, agent reasoning, and autonomous systems. MS in Computer Science.

Learn more →
Browse Topics: AI/ML | Applications | Architecture | Machine Learning | Operations
Scroll to Top