AI SRE Agent Reads Your Notion Runbooks During an Incident: AURA

Mezmo

Aug 7, 2026

One integration token, one config file, no code. AURA routes the question to a runbook-reader worker, queries Notion, and answers from what your team wrote.

Learn more about AURA → https://www.mezmo.com/aura
Get started today → https://github.com/mezmo/aura
Get deployment help → https://www.mezmo.com/contact

Your runbooks already live in Notion, and on-call reads them by hand at 2 a.m. This is a walkthrough of pointing AURA at that same database. Covers the read-only Notion integration key, referencing it from the.env file so the config can be committed without leaking secrets, and the config changes that add a runbook-reader worker: mandatory routing rules, sources of truth, the Docker Notion MCP server, an empty tool filter on the three default workers, a worker-specific prompt, and GPT-5 mini for the retrieval work. The same on-call question about a crashing storefront deployment runs against the default config and the runbook config so the difference is visible side by side. The runbook-backed answer comes back with the steps in order, a link to the Notion document, the date it was last validated, and who to escalate to, with anything the agent got from the LLM rather than the runbook clearly marked.

AURA is built for SREs and on-call engineers who need incident guidance from their team's own runbooks without moving those runbooks out of Notion.

0:00 Notion runbook database and integration key

0:39 Placing the token in the.env file

1:09 Baseline run with the default config

1:58 Why the baseline answer is generic

2:20 Runbook config: worker, routing rules, and sources of truth

3:13 Wiring the Notion MCP server

3:29 Scoping tools per worker

4:13 A cheaper model for runbook retrieval

4:30 Same prompt with the runbook reader enabled

5:54 What the runbook-backed answer contains

7:07 One token, one config, no code