Skip to main content
Don’t want to set this up manually? Paste a link to this page into a Devin session and ask it to set everything up for you.
Granola records your meetings and turns them into notes, summaries, and transcripts. Once you connect the Granola MCP, Devin can use those meeting artifacts the same way a teammate would: read what was discussed, find concrete engineering follow-ups, and start work.Run this as an hourly schedule and tasks can start right when you get off a call. The whole loop runs inside your Devin instance, using a schedule, the Granola MCP, Knowledge, and child sessions.
Devin scheduled session (hourly)
  → List recent Granola meetings via MCP
  → For each new meeting (oldest-to-newest):
      → Fetch metadata, notes, AI summary, transcript
      → Identify engineering tasks from the discussion
      → Start child Devin sessions for concrete tasks
      → Log the processed meeting in Knowledge
1

Connect the Granola MCP

Devin needs access to your Granola meetings to read transcripts and notes.
  1. Go to Settings > Connections > MCP servers and search for Granola
  2. Click Enable and authenticate — this grants Devin read access to your meetings, transcripts, and notes
  3. Click Test listing tools to verify the connection is working
Once connected, Devin can call list_meetings, get_meetings, and get_meeting_transcript to pull meeting data during a session. Learn more about configuring MCP servers.
2

Create a processed-meetings Knowledge note

Devin uses a single Knowledge note to log which meetings have already been processed. This prevents duplicate processing across hourly runs.Go to Settings > Knowledge and create a new note:
  • Name: Granola Post-call Processor Meeting Log
  • Trigger: When running the Granola post-call processor scheduled session, use this note to track meetings that have already been processed.
  • Body:
Granola Post-call Processor Meeting Log
{
  "last_processed_meeting_id": null,
  "last_processed_meeting_time": null,
  "last_processed_title": null,
  "updated_at": null
}
The scheduled session logs each successfully processed meeting in this note, so the next run picks up where the last one left off.
3

Write the Post-call Operator playbook

Create a playbook that tells Devin how to process each meeting. Go to Settings > Playbooks and create a new playbook:Note the playbook ID after saving — you’ll reference it in the schedule prompt.
4

Create the hourly schedule

Go to Settings > Schedules and click Create schedule.
  • Name: Granola post-call processor
  • Frequency: Hourly (0 * * * *)
  • Agent: Devin — this lets Devin spawn child sessions for each task, so fixes run in parallel
  • Slack channel (optional): Select a channel so your team gets notified when meetings are processed and PRs are opened
  • Prompt:
Set bypass approval to true if you want fully autonomous operation — no manual approvals needed for MCP tools, Knowledge updates, or child session creation.
5

What a typical run produces

Each hour, Devin processes any new meetings and opens targeted PRs. Here’s what a real session output looks like:
Processed 1 new Granola meeting since the latest meeting log entry:

Meeting: "Backend API planning" (2026-04-29 2:00 PM)

Child sessions started (3):
1. Fix N+1 query in /api/invoices endpoint
   Repo: acme/api-server
   PR: Eager-load invoice line items to fix timeout
   Session: https://app.devin.ai/sessions/abc123

2. Add rate limiting to webhook endpoints
   Repo: acme/api-server
   PR: Per-key rate limits on /webhooks/*
   Session: https://app.devin.ai/sessions/def456

3. Update API docs for new billing endpoints
   Repo: acme/docs
   PR: Add billing endpoint reference docs
   Session: https://app.devin.ai/sessions/ghi789

Recommended actions (1):
- Investigate auth token refresh flow — mentioned as "sometimes
  flaky" but no specific error or repo identified. Needs more
  context from the team.

Knowledge meeting log updated to "Backend API planning" (2026-04-29).
Each child session runs independently and opens its own PR with the meeting context baked into the description.
6

Tune and iterate

After a few days of runs, review what’s working and adjust:Handle transcript delays. The schedule stops processing when it hits a meeting without a ready transcript — this prevents skipping meetings with delayed processing. If you find transcripts are consistently slow, increase the schedule interval or add a delay buffer to the prompt.Scope by meeting type. Not every meeting produces engineering work. Add filters to the prompt to skip certain meeting types:Learn from results. After a couple of weeks, ask Devin to analyze which child sessions produced merged PRs and which were closed without merging. Use that feedback to refine the playbook’s task extraction criteria: