Build Log4 min read

Build Log 01 — A daily AI briefing that writes itself overnight

Hours of podcasts and feeds for one usable insight. So I built a scheduled AI task that does the extraction overnight and ships a six-section briefing to my inbox by morning. The build decision that mattered: a written spec, not a clever prompt.


My information diet had a bad exchange rate. Hours of podcasts, newsletters, and feeds for one insight I could actually use. And that was a good day. The worse days were the ones where the thing I needed to know never crossed my feed at all.

That's a leaky bucket. Just for attention instead of revenue.

So I built my first scheduled Cowork task: a briefing that assembles itself overnight and lands in my inbox at midnight. I read it with my morning coffee.

What it actually does

Every weekday the task runs a pipeline. Web search pulls AI and growth news from the last 24 to 48 hours. Google Calendar feeds today's schedule, with transit routing between blocks. Google Drive supplies my MMA training log so the briefing can tell me what to drill, or when not to train at all. Gmail, connected through Zapier, delivers the result as a formatted email.

Six sections come out the other side:

  • AI brief — named companies, measurable outcomes, no vendor PR.
  • Product and growth brief — a few moves I can steal into client work this week.
  • Today's schedule — calendar plus transit routing between blocks.
  • MMA check-in — what to drill, or REST TODAY when training load says so.
  • Coffee recommendation — a single roaster pour, rotated.
  • One content idea — a writing prompt I'd actually publish.

Three minutes to read. Two or three things I can act on.

The actionable part took the most work to get right.

System map of the midnight briefing pipeline: four connected sources converge into a written spec acting as a quality gate, then a scheduled task assembles six sections and delivers an email to the inbox at midnight.
Fig. 01 — The briefing pipeline. Connected sources pass through a written spec, the quality gate, before the scheduled task assembles six sections and ships the email.

Why a spec beats a prompt

Before I scheduled anything, I wrote a skill: a standing document that defines what “good” looks like for every section, and the system reads it on every run. The scheduled task is just execution. The skill is the requirements doc.

Any PM will recognize the move. It's writing the PRD before the sprint, not after the demo disappoints you.

And the first demo disappointed me.

Version one was useless in a familiar way

The early outputs were broad. A typical item: “AI was leveraged to improve conversion rates.”

Leveraged how? By whom? What was the lift? It read like news and functioned like noise. A vague experiment hypothesis fails the same way: if you can't act on it, it doesn't matter how fast it shipped.

If an item can't name a real company and a measurable outcome, cut it.

“Companies are rethinking onboarding with AI” doesn't survive that rule. “Slack rebuilt onboarding around getting teams to 2,000 messages exchanged, after finding that 93% of teams who hit that mark kept using the product” does. One of those changes how I'd run a client standup. The other is filler.

The refinements that followed used the same loop: find the failure, write the rule into the spec. Technical jargon now gets a one-sentence plain-English explanation, because a briefing I can't re-explain to a client without hand-waving isn't doing its job. The MMA section got a hard gate: when my accumulated training load says rest, the briefing leads with REST TODAY, no softening. I have a documented habit of skipping rest days, so I built a system with permission to push back on me. And the briefing task now chains into two other skills I'd already written for training and recovery. Skills calling skills. The spec layer compounds.

What I'm still figuring out

I'm early in this. Some mornings an item still slips through generic, and the coffee rotation repeats itself more than it should. But the iteration loop feels familiar. When output quality drops, I don't re-prompt and hope. I go fix the spec. Hypothesis, build, result, revise — the same loop as any growth experiment, pointed at my own workflow.

The hours come back, but the bigger change is the shape of the morning. I used to hunt across sources and hope something useful surfaced. Now the surfacing happens overnight, and my attention goes to the part I can't automate: deciding what to double down on.

How to steal this pattern

If you're building any kind of AI workflow — a daily briefing, an inbox triager, an experiment-summary bot — put the quality bar in a written spec the system reads every time, not in the prompt you happen to type that day.

The shape that works for me:

  1. Write a spec before the first run. Define what “good” looks like per section, in one or two sentences each.
  2. Ship the first version anyway. The spec gets sharper when you see it fail.
  3. When an output disappoints, fix the spec, not the prompt. Re-prompting drifts; spec edits compound.
  4. Let skills call skills. Once one spec works, chain it from others instead of duplicating rules.

The same loop powers the first-90-days work I do for subscription clients — ship the hypothesis, watch the cohort, fix the rule, not the dashboard. The mechanism is the same; only the surface changes.

Steal the one rule, at minimum: no company, no metric, no item. It's one sentence, and it's the difference between a feed and a briefing.


Work with me

Running this play on a real subscription?

First-90-days engagements for Performance Health companies before Series B. Three or four per year.

Q3 2026: 2 of 2 spots open · 48-hr response

More reading