Writing a blog post from a stack of customer calls usually means scrubbing through transcripts, copy-pasting quotes into a doc, opening an AI chat, pasting in your style guide, asking for a draft, then rewriting most of it because it sounds nothing like you. The agent has no memory of your voice or your editorial rules, so every post starts from zero.
This guide walks through building a blog-post drafter: a named workflow in Claude Code that reads your Granola meetings, pulls voice and editorial rules from a Wire container, and saves a markdown draft for you to review. Once the agent exists, your customer conversations become a writeable corpus instead of a pile of transcripts you keep meaning to do something with.
What you’re building
A blog-post drafter with two sources of truth and one output surface. You give it a topic. It searches your Granola meetings for relevant customer evidence, pulls past posts and editorial rules from a Wire container, drafts a post in markdown with footnotes citing every source, and saves it locally. You review the draft, edit, and publish on your own CMS.
Two data sources, one draft:
- Granola (via the Granola MCP) holds the customer conversations. Meeting notes, transcripts, attendees, dates. The agent queries it fresh every time it drafts so the evidence is current.
- Wire holds what is not in your meetings. Past blog posts for voice grounding, brand and product positioning, editorial rules and naming preferences, and your topic backlog so you do not write the same post twice.
The agent never publishes. Neither MCP exposes a CMS or send tool, so the only output is a markdown file you read before shipping.
How it works
Without grounded context, a generic AI draft for a topic like “common objections we hear from technical founders” looks like:
Technical founders often have concerns about adopting new tools. Common objections include integration complexity, security questions, and cost. It is important to address these proactively in the sales process.
With Granola meetings as evidence and a Wire container holding your voice and brand, the same agent produces:
The objection that comes up first in maybe four out of five technical-founder calls is “I do not want another vendor in the data path.” We hit this so often we now lead the demo with our self-host story instead of the pricing page. Drawn from three founder calls in the last 60 days.
What changed: the agent had real meeting evidence to ground the claim, a Wire entry telling it your house style runs short and opens with a specific number, and a clear path back to the source meetings if you want to verify before publishing.
Why Wire containers
Granola already has an MCP. Search meetings, list by date, pull transcripts. So why add Wire to the picture?
Granola holds evidence. Wire holds editorial. Your past blog posts, your brand voice, what you call your product, which customers cannot be named, what topics you have already covered. None of that lives in Granola, and a draft built only from raw meeting evidence reads like a transcript dump. Wire is where you put the things that turn evidence into something publishable.
One container, many agents. When you later build a sales objection report, a customer interview synthesizer, or a release-notes drafter, they all read from the same Wire container. The voice and brand entries you write once feed every downstream content workflow. You do not maintain three parallel style guides that drift apart.
Editorial rules survive. A Wire entry that says “anonymize customer Acme in public content” applies to every draft from now on. The agent reads the rule before each run. You do not have to remember to flag it in the prompt.
Setup
Three connections. All link to canonical docs so you pick the path that fits your stack.
1. Create a Wire container and seed it
Create a container and add: three or four of your past blog posts, a short brand and product context note (who you write for, what you call your product, your common framings), and any editorial rules (naming preferences for customers, terminology you avoid, links you always include). Add as files or paste as entries.
See Creating containers.
2. Connect Wire to Claude Code
Add the Wire MCP to Claude Code so the agent can search your container.
3. Connect Granola to Claude Code
Connect the Granola MCP. It uses browser OAuth, no client secrets needed.
See Granola MCP setup.
Usage
Once the three connections are live, the agent runs from a single prompt in Claude Code. Paste this whenever you want a draft on a specific topic:
I want to draft a blog post on the topic: <YOUR TOPIC HERE>.
Use the Granola MCP and the Wire MCP to do this. Do not invent facts.
Every claim in the draft must trace to either a meeting in Granola or
an entry in Wire. Footnote every claim with its source.
1. Search my Wire container for any editorial rules, brand and product
context, and the topic backlog. Apply the rules before drafting:
honor my naming preferences, use my preferred terminology, follow
any structural patterns in my voice notes. If the topic is already
on the shipped list, surface that and ask whether I want a follow-up
angle or a different topic before continuing.
2. Search Granola for meetings relevant to the topic. Skip internal
meetings, recruiting calls, and partner conversations. Pull notes
and, where available, transcripts from the most relevant customer
or prospect meetings. Aim for at least three meetings as evidence.
If fewer than two meetings cover the topic, stop and tell me, do
not draft on thin evidence.
3. Search my Wire container for three or four of my past blog posts.
Read them before drafting to match my sentence rhythm, structure,
sign-off, and any phrasing I reuse. Do not copy any post verbatim.
4. Compose a draft that:
- Opens with a specific observation grounded in a meeting, not a
general statement.
- Uses real customer language. Anonymize where a naming-preference
rule applies.
- Sounds like my past posts. Match voice precisely.
- Footnotes every factual claim back to a Granola meeting (with
date and attendees, anonymized as needed) or a Wire entry.
- Stays the length of my typical posts. Do not pad.
5. Save the draft to drafts/<topic-slug>.md as markdown.
6. Update my topic backlog in Wire with this topic, marked as drafted
but not shipped.
When done, tell me:
- The path to the saved draft.
- The list of meetings used as evidence (date, anonymized attendee).
- Which editorial rules you applied.
- Anything you wanted to claim but could not source. I should know
what is missing before I edit.That is the whole thing. Paste it into Claude Code with a topic, review the markdown draft it saves, edit, and ship from your CMS.
Closing the loop
The skill closes the loop on its own. At the start of every run, it scans your drafts/ folder for any markdown file with an open topic-drafted entry in Wire. It treats your latest edits to the file as the final version, ingests that markdown as a new voice-corpus entry, and marks the topic archived in your backlog. No URL, no slug, nothing for you to copy. Future drafts mirror your latest writing instead of drafting against an aging corpus.
We simplified the whole flow into a one-command skill. Download it below and run it with /blog-post-drafter instead of pasting the long prompt every time.