Alessandro Sillato

Every Monday morning, I used to spend the first 30 to 40 minutes of my day doing the same thing: figuring out what was on fire, what could wait, and what I had forgotten to reply to the week before. As an IT Manager at a large company, my inbox is a permanent mix of SLA violations, vendor escalations, project updates, and the occasional “did you see this?” email that quietly becomes a crisis by Wednesday.

I decided to automate that ritual. What I built is a weekly AI-powered email briefing that lands in my Notion workspace every Monday morning, structured, prioritized, and actionable, generated from my Outlook inbox, powered by Claude, and orchestrated by n8n. No backend. No custom code deployment. No expensive SaaS tools.

But the most interesting thing I learned along the way had nothing to do with the technology.

The stack

Four tools, one pipeline: Microsoft Outlook as the email source, n8n as the automation orchestrator (self-hosted on my VPS), Claude via the Anthropic API as the intelligence layer, and Notion as the destination where the report appears.

Every Monday at 8:00 AM, the workflow pulls every email from the past seven days from Outlook, sends them to Claude for analysis, and writes a formatted report into a Notion database. The whole process takes under two minutes.

What the report looks like

The output is not a dump of emails. Claude produces a structured intelligence briefing organized into sections: critical items requiring immediate action, medium priority follow-ups, low priority monitoring, emails I sent that never got a reply, weekly metrics, and a prioritized to-do list for the week ahead.

When I open Notion on Monday morning, I have a situational briefing that would have taken me 40 minutes to build manually. I start the week already knowing what matters.

Three things I had to learn the hard way

Prompt engineering is product design. The difference between a useful report and a useless one is not the AI model. It is the prompt. I went through at least six iterations. Explicit format constraints work better than vague instructions. Telling Claude to use bullet points, limit to five items per section, and not repeat the same item across sections eliminated roughly 30% of redundant content and made the output genuinely usable.

The token problem is an architecture problem. Early on, I was sending a full week of raw email JSON to the API, including conversation IDs, full recipient arrays, and thread metadata that added tokens without adding any analytical value. I hit rate limits before I hit insight. The fix was data hygiene upstream: strip everything irrelevant before the AI call. Input size dropped by 70%. Output quality stayed the same.

Native nodes have limits; HTTP requests do not. n8n’s Notion node is convenient but opinionated. For anything beyond simple field writes, switching to a raw HTTP Request gives you full control over the Notion API. Once I made that switch, the block limit problem disappeared entirely.

The pattern underneath

What I actually built is a context aggregation and intelligence layer. Pull data. Strip noise. Structure with AI. Write to a knowledge base. The same pattern applies to almost any operational workflow: ticket briefings from an IT system, SLA monitoring with proactive alerts, meeting note summarization, vendor communication tracking. The architecture is reusable. The prompt changes. The data source changes. The intelligence layer stays the same.

I am already working on connecting the same pipeline to our IT ticketing system for daily briefings with SLA countdowns and escalation flags.

What this taught me about AI

Here is the thing I keep coming back to. This system does not make decisions for me. I still read every flagged item. I still make every call. What it does is eliminate the cognitive overhead of orientation, the 40 minutes I used to spend just figuring out where I stood before I could even start thinking.

AI does not replace judgment. It prepares you to exercise it. And for knowledge workers, that distinction matters more than almost anything else in how we think about what these tools are actually for.