Building SmartMeet AI: A Meeting Intelligence Agent Inside Microsoft Teams
By Anas Shaikh · June 4, 2026 · 4 min read
Meetings generate enormous value and almost no record. The decisions, the action items, the context — most of it evaporates the moment the call ends. SmartMeet AI was built to fix that: an AI agent living inside Microsoft Teams that quietly turns every meeting into a searchable, summarised, actionable record.
This is a look at the architecture and, more usefully, the production problems we solved — because the gap between "it works on my machine" and "it works for a whole organisation" is exactly where this kind of AI integration earns its fee.
What SmartMeet AI does
- Detects when a meeting is recorded.
- Pulls the recording, transcribes it with Whisper.
- Generates a structured summary — decisions, action items, key topics.
- Posts the summary back to the right Teams chat.
- Archives everything to SQL Server so it's searchable later.
Simple to describe. The interesting part is everything that can go wrong when you run it against a real Microsoft 365 tenant with the Graph API.
Two paths, one pipeline
Recordings arrive through two very different Graph surfaces, and treating them the same is a trap:
- Scheduled meetings surface through
getAllRecordingsand can be delivered back into the Teams thread. - Direct and group calls surface through
callRecords— these get archived to the database only, with no thread to post into.
Routing each event down the correct path is the backbone of the whole system. Conflating them produced some of our nastiest bugs.
The production bugs that actually mattered
A demo bot never hits these. A bot serving a real company hits all of them in the first week.
Duplicate database inserts. Cross-path deduplication was failing, so the same meeting landed twice. The fix was a deterministic dedup key checked before every insert — not after.
Searching the wrong OneDrive. The instinct is to look in the organiser's OneDrive for the recording. Wrong. We learned to always search the bot-mapped user, regardless of who scheduled the meeting.
403s when posting summaries. Posting into the meeting's group thread returned 403s. The reliable channel turned out to be the user's personal @unq.gbl.spaces chat.
Stale subscriptions on restart. Graph change-notification subscriptions would re-deliver old events every time the service restarted, reprocessing meetings that were already done. We added subscription lifecycle handling so a restart doesn't replay history.
Event-loop starvation. Blocking requests calls inside an async pipeline silently throttled throughput. Moving to non-blocking I/O unblocked concurrency.
Datetime conversion errors. Graph returns ISO 8601 timestamps with a Z suffix; SQL Server wanted a different format. A small normalisation step before insert killed a recurring crash.
from datetime import datetime, timezone
def to_sql_datetime(graph_ts: str) -> str:
# Graph: "2026-06-04T10:15:00Z" -> SQL Server friendly
dt = datetime.fromisoformat(graph_ts.replace("Z", "+00:00"))
return dt.astimezone(timezone.utc).strftime("%Y-%m-%d %H:%M:%S")
None of these are glamorous. All of them are the difference between a bot people trust and one they quietly stop using.
The results
| Metric | Result |
|---|---|
| Meeting-admin time saved | 80% |
| Summary accuracy | 95% |
| Meetings processed | 2,500+ |
The lesson for any Microsoft 365 AI project
The model is the easy 20%. The hard, valuable 80% is the integration: handling the Graph API's edge cases, surviving restarts, deduplicating reliably, and delivering output to a place users actually see. That's the work that makes an AI agent dependable enough to become part of how a team operates.
If your meetings, emails or documents are generating value that disappears the moment they're over, that's a workflow worth automating.