Fathom to Linear

Someone commits to something on a call. Fathom captures that it was said. Linear is where it would actually get tracked — if anyone remembered to open it afterwards. promisedby closes that gap: it pulls the commitments out of the transcript and files the ones you approve as Linear issues.

What lands in Linear

A real issue on the team you choose, not a comment or a document. Each one gets:

• A title written as a task — “Send revised timeline”, not the full sentence someone said.
• An assignee, matched by email against your Linear workspace members.
• A due date, when one was actually stated.
• A description carrying the evidence — the quote it came from, attributed to the speaker.

Because Linear issue descriptions are markdown, the quote travels with the issue rather than being lost at the moment of filing. Whoever picks the issue up in three weeks can see the sentence that created it and who said it, without going back to the recording.

Assignment is strict on purpose

An owner is only set when the person's email matches a member of your Linear workspace. When it does not — an external client, someone on a personal address, a guest on the call — the issue is still created and the assignee is reported as skipped.

That is the deliberate choice. Linear has no sensible place to record “assigned to someone who is not in this workspace”, and guessing at the closest-looking member is how work silently lands on the wrong person. An unassigned issue you can see is better than an assigned one that is wrong.

Dates work the same way. “Sometime after the launch” is not a date, so it is left empty rather than turned into a deadline nobody agreed to.

Notion or Linear, per meeting

A destination can be set as your default and overridden for an individual meeting — useful when engineering standups belong in Linear but a client call belongs in a Notion database the client can see. The review screen shows which destination a meeting will file to before you approve anything, and the owner picker offers people from that destination's workspace, so you cannot pick an owner who would resolve to nobody.

The review step

Nothing reaches Linear automatically. Detected commitments go into a review queue where you approve, edit or drop each one; only approved items are filed. For a normal meeting it takes about ten seconds.

This is not caution theatre. Models misread meetings — they miss items, invent detail, and mistake who was speaking. An issue tracker filling itself with unreviewed guesses would create more work than it saves, and the first wrong assignment would cost more trust than the feature was worth.

Re-filing is safe

Already-filed tasks are recognised and skipped, so fixing one item and filing again does not duplicate the others. When a single issue fails — a revoked token, a team that no longer exists — the rest still file and you are told exactly which one failed and why.

Setting it up

1. Connect Fathom. A webhook is registered, so finished meetings arrive on their own.
2. Connect Linear and choose the team issues should be created on.
3. Run your next meeting exactly as you do now.

There is no property mapping step — Linear's issue fields are fixed, so there is nothing to configure. If a meeting is ever missed because a webhook could not be delivered, you can import it from the recordings Fathom already holds.

What this does not do

• It does not replace Fathom or Linear. Both keep doing what they already do well.
• It does not sync issue state back. Closing an issue in Linear is a Linear concern.
• It does not set projects, labels, estimates or cycles. Issues land on the team; your existing triage decides the rest.
• Fathom is currently the only supported source. Using something else? Let us know — it genuinely affects the roadmap.

Your meetings are not training data

Transcript content is processed to produce your issues and for nothing else. The privacy policy names every provider that touches it.

Tracking work in Notion instead? Fathom to Notion.