Morning Brief as a Product

At 6am a brief lands in my inbox. It is written by my own harness, from my calendar, my open loops and a few other feeds. Some mornings the subject line starts with a warning: degraded, one section missing, here is which one and why.

That warning is the best feature the brief has. It took me a long time to build it, and longer to understand why it matters.

A brief that silently drops a section looks fine. It reads well. It is also lying to you by omission, and you will not know until you walk into a meeting it forgot to mention. Once that happens twice, you stop trusting the whole thing and go back to scrolling your calendar at the kitchen bench.

So the lesson I keep relearning is not about prompts. It is about product. A morning brief has a customer, even if the customer is you.

Run it like a pre-start

In operations, good shifts start with a pre-start. Five or ten minutes, standing up. Safety first. Then volume, staffing, and what is different about today: a late truck, a broken scanner, a new process going live. Nobody reads the whole overnight log aloud. The supervisor has already done the editing.

That editing is the product. Anyone can dump yesterday's notifications into a summary. The value is in deciding what the team needs to know before the day starts, and what they can safely ignore.

My brief has four jobs, and only four:

1. What is fixed today: meetings and hard commitments.
2. What is at risk: loops that are overdue, and days where the load does not fit.
3. What I should not do: things I could drop or defer.
4. One cue outside work that keeps me honest about the rest of my life.

If a section does not serve one of those, it goes. More sources will not save a brief that has no shape.

One pipeline, many triggers

The expensive mistake I made was building clever copies.

The brief first ran on my laptop. When the laptop slept, the brief did not arrive. So I built a cloud version. Then a version I could trigger from my phone. Each fix was sensible on the day. Together they became three things to maintain, drifting apart a little every week.

The low point was a leaner cloud rewrite that was meant to be simpler. It was simpler. It had also dropped the sections that made the brief worth reading. Each copy had been a fix for the symptom in front of me. What I skipped every time was the five whys: ask why, then why again, and keep asking until you reach the root cause. Most of us would rather jump into solution mode than ask the hard questions and understand the root cause. I did exactly that, three times.

The rule that survived is boring. One codepath. One section contract that says what each section contains and what it must never contain. Several triggers: a schedule, an on-demand call, a manual pull. If I need the brief somewhere new, I add a trigger. I do not add a copy.

Boring engineering is what makes it a product. The brief writes to a file first and then sends the file, because building HTML inside a shell string is how briefs arrive mangled. Calendar data comes from a proper sync that understands recurring meetings, because one invented meeting does more damage than any number of good summaries.

What I measure

I do not measure word count or how clever the summary sounds. I measure four things:

• Time from opening the brief to my first useful decision.
• Wrong meetings: anything invented, duplicated or on the wrong day.
• Section debt: any section I skip three mornings running gets cut.
• Maintenance minutes per month. If that number climbs, the product is failing, however good it reads.

Drafts, not sends

The brief can prepare a reply. It can suggest a message to move a meeting. It cannot send either. That rule lives in the code: the tool that writes the brief has no way to send email on my behalf. The paragraph in my instructions that says "never send" is there for the humans. The missing capability is what actually holds the line.

That one choice removes most of the anxiety of running an AI chief of staff. The worst it can do is prepare something bad, and I will see it before anyone else does.

What this means for teams

Most leadership teams already have some version of a morning brief. Often it is a person, or a script on one person's laptop, or a dashboard nobody opens before nine.

Treat it as a service with an owner. Write the section contract down. Decide what must never appear in it, and test for that. Make it report its own gaps loudly. And ask the question every pre-start asks: what do people need to know before the day starts, and what can they ignore?

The pre-start works because someone edited the night before it got to you. Your brief should too.

If your morning brief lost a section tomorrow, would you notice, and would it tell you?