Turn the Information Firehose Into Something You Can Use
Event / Source
Internal AI enablement work · Microsoft 365 Copilot · Notion · September 2026
The business problem
Our small team needed to be stay on top of and be aware of new Copilot features and test them.
We were busy building current curriculum, with current features and training on those. But Copilot and M365 is always adding new features to its suite of apps. We were at risk of missing something valuable.
We’d relied on adhoc alerts: someone sees an announcement. Someone notices something new inside Copilot. Someone remembers to check the Microsoft 365 Roadmap. We test features when we hear about them and update materials when we realize something has changed.
The obvious problem: How do we know what we don’t know?
We needed a way to continuously answer:
What actually launched?
What changes our curriculum?
What should we test?
And what changed since the last time we looked?
I didn’t want another newsletter or another pile of browser tabs. I wanted a system.
What I built
I built a Notion agent to harvest Microsoft’s public Microsoft 365 Roadmap.
Instead of a person repeatedly searching the roadmap, the agent checks it on a schedule and turns relevant product updates into structured records in a Notion database.
The first version was intentionally simple.
Pull the features. Add them to the database. Don’t create duplicates. Categorize them so we can decide what deserves attention.
But testing the V1 immediately exposed a more interesting problem.
Finding product announcements wasn’t enough.
The system needed to understand the lifecycle of a feature.
Something that’s “In Development” isn’t useful to a team that needs to test Copilot today. Something that’s “Launched” might require immediate attention. Something that’s “Rolling Out” may be available to some users but not others.
So the workflow evolved.
The workflow
1. Monitor
The agent checks the Microsoft 365 Roadmap for relevant changes.
2. Capture
Each feature becomes a structured record rather than another piece of information someone has to remember.
The database captures things like:
Feature
Microsoft product
Roadmap status
Platform
Rollout timing
Source
Description
3. Filter
Not every Microsoft update deserves equal attention.
The system sorts features into three working categories:
TEST
The feature is available and relevant to a product or workflow we actually use, teach or support.
WATCH
The feature looks relevant, but it isn’t actionable yet.
SKIP
Interesting to Microsoft. Not important to our current work.
The value comes from reducing the amount of information a human has to evaluate.
Then we found the more interesting use case
During a review of the prototype, we realized the Microsoft Roadmap itself isn’t enough.
A roadmap entry might tell us that a feature exists, but if we’re going to evaluate it, teach it or recommend it, we need more context.
So the next layer is research.
For relevant features, an agent can look beyond the original roadmap entry for:
Microsoft Learn documentation
Product documentation
Demonstration videos
Tutorials
Other useful explanations of the feature
That information can then be appended to the existing Notion record.
Now the database isn’t simply telling us:
“Microsoft launched something.”
It’s starting to tell us:
“Microsoft launched something relevant to your work. Here’s what it does, here’s where you can learn more, and this is something you should test.”
That’s the kind of valuable detail I want AI to give me at the beginning of my work day.
Tool stack
Notion
The working database and knowledge layer. It stores features, statuses, categories, source material and eventually testing notes.
Notion Agent
Monitors the source, structures incoming information, checks existing records and helps classify what deserves attention.
Microsoft 365 Roadmap
The primary source of product and feature updates.
Web research / secondary research agent
Adds documentation, demonstrations and learning resources to relevant feature records rather than relying only on the original roadmap description.
Claude
A downstream thinking and synthesis layer. Once the structured information exists, it can be used to summarize what changed, identify patterns, help create briefs or turn completed testing into longer-form material.
The important part isn’t any individual tool.
It’s the handoff:
Source → Agent → Structured database → Human evaluation → Research → Testing → Reusable knowledge
Tweaks I made
Deciding what the information meant once we had it. What counts as “new”?
What happens when an existing feature changes status? Should the agent create another record or update the existing one?
When is something ready to test?
Which products matter? Do we need to know about all of them?
Without these business-rule questions we just have more work on us to decipher and decide.
Business impact
The goal isn’t just to log all the updates and features in a new spot. It’s already on the M365 site.
Instead, it’s to remove a recurring piece of cognitive overhead from the team. Turn it into ACTIONABLE INFORMATION.
Instead of relying on someone to remember to check for updates, interpret them, figure out whether they matter and tell everyone else, we can create a repeatable operating rhythm:
Detect → Filter → Research → Test → Learn → Update
That creates a single place to see what has changed, what deserves testing, what we’ve already evaluated and eventually what those changes mean for training, workflows and client recommendations. And assign the testing to a team member. Delegating tasks helps you cover more ground
It also creates institutional memory.
Six months from now, we shouldn’t have to ask: “Didn’t we test that feature at some point?” That’s critical for a client meeting: to have a full checklist of features that we vetted vs a panicked feeling like we missed something is GOLD, Jerry, GOLD.
What I’m keeping
Monitoring isn’t the same thing as intelligence.
Getting information into a database is easy. Anybody can do that. But we all know how more data can just cause overwhelm.
The interesting work starts when you decide what deserves attention, what action it should trigger and what should happen when the underlying information changes.
Agents become much more useful when they’re attached to a decision system.
“Find new Microsoft features” is useful.
“Find new Microsoft features, determine which ones affect our work, flag the ones we can actually test, research them and preserve what we learn” is a workflow.
Structured information compounds.
Once the roadmap information lives in a database instead of someone’s browser history, you can keep building on it. THIS is my favorite feature of this workflow: what else it can spawn.
Testing notes can attach to it.
Training updates can reference it.
A monthly recap can summarize it.
A two-minute feature demonstration can come from it.
A future agent can query it.
The same piece of information stops being consumed once and forgotten.
How this changes my work
I’m becoming much less interested in building isolated AI automations.
I’m more interested in building small operational systems that keep getting more useful as information moves through them.
In this case, the first question was: How do we keep up with Microsoft feature updates?
But the more valuable question turned out to be: How do we turn a constant stream of new information into knowledge that compounds over time? This system gives the team something much more valuable than a list of new features: it gives us confidence that we’re current, depth of knowledge about the tools we use, and a growing body of tested experience we can keep putting to work.
The TL;DR
Source: Microsoft 365 Roadmap
Trigger: Notion Agent runs on a schedule
Capture: New relevant features are added to a structured database
Update: Existing features are updated when rollout status changes rather than duplicated
Decision rules: Features are classified as Test, Watch or Skip based on availability and business relevance
Enrichment: Relevant features are researched for documentation, demos and learning resources
Human step: Features marked Test are evaluated before anything changes in training or client guidance
For Agent 2 in this workflow:
Use a trigger, not a schedule. Agent 2 should run only when something has actually been classified TEST. Notion specifically recommends triggering Custom Agents on specific property changes rather than general database updates, which also saves agent credits.