Proposal: add Fathom as a selectable meeting-intelligence provider (alongside Granola)

[Anou4r]

Meeting intelligence currently runs on Granola. I'd like to propose adding Fathom as a selectable alternative, so users can pick whichever meeting provider they already use. A lot of teams already run on Fathom (it auto-records and transcribes Zoom / Meet / Teams), and today they get no meeting intelligence in Dex unless they also adopt Granola.

I've built and run a working Fathom integration in my own vault for a few weeks: a remote claude.ai MCP connector (.claude/mcp/fathom.json, OAuth via /mcp) with /process-meetings reworked to pull on-demand. No Python server, no .env key, no background daemon, no local cache. The catch is that in my vault it currently replaces Granola, whereas for upstream the right move is to make the backend a choice: a meeting_intelligence.provider field in user-profile.yaml (granola | fathom | none), with Granola staying intact and the default, and /process-meetings plus onboarding branching on it.

Before I open a PR I wanted to align on the design: is a simple provider switch the direction you'd want, or a fuller abstraction layer, and what config shape do you prefer? If there's appetite for this, I'm happy to build it out.

[m13v]

the provider field (granola|fathom|none) closes this exact choice, but /process-meetings still branches on the provider name, so provider #3 forks the same conditional again. the boundary the switch doesn't touch is the shape of what comes back: fathom's transcript payload and granola's note structure don't normalize to one record, and onboarding has to fork per provider too. a thin adapter mapping each backend onto one meeting schema is what stops the drift, the config field just picks which adapter runs.

[davekilleen]

Anou4r — apologies for the long silence, and thank you both for the proposal and for building it in your own vault first.

Short answer: yes to Fathom as a selectable provider, no to the plain provider switch as the shape.

@m13v's point above is the right one, and it is why I took a while. A meeting_intelligence.provider field picks which backend runs, but it does not touch the thing that actually forks the code: Granola's notes and Fathom's transcripts do not arrive in the same shape. Granola is also wired in more deeply than the config suggests — a dedicated MCP server (core/mcp/granola_server.py), a sync script and API-key helper under .scripts/meeting-intel/, a granola-setup skill, and named references inside /process-meetings, /daily-plan, /week-plan and onboarding. A config field in front of all that just relocates the conditional.

So the shape I would want is the adapter:

1. Define the internal meeting record first — what /process-meetings and the person/company page updates actually need (attendees, time, notes or transcript body, action items, source id). That contract is the whole design; everything else falls out of it.
2. meeting_intelligence.provider (granola | fathom | none) selects an adapter, not a code path. Granola stays the default and its behaviour must not change.
3. Onboarding branches once, at the provider choice, into the matching setup skill — granola-setup is the pattern to copy.
4. /process-meetings and the flows consume the internal record and stop naming any provider at all.

If you are up for it, the most useful first PR would be the one with no Fathom in it: define the internal record and move Granola onto it, unchanged. That is the risky half. If Granola still works untouched through the adapter, Fathom becomes additive and genuinely easy to review. Happy to agree the record shape with you before you build against it if you would rather settle that first.

One honest caveat so it is not a surprise later: I cannot test Fathom myself, so I would lean on you for verification on that side, and I would want the setup skill to say plainly when it is not working rather than degrade quietly — we have just been bitten by exactly that with a mail integration.

Thanks again for the patience. And @m13v — thank you for the critique, it changed the answer.