Key takeaways
Key takeaways

Key takeaways

What this agent does

Every morning at a time you set, the agent calls the Microsoft Graph API and pulls the last twenty-four hours of messages from each whitelisted channel. For each message it asks one question: does the user need to know about this today? Then it groups everything that survived the question into a single digest and posts it to the user as a Teams personal chat message.

The user opens Teams, sees the digest at the top of their chat list, reads it in under three minutes, and decides which threads to click into. Most days they click into one or two. Some days zero. That is the point.

What the agent does not do: it does not reply to anyone, react with emoji, mark messages as read, or move them to folders. It does not summarise direct messages between you and your manager unless you specifically opt in for that chat. It does not browse SharePoint files linked in the channel. It does not transcribe audio messages. Every one of those was tried, every one of those produced more noise than signal.

If you want a deeper read on the pattern behind agents like this, the founder write-up at what an AI agent can actually do covers the constraints that keep them useful.

Sources of truth

The agent reads Microsoft 365 only. No Slack, no email, no Notion. Mixing sources introduces ambiguity the agent cannot resolve without asking, and the whole point of a morning digest is to not be asked.

That is the entire surface. If the agent finds a thread that links to a Jira ticket, a Figma file, or a Confluence page, it includes the link but does not fetch the target. The user clicks if they need to. This keeps the digest fast and prevents the agent from fanning out into systems it does not understand.

Five filters that decide what is in the digest

A typical user is in twelve channels. A busy day across those twelve channels is between four hundred and eight hundred messages. The digest fits in three minutes of reading. So roughly ninety-five out of every hundred messages do not make it. The agent picks the five that do using five filters, applied in order. Any one filter is enough to include a message.

Filter 1: Direct mentions

Any message that @mentions the user is included. No scoring. No exceptions. This is the only filter that runs first because mentioning someone is the explicit signal a teammate sends that they need that person to see this thread.

Filter 2: Decisions

The agent looks for messages that resolve an open question. Patterns like "we will go with", "let us ship", "decision is", or threads that have replies followed by a long silence and then a single message that ends the chain. Decisions are surfaced because they cause downstream work for people who were not in the thread.

Filter 3: Deadlines and dates

Anything that names a date in the next fourteen days is checked. If it is a commitment the user is on the hook for, it is included. Customer demo Thursday, release notes due Friday, audit window starts the fifth.

Filter 4: Blocking questions

Questions in channels where the user is a maintainer, owner, or on-call rotation get flagged. The agent does not try to answer them. It just shows you the question and a link to the thread.

Filter 5: Changes to documents you own

If a thread mentions or links to a document where the user is the OneDrive owner, the agent surfaces the change. This catches the case where someone edits your spec without telling you and the edit gets buried under twelve unrelated messages.

The five filters are not exhaustive. Plenty of important conversation slips through, and the digest is honest about that. It ends with a one-line note like "thirty-eight other messages were posted in channels you watch, nothing flagged." If the user disagrees with the agent's filtering, they tell the agent which thread it missed and the agent retrains itself for that filter pattern, the same way it learns in how to train an agent on company docs.

Output: one digest per day

The digest is posted to the user's Teams personal chat as a single rich message. Structure is always the same so the user reads in the same order every day:

  1. Mentions. Five at most. Each shows the channel, sender, one-line summary, and a deep link to the message.
  2. Decisions. Up to five. Each shows the channel, the decision in plain text, who made it, and a link.
  3. Deadlines this week. Bulleted by date.
  4. Open questions in your channels. Three at most. The agent picks the ones with no reply and a sender outside the user's usual collaborators.
  5. Document changes. Only if anything changed.
  6. Tail. One line, total messages reviewed, total channels read, total noise filtered.

That is the entire output. No charts, no scores, no "AI confidence" indicators, no follow-up prompts. The shorter the digest is the more useful it is, and the design constraint is reading time under three minutes for the median user.

Guardrails

The Graph permissions the agent requests are the smallest set that produces the digest. They are listed below because Microsoft 365 administrators ask for them before approving the tenant install.

The agent has no permission to add itself to other channels, invite users, or change tenant settings. If an administrator revokes any scope, the digest degrades gracefully, meetings get dropped, document changes get dropped, but the core mentions and decisions filter keeps working until the channel scope itself is revoked.

Common mistakes

Reading every channel the user has joined. The first version did this. The digest came out to seventy items. People stopped reading it on day three. The fix was the whitelist. Four to eight channels is the sweet spot. If a user wants to add a ninth, they have to retire one of the existing eight. That tradeoff is intentional and is the same constraint discussed in how to give an agent multiple tools.

Summarising the message content instead of surfacing it. Early prototypes paraphrased every thread. The summaries were technically correct and uniformly less useful than the first line of the actual message. Now the digest shows the sender's own words and a deep link. The user reads context in Teams, not in the digest.

Treating reactions as signal. A thumbs up does not mean a decision was made. The agent ignores all reactions, including thirty thumbs up. Decisions come from text.

Running mid-day. Two daily runs sounds reasonable and is not. Users either read both or they read neither. One run at a consistent time wins. For the why, see how to write the prompt for a recurring agent.

Posting in channels. The single biggest temptation. Auto-reply to a "where is the spec?" question, auto-summarise a long thread for the team. Both make the agent visible to everyone in the channel and create a feedback loop where teammates rely on the agent and start writing for it instead of for each other. The digest stays in the personal chat. Always.

Frequently asked questions

Can an AI agent summarise Microsoft Teams channels for me?

Yes. Using the Microsoft Graph API the agent reads channel messages for the channels you whitelist, scores each thread for relevance to you, and posts a digest in your personal chat once per day. It does not summarise direct messages unless you explicitly opt in per chat.

Does the agent read every Teams channel I am a member of?

No. It only reads channels you whitelist during setup. Most users whitelist between four and eight high-traffic channels. The agent ignores the rest. This is intentional. A digest that includes every channel is just a second inbox.

What about meeting recordings and transcripts?

Meeting recordings are off by default. If you turn them on the agent reads the auto-generated transcript stored in OneDrive, extracts decisions and action items assigned to you, and adds a Meetings section to your digest. It does not summarise meetings you did not attend.

Will the agent reply to messages on my behalf?

No. The agent has read-only Graph scopes for channel messages. It cannot send messages, post in channels, or react with emoji. The only writes it performs are to your personal chat with the digest, which uses a separate write scope you grant during setup.

How is this different from Microsoft Copilot in Teams?

Copilot is a synchronous assistant. You ask it questions inside a chat and it answers. This agent runs autonomously at a scheduled time, decides what is worth surfacing, and writes one digest. You read the digest. You do not have to ask. The pattern is closer to an autonomous agent than a copilot.

Three takeaways before you close this tab

  1. The unit of usefulness is the digest, not the underlying summarisation model. Constrain the digest, the model takes care of itself.
  2. Whitelist the channels. Always. A blacklist becomes unmaintainable inside a quarter and the digest fills with noise.
  3. The agent never posts in channels. The moment it does, teammates start writing for the agent instead of each other and the signal collapses.

Sources