The Monday Morning Brief: what it took to build an assistant that reads my week

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. Here is what I asked for, what got built, what I changed once I could see it, and the four things that broke along the way.

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.

That last sentence is the whole project. 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.

The top section is the part that matters. 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. More on that below, because it turned out to be the point.

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 connector. My business email is connected. My personal Google account is not, and there is no way to connect a second one without disconnecting the first. The obvious move is to fight this. The better move is to notice that Google already solves it: I shared my personal calendar into my business account. 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 auto-generated note document contains a clean summary followed by a full verbatim transcript. The transcript is ten to twenty times longer than the summary and adds nothing a weekly brief needs. Reading them whole failed on size. The fix was to stop reading them whole: cut the document at the transcript heading and keep only the summary, decisions, and follow-ups. Obvious in hindsight. Not obvious at the time.

Email search lies about threads. Searching the inbox returns a preview of each conversation showing the oldest messages, not the newest. A thread where I had already replied on Saturday looked exactly like a thread where I had gone silent. Left alone, this produces a brief that nags you about things you already finished, which is the fastest way to make someone stop reading. The brief now opens any ambiguous thread in full before deciding whether the ball is in my court.

All-day events end a day later than they say. 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. 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.

No single tool I own could have told me that, because no single tool holds all three facts. That gap is the thing worth automating. Not the summarizing. The cross-checking.

If you are thinking about building something similar

A few things I would tell you before you start.

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.

And 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.

That gap is nobody’s fault. It is also nobody’s job, and that combination is exactly why it persists.