Get a Morning Briefing from Sarah Grant

A great first Digital Employee is one who sends you a Morning Briefing on weekdays.

Meet Sarah Grant.

She is my BD Manager. One of her responsibilities is to send me a Morning Briefing.

Reads my calendar, inbox, and pipeline every morning, tells me how I am tracking on my goals and where I need to step up, and sends it all in an email each weekday at 7 AM.

It is also the first DE I would build if I were starting over, and I want to be specific about why.

It runs daily, so you get repetitions fast, and repetitions are how the instructions get sharp.

You can tell in thirty seconds whether it is any good. Did it miss the meeting I needed to prep for? Did it flag something I already handled?

And when it is wrong, it costs you a minute. That matters because you are going to get the instructions wrong the first few times.

Most people jump to building something complex.

Would you trust a new employee to work your most complex work on Day 1? No. You ramp up the work as they prove themselves.

Take that same approach to an AI employee.

Schedule a Task in ChatGPT or Gemini. A Claude Code Routine in Claude.

Here is how to do it with Claude Code Routines.

Name: sarah-grant-morning-briefing

Description: My Morning Briefing for Accountability tracking

Instructions: The rules to run the Morning Briefing

Environment: Default

Cloud or local: mine lives in a GitHub repo called ‘THINK Internal’.

Connectors: Gmail or your email tool, for reading. Resend or Zapier MCP for sending. Wherever your CRM data lives, Notion, HubSpot, Airtable, or a spreadsheet. Add your goal tracking and social data if you have them.

Schedule: Weekdays at 7 AM

The instruction isn't one long block. It's part context, part markdown file references. Claude Code Routines is the container that reads them.

Split the way you'd split a job:

Same as hiring a person. Nobody hands a new employee one wall of text.

Build your Morning Briefing as if you were providing instructions to a human employee.

Here is a snapshot from my July 10th report.

And this is what mine looks like.

If you want to skip creating the instruction, THINK School members can access it here.

Four things do most of the work in that instruction, and if you understand why, you will write better instructions for every DE after this one.

Tell it what it cannot touch. Read-only, no sending, no commits. Your first DE should not be able to do anything embarrassing. This is not caution for its own sake — it is what lets you leave it running unattended without checking on it. Every DE I build starts here.

Tell it not to pad.

Without that instruction, you get filler. Nothing in the inbox becomes three paragraphs about how quiet the inbox is. A briefing that pads is a briefing you stop reading by Thursday.

Tell it to continue when a connector fails.

Connectors fail. Without this, one timeout kills the whole run, and you get nothing at 7 AM, which is worse than a partial page. Say what happens on failure, or the failure decides for you.

Tell it to skip stale data rather than report it as current.

Stale metrics presented as fresh are worse than no metrics. This is the line that keeps you from making a Tuesday decision on Friday's numbers.

Those four are the difference between a briefing you read every morning and one you mute in a month.

It will. Mine surfaced threads I had already replied to for the first week, which made me distrust the entire page.

The fix is never to rewrite the output. Go back to the instruction and change the rule that produced it.

I added one line about checking whether I had already replied. Wrote it once. It has been held every morning since.

That is the discipline, and it is the skill you are building.

Once Sarah’s Morning Briefing runs cleanly for a week, add to Sarah’s job duties by having her read your inbox, prioritize responses, and draft replies.

Sarah slowly moves from an automaton to a teammate, filling a role for you.

-Marvin

Want to fill an open role with a Digital Employee?
Message me.