Alright folks, gather ‘round the virtual campfire. I want to talk about a different kind of "incident response"—the post-meeting scramble. You know the drill: you’ve just come out of a critical, hour-long architecture review with a mix of in-office engineers and remote folks across three time zones. The action items are scattered across the chat, the whiteboard photo is blurry, and three different people have three different interpretations of the deployment timeline. The "mean time to understanding" (MTTU) is through the roof.
We’ve been trialing meeting summarizers for the last quarter to combat this, specifically for our hybrid SRE and platform engineering teams. Our north star metrics were simple:
* **Accuracy of technical commitments:** Did it correctly capture the specific service, owner, and deadline?
* **Reduction in clarification threads:** Measured by Slack threads starting with "Wait, did we say..."
* **Time to published summary:** From meeting end to summary in the wiki.
We tried a handful of the big names. Here’s the war story.
The front-runner was initially impressive, but it kept hallucinating under specific, high-stress conditions we know all too well—like during a postmortem discussion. It would confidently summarize a root cause that was merely a *hypothesis* someone floated, not the consensus. We caught this because we have a rule: all postmortem summaries must match the timeline in our incident dashboard. The mismatch created a secondary incident of its own. Not good.
The tool that ultimately stuck wasn't the shiniest, but it was the most robust. Its strength was in its structure and its API. It gave us a deterministic output we could pipe into our runbooks and on-call alerts. For example, if a meeting summary contained a new deployment freeze window, we could automatically update our `DeploymentFreeze` config map.
Here’s a sanitized snippet of how we integrated it with our alerting pipeline. When a production readiness review ends, the summary generates a JSON blob we consume:
```json
{
"meeting_topic": "Q4 Infrastructure Migration Go/No-Go",
"key_decisions": [
{
"decision": "APPROVED for migration",
"target_service": "payment-processor",
"window": "2023-11-15T01:00:00Z to 2023-11-15T04:00:00Z",
"owner": "team:platform-eng"
}
],
"action_items": [
{
"task": "Disable legacy service monitoring rules for payment-processor",
"assignee": "alice@company.com",
"due_date": "2023-11-14"
}
]
}
```
We then have a simple Python service that parses this, creates Jira tickets for the action items via API, and—crucially—updates our Grafana annotation dashboard to mark the approved change window. This traceability from conversation to commit to dashboard is everything.
The key takeaways for a mid-market company like ours:
* **Precision over prose:** You don't need eloquent paragraphs. You need bullet-pointed decisions, clear owners, and dates. The best tool for us enforced this format.
* **API-first is non-negotiable:** If you can't plug the summary into your existing ops toolchain (Slack, Jira, your monitoring stack), it becomes just another siloed document.
* **Calibration is required:** We spent two weeks "calibrating" the tool by reviewing summaries against our own manual notes, teaching it our acronyms and service names. Treat it like tuning a Prometheus query.
Our metrics improved significantly:
* **Clarification threads:** Down ~60% for meetings with summaries.
* **Time to published summary:** Went from ~45 minutes (someone volunteering, drafting) to 95% on technical commitment capture.
It’s less about having an AI "attend" the meeting and more about creating a reliable, automated scribe that feeds your operational reality. The reduction in cognitive load and context-switching for the team has been the real win.
What’s everyone else using? Any horror stories or brilliant integrations I should steal?
-- sre_tales
-- sre_tales