Your Daily Brief Is a Canary

I’d argue the opposite. A daily brief that actually works is one of the better signals you have that your AI systems are set up correctly. Not because the output is impressive on its own — it isn’t — but because building one that’s useful forces you to wire up the same context plumbing every more ambitious workflow depends on. If you can’t get a daily brief right, the more glamorous use cases on your roadmap are not going to land either.

Why most daily briefs are bad

Most daily briefs people try are useless because they’re built on one source: email. And email, on its own, is almost context-free. The best case is a reply-all thread of two-sentence messages. The worst case is a single ten-word follow-up at the bottom of a long chain. There’s not enough signal there for an LLM to tell you anything you didn’t already know. So the brief comes back as “you got an email from X, you should follow up.” Thanks. I had that already.

The bad daily brief problem isn’t a model problem. It’s a context problem.

FORGE is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

What changes when you add the second source

The fix is adding a second context source: meeting transcripts. I use Granola for this, but the specific tool matters less than the principle. Email is terse; meetings are where the actual substance lives. Decisions, commitments, the back-and-forth that produced the terse email in the first place — all of it sits in the transcript. When you give an LLM both the email and the relevant conversation that preceded it, the brief stops being a summary and starts being a follow-up tool.

Then add a third source: your calendar. Now the model knows what’s happened, what’s been said, and what’s coming. With those three streams — email, meetings, calendar — the brief can actually answer the questions that matter at the start of a day:

• What’s on my plate today?
• What did I commit to in the last few days that I haven’t acted on?
• Which emails actually need a response, and which are noise?

That last question is the one most briefs fail. The skill I’ll describe in a minute spends a meaningful share of its instructions on email triage — dropping newsletters, notifications, transactional clutter — because the value of the brief lives in what it leaves out as much as what it includes.

What I leave out on purpose

I don’t include tasks. Not because tasks aren’t useful, but because mine are perpetually out of date. I have more open tasks than any human will reasonably complete, and triaging them is a separate weekly job. Pulling stale tasks into a daily brief mostly produces guilt and noise. Your mileage may vary; if your task system is genuinely current, by all means add it. But if it isn’t, leaving it out is the right call.

The shape of a good brief

The brief I actually use has two parts: events coming up today, and conversations I need to follow up on. The follow-up section is where the value is — it’s the bit that keeps commitments from falling through the cracks when the next emergency repaints my brain.

The full structure I land on looks like this:

1. Top 3 for Today — the most important things to do or know, drawn from meeting action items, time-sensitive emails, and calendar events that need prep.
2. Today’s Calendar — events with real times (more on this below).
3. Commitments & Follow-ups — things I said I’d do in the last few days, surfaced from meeting transcripts and email threads.
4. Emails to Review — only the ones that need a response or decision.
5. Yesterday’s Recap — meetings that produced decisions or action items, two lines max.

Every line is tagged with its source — meeting, email, or calendar event — and a date. If a line can’t be attributed to a specific source, it doesn’t ship. The grounding requirement is what keeps the brief honest and stops the model from quietly making things up.

The skill

I packaged this as a stateless Claude skill that pulls from three sources: Granola for meetings (via its MCP server), Google Calendar for events, and Gmail for email. Stateless meaning there’s no database — every run reads live data. If a service is down, the brief degrades gracefully and notes the gap.

A few details worth calling out:

• Date logic handles Mondays. If today is Monday, “yesterday” means Friday. Same for Sunday. Seems trivial; very easy to forget.
• Calendar is the source of truth for meeting times. Granola’s timestamps are frequently wrong by hours. The skill matches each meeting to a calendar event by title or participants and uses the calendar time. If no match, the meeting lists without a time rather than lying about it.
• Email triage is aggressive. Newsletters, GitHub notifications, transactional mail, calendar invites that don’t need a response — all dropped before any thread is fetched in detail. The remaining threads (capped at ten) get pulled in parallel.
• Every claim is sourced. Bullets that can’t be tied back to a specific email, meeting, or event don’t appear. This is the difference between a useful brief and a confident hallucination.

The whole thing runs in roughly six steps: figure out the dates, pull the data in one parallel batch, fetch meeting notes for anything substantive, resolve meeting times against the calendar, triage emails, compile the structured brief.

How to use it

In Claude: Skills are uploaded once and then available across conversations. Anthropic’s Use Skills in Claude walkthrough covers the upload flow and how to invoke a skill. You’ll need Google Calendar and Gmail enabled as connectors on your account, plus the Granola MCP server installed.

In ChatGPT: OpenAI now has its own version of skills — Skills in ChatGPT covers how to add and use them. The recipe is the same: drop in the skill, point it at Gmail, Google Calendar, and the Granola MCP, and run it. Granola ships as an MCP server in both environments, so that piece is portable as-is — only the Gmail and Calendar wiring changes per host.

The exact wiring will depend on your stack, but the underlying recipe — three context sources, stateless execution, source-tagged output, aggressive triage — transfers cleanly between platforms.

The point

If you can build a daily brief that you actually rely on, you’ve already done the hard part. You’ve connected the systems that hold your context, you’ve figured out which signals matter, and you’ve made the model produce grounded output instead of plausible nonsense. Every more ambitious workflow — the agent that drafts replies, the assistant that runs your week, the operating system you keep meaning to build for yourself — sits on top of those same foundations.

The daily brief isn’t the unsexy answer to what AI can do. It’s the canary. If yours is working, the rest is reachable. If it isn’t, the rest is a long way off.