Why this agent
Watch anyone’s calendar for a day and you’ll see the same ritual before every meeting that matters: ten minutes of inbox archaeology, five minutes hunting for the document someone “shared last week,” a quick LinkedIn-style stalk of the attendee you’ve never met, and a vague attempt to remember what you promised last time. Multiply by four meetings a day and you’ve lost two hours to preparing to think.
This is the rare agent that needs no shared knowledge source, no content audit, and no committee. It’s grounded entirely on data the asking user already owns — their calendar, their mail, their files. That makes it the perfect second agent: where Policy Pilot proves agents can serve the org, Briefing Officer proves they can serve you, in twenty minutes, with nothing to govern but your own mailbox.
The design constraint that matters: the brief must be scannable in 90 seconds. An agent that returns a wall of summarized email is just a different kind of homework. The instructions enforce a fixed four-section format — attendees and context, open items, related documents, suggested questions — and forbid padding.
Before you build: a 5-minute reality check
There’s no SharePoint audit here, but there is one honest question: is your meeting data in Microsoft 365? The agent can only brief from what Graph can see.
- If half your commitments live in Slack or a personal notebook, the “open items” section will be thin. The agent flags gaps rather than inventing — but set your expectations.
- Recurring 1:1s with no agenda and no email trail produce sparse briefs. That’s a signal about the meeting, not the agent.
- External attendees yield less context by design — the agent can see your correspondence with them, not their org chart. The instructions tell it to say so plainly.
Build it (no code, ~20 minutes)
- Open Agent Builder in Microsoft 365 Copilot Chat — Create agent, then go straight to the Configure tab. Skip the conversational setup; the instructions below are the product.
- Name and describe it using the manifest’s description verbatim. The orchestrator routes based on description, and “pre-meeting brief” is the phrase users will actually type.
- Paste the instructions from the downloadable manifest. They encode the four-section BRIEF format, the 90-second length cap, and the rule against speculation about attendees.
- Enable the four capabilities: Meetings (the trigger surface — “brief me on my 2pm”), Email (recent threads with attendees), People (who they are, who they report to), and OneDrive & SharePoint (files referenced in or related to the thread). No web search — a brief that blends your inbox with the open internet is noise.
- Add the conversation starters and test against tomorrow’s real calendar before showing anyone.
This stays a personal agent published to yourself or a small team. It needs no admin approval theater because it touches nothing the user can’t already see — every retrieval is security-trimmed to the asking user. Your brief is built from your access; a colleague running the same agent on the same meeting gets a different brief.
Test it like a hostile user (15 minutes, not optional)
| Test | Pass looks like |
|---|---|
| ”Brief me on my next meeting” with a real, messy meeting | All four sections, under ~300 words, every claim traceable to a thread, file, or invite |
| A meeting with an external attendee you’ve never emailed | ”Limited context available” for that person — no invented background, no guessed job title |
| A meeting where you owe someone a deliverable | The commitment appears under Open items with the source thread cited |
| ”What does Sarah think of this project?” | Reports only what Sarah wrote, attributed and dated — refuses to characterize her opinion beyond that |
| A meeting with no email trail, no attachments, no agenda | A short honest brief that says context is thin — not 300 words of filler |
The fifth test is the one that fails most often. A model’s instinct when retrieval comes back empty is to be helpful anyway. The “never pad a thin brief” instruction is the load-bearing wall here.
Governance notes IT will ask about
- Permissions: every capability retrieves as the asking user. The agent cannot surface a thread, file, or meeting the user couldn’t open themselves — there is no privilege escalation surface to review.
- Licensing: this is the design where licensing bites hardest. An agent grounded on tenant data (mail, calendar, files) is metered for users without an M365 Copilot license — every brief burns Copilot Credits via pay-as-you-go or a capacity pack. For licensed users it’s included. A daily-habit agent like this one strongly favors licensed users; metering a four-times-a-day habit gets expensive fast.
- Sensitivity: briefs can aggregate things the user could see individually but never had in one place — that startles people. Brief your pilot users that the agent reads their mailbox, on their behalf, and nothing else.
Measure it or it didn’t happen
Ask pilot users to time their prep for one week before launch (most guess 15–30 minutes per significant meeting). After launch, track: briefs generated per user per week (admin center analytics), and one pulse question — “did the brief surface something you would have missed?” That second number is the one that gets this agent budget. Saving time is nice; catching the forgotten commitment before the meeting is what people retell.