The Monday Morning Brief – what it took to build an assistant that reads my week before I do

I spend the first hour of most Mondays reconstructing the week I just finished.

Which calls happened. What I committed to on those calls. Which emails are still open with someone waiting on me. What is coming this week that I have not looked at closely enough yet.

It is not difficult work. It is just work that has to happen before any real work can start, and it happens every single week. Fifty times a year, one hour at a time.

So I built something to do it instead.

What I asked for

One email, every Monday at 7:00 AM. It should tell me what happened last week and what I owe people this week.

The inputs were the obvious ones – my meeting notes, my calendar, and my email. I have close to a hundred auto-generated meeting summaries sitting in a Drive folder, going back a year. My calendar knows what I attended. My inbox knows who is still waiting on a reply. Every piece of the answer already existed. None of it was ever assembled into one view.

The information was not missing. It was scattered.

What got built

A scheduled agent with access to my calendar, my Drive, and my inbox. Every Monday morning it does what I would do, in the order I would do it.

Pull last week’s calendar to see what actually happened. Find the meeting notes generated from those calls and read the decisions and follow-ups out of each one. Sweep the inbox for threads where someone is waiting on me. Pull the coming week’s calendar. Then write the brief and send it.

The output has a fixed shape – three to five judgment calls at the top under “What matters this week,” then a section per client covering what moved and what is stuck, then a prioritized task list, then the week ahead, then a short list of who owes me what.

Anything can list your meetings. The value is in a system willing to say this deadline is at risk and here is why.

What changed once I could see it

Three things, and all three came from looking at a real draft rather than from planning.

The task list changed sources. My first instinct was to pull the week’s tasks from my project tracker, since that is where tasks are supposed to live. Looking at the first draft, that was backwards. The tracker holds what I already knew to write down. The commitments that actually slip are the ones I made out loud on a call on Thursday afternoon and never captured. So the brief now derives the list from what I said I would do in meetings, plus what is sitting unanswered in email. The tracker is a record. The brief is a catch.

It had to learn what is not correspondence. My inbox is full of email I send to myself. I have an automation that emails production queue notifications to a client contact and copies me, and the first version dutifully reported those as important activity. They are not activity. They are output from a system I already built. The brief now knows to skip them.

It had to get quieter about some things and louder about others. Recurring reminders for loan payments are real calendar entries and completely uninteresting in a weekly summary. They collapse to one line now. Meanwhile, anything that puts a personal commitment on top of a work obligation got promoted to the top of the brief.

What broke

Four things, none of them exotic, all of them the kind of detail that separates a demo from something you actually rely on.

One account per connection. My business email was connected. My personal account was not, and there was no way to add a second without dropping the first. Resolved. I shared the personal calendar into the business account instead. It now appears in the same calendar list, with no second connection and nothing to maintain. When a tool will not do what you want, check whether the data has another route in.

The meeting notes were too big to read. Each note document holds a clean summary followed by a full verbatim transcript, ten to twenty times longer and useless to a weekly brief. Reading them whole failed on size. Resolved. Stop reading them whole. Cut each document at the transcript heading and keep only the summary, decisions, and follow-ups.

Email search lies about threads. Inbox search returns a preview showing the oldest messages, not the newest. A thread I had already answered on Saturday looked identical to one where I had gone silent. Resolved. Open any ambiguous thread in full before deciding whether the ball is in my court. Left alone, this produces a brief that nags you about finished work, which is the fastest way to stop reading it.

All-day events end a day late. A calendar event ending August 31 actually runs through August 30. Get that wrong and a three-day trip becomes a four-day trip in the summary. Resolved. Compute the real span before describing it. Small bug, embarrassing in a document whose entire job is telling you where your time went.

There is one more sitting in the future. The schedule runs in UTC, so when daylight saving ends in November the brief will start arriving at 6:00 AM instead of 7:00. Known, dated, and easy to fix. Worth writing down rather than rediscovering in a dark kitchen.

The part I did not expect

The first working version was business-only, because my personal calendar was not connected yet. It read well. It was also wrong in a way I would not have caught.

Once the personal calendar was added and the brief was regenerated, the top of the document changed completely. I have a family wedding out of town this Friday through Sunday. My client contact on an ERP go-live is out all week. The go-live is the following Wednesday, and the project still needs roughly three days of physical inventory counting that nobody has scheduled.

Each of those three facts lived in a different system. The travel was in my personal calendar. The client’s absence was mentioned once, out loud, on a Friday call. The unscheduled inventory count was a follow-up item in a meeting note. Every one of them was individually harmless. Together they meant the last week before go-live had about four usable days in it.

If you are thinking about building something similar

Build it against a real week, not a hypothetical one. Every meaningful change I made came from reading an actual draft and thinking “that is wrong,” which is not a thought you can have about a specification.

Expect to spend your time on judgment, not on connections. Wiring up a calendar takes minutes. Teaching a system which three of your forty calendar entries deserve to lead the summary is the actual work, and it is worth doing carefully.

Be honest about what you are really building. I did not build a report. I built a standing cross-check between systems that were never designed to talk to each other, which is where most of the friction in a growing business lives. Every system in your building has an owner. The connections between them usually do not.

That gap is nobody’s fault. It is also nobody’s job, which is why it persists.