The daily morning brief.

Why the morning brief is the right first automation CORE

Of the four patterns you will build in this module, the morning brief is the one most students find useful on the first day. There are three reasons to start here, and knowing them will help you not confuse this task with tasks it looks like but is not.

First, the morning brief has immediate payoff. The first time you wake up to a one-page summary of what’s in your inbox and on your calendar, with the three things that actually want your attention called out, you start the day already oriented instead of using the first stretch of it to triage. Students who build a weekly report first often abandon the module before the Sunday run happens; students who build the morning brief first read it tomorrow and come back excited.

Second, the morning brief exercises every part of the five-move loop. You have to plan the scope (which inbox label, which calendar), plan the artifact shape, wire the trigger, write the prompt, define the idempotency key (date), pick the delivery target, and design the log. If you can build a morning brief you can build the other three patterns in this module.

Third, the morning brief is the lowest-stakes place to make mistakes with scheduled agents, because the audience is literally you. The worst case for a bad morning brief is that you read it, notice it’s not useful, and re-prompt. There is no relational consequence, no outbound send, no third party. This is the right place to learn what the agent does well on a schedule and what it gets reliably wrong.

One thing to be honest about: a morning brief is not magic. An agent reading your inbox is not smart about your inbox the way you are. It will sometimes rank the wrong message at the top. It will sometimes miss the subtle line that mattered in a long thread. Your job in the first three days of running it is not to celebrate; it is to read critically and tighten the prompt. The activity below makes you run the brief three days in a row specifically so you can see what changes and what stays the same across runs.

The brief’s structure: five sections, reviewable at a glance CORE

A morning brief that follows a predictable structure is easy to scan, easy to trust, and easy to debug. A brief that is a wall of paragraphs is slower to read than the inbox it is supposed to save you from. Design the structure once; enforce it in the prompt; review the same shape every morning.

The five sections this course recommends — you may adapt them, but start here:

1. Header line. One line. Run timestamp, today’s date, brief ID. The header lets you notice at a glance whether the brief you’re reading is today’s brief or yesterday’s. This is the observability minimum — every artifact in Module 6 opens with a header line.
2. Three things that want your attention today. A numbered list, maximum three items. Each item is one sentence: what it is, why it matters today, what action it wants from you. “Draft due by 3 PM for Ms. Rivera’s class — thread is in agent-access/school with three open questions.” Not a paragraph. Not a section. One sentence per item, capped at three.
3. Inbox summary for the bounded label. A categorized list of what’s in your agent-access label since yesterday’s run. Categories match the Module 5 shape — needs-reply, FYI, newsletter, waiting-on-me. Counts per category. No content yet — the counts and the one-line subjects only.
4. Calendar preview — today and tomorrow. Today’s blocks and tomorrow’s blocks from your Agent Access calendar and any read-only calendars you have permitted the agent to see for conflict-checking. Flag any conflicts or back-to-back items under 15 minutes apart.
5. Brief footer — health and honesty signals. What the brief could not do. “Three emails in the label had attachments the agent could not read.” “The agent was told not to open the thread with subject X because it contained a keyword in your sensitivity list.” “One calendar permission returned an error; conflict-check may be incomplete.” Explicit admissions of limits, so the reviewer knows where their own judgment has to fill in.

This structure has two properties the module cares about. It is bounded — the agent cannot produce a runaway wall of text even if it wants to, because the prompt caps sections two and three. And it is honest — the footer forces the agent to declare what it did not do, which is the single best defense against a brief that silently stopped working. If you stop seeing a footer, something changed.

The structure is also the scaffold for critical reading. When you read your brief at breakfast, you’re not reading it as prose; you’re auditing five specific sections. Section 2 wrong? Either your scope is wrong or the prompt’s “what wants your attention” heuristic is wrong. Section 3 wrong? Your label is likely misconfigured. Section 4 wrong? A calendar permission issue. Section 5 empty? The agent has lost the habit of admitting limits and the prompt needs a reminder.

The brief-shaping prompt: scope, sections, length, voice, honesty rails CORE

The prompt you write for a scheduled task is not a chat prompt. A chat prompt is a line you write once and iterate on in the same session. A scheduled prompt runs every day for weeks. It has to be precise enough to produce the same shape in the agent’s voice on Tuesday that it produced on Monday, even as the underlying data changes. This is a specific skill the module teaches, and the brief is the best place to learn it.

The five parts of a good scheduled prompt:

• Scope. Name the exact inputs. “Read the agent-access label for messages received since 18:00 yesterday. Read the Agent Access calendar and the primary calendar (read-only) for today and tomorrow.” Not “read my email.” The more specific the scope, the more stable the output.
• Sections. Name the output structure. “Produce a Markdown file with exactly five sections, in this order: Header, Three things that want my attention today (max 3 items), Inbox summary (categorized counts and one-line subjects), Calendar preview (today and tomorrow, flag conflicts under 15 minutes), Health footer (what you could not do).” List the sections; cap the lengths.
• Length. Put hard ceilings on the parts most likely to drift. “Three things section: exactly three items or fewer, one sentence each. Inbox summary: ten subject lines per category maximum. Calendar preview: one line per event.”
• Voice. Write one sentence about tone. “Direct. Not cheerful. Do not greet me. Do not sign off. No emojis.”
• Honesty rails. Explicit instructions about what counts as failure and how to surface it. “If any scope is unavailable, produce the brief anyway with the available sections and record the missing scope in the Health footer. If no new messages arrived, produce the brief anyway with zero-count sections. Never invent an item for section 2 to fill space. If fewer than three items warrant the top-three list, produce one or two, not three.”

Read those five parts again with the same skepticism you read the prompts in Modules 3, 4, and 5 with. Each part exists because a student shipped a scheduled task that failed that part’s test, and the prompt-rail was how they fixed it. The last one — never invent an item for section 2 to fill space — is a rail the course added after observing that agents will happily manufacture a third top-three item to match a request for three. Tell the agent not to.

The worksheet at morning-brief prompt template provides the template text. You will fill in the scope and the length numbers; the section shapes and the honesty rails are pre-written and should be used as-is in your first run.

The three-day read: what you are actually looking for CORE

The activity below asks you to run the brief three days in a row and review each one honestly. The purpose is not to confirm the brief works; it is to find the places where it silently misrepresents your day.

Specifically, read each day’s brief and ask:

• Did section 2 name the right three things? Not “were the three things accurate” — any three items in your inbox are accurate — but were those the three that would have wanted your attention if a careful human friend had summarized your day for you? If the brief put a newsletter in the top three and missed a teacher asking a direct question, your three-things prompt is wrong.
• Does the inbox summary match what you’d have said? Open your label, look at the same messages, and mentally categorize. Does your categorization match the agent’s? If not, the Module 5 label is probably the easier fix — the agent is categorizing correctly given what it sees; you just need to adjust what it sees.
• Is the calendar preview aware of commitments outside its scope? It cannot be. That is the point of the permission posture from Module 5. Note which conflicts the agent missed because they live on a calendar the agent does not read, and decide whether to extend scope (widen access) or to live with the gap (safer default).
• Did the footer actually say anything? A footer that reads “no issues” every day, every week, for a month is suspicious. Real briefs have small honest limits — attachments not read, a calendar permission briefly denied, a thread the agent refused to open. A footer that is always empty means the agent stopped reporting limits. Time to remind it.
• Did anything in the brief surprise you in a way that made you take action you would not have taken otherwise? This is the why you built it test. If after a week the brief has not once caused a single productive act you would not have otherwise done, the brief is cosmetic. Retire or re-scope.

You will tighten the prompt at least once during the three-day run. Keep a small prompt change log at the top of the register entry — one line per change, with the date and one sentence of reason. Students who change the prompt silently end up six weeks later unable to explain why their scheduled task does what it does.

Why the date is the idempotency key — and what the trap is CORE

Naming the idempotency key for a morning brief is easy: it’s the date. brief-2026-04-22.md. Re-run on the same day, overwrite. No confusion.

The trap is subtler. The date-as-key works only if the run time zone is stable. If your scheduler fires in local time and you travel to a different time zone, a run at “06:30 local” produces a file stamped with one date; a run triggered at “06:30 local” the next day in the new zone may straddle the date boundary and produce a file with an unexpected name, or with the same name as an earlier run. Students who travel across time zones during the module occasionally produce double briefs or missed briefs for this reason.

The fix is simple: pick one time zone as the canonical one — usually the student’s home time zone — and compute the brief’s date from it explicitly, regardless of where the machine is. The recipe does this for you in both paths. You do not need to do the conversion math; you do need to know why the prompt names a time zone and why you should not change it casually.

A second smaller trap: if the brief’s run skips a day (laptop asleep, scheduler not running), the next run should not try to “catch up” by producing two briefs. It should produce today’s brief and leave a note in section 5: “Yesterday’s run did not fire.” This is a form of idempotency too — the task’s intent is produce today’s brief, not ensure the last N days have been briefed. The prompt enforces this.