Skip to content

Notion destructive ops, API egress, and multi-agent orchestration

Guide

Notion destructive ops, API egress, and multi-agent orchestration

  • Date: 2026-06-01 · By: Personal Assistant / Operations

What we learned

The Notion MCP cannot delete/trash/archive a page. Its surface is fetch / search / create-pages / update-page / move-pages / comments / users / teams. update-page only updates properties, content, or verification; move-pages only re-parents. So any destructive registry cleanup (de-duping rows, removing stale rows) cannot be executed through the MCP.

Direct api.notion.com is blocked from the execution container. A bare curl to https://api.notion.com returns 403 (egress not allow-listed by the network policy). The Notion MCP works only because that server calls Notion from its own infrastructure, not from this container — so “the MCP can read Notion” does not imply “this shell can reach the Notion API.”

Therefore: route destructive Notion ops through GitHub Actions. A manually-triggered (workflow_dispatch), dry-run-by-default workflow that PATCHes {"archived": true} using the NOTION_TOKEN secret runs on GitHub’s open-egress infra, is auditable, masks the token, and is reversible (Notion trash is 30-day recoverable). See .github/workflows/notion-roster-cleanup.yml.

Multi-agent orchestration: one file, one owner. Spawning a second/third background agent to “add to” a file another agent is already writing risks write collisions (hit while extending the External Review Partners advisory). There is no live message channel to a running subagent in this setup — Agent starts a fresh worker; it does not thread into the prior one. Consolidate follow-on requirements and hand them to the single owning agent, or feed the full consolidated brief to the integrating author (here, the COO).

Why it matters

Saves a dead-end loop: don’t promise an in-session Notion deletion the tools can’t perform, and don’t assume container egress mirrors MCP reach. Keeps the archive/record honest by avoiding half-finished destructive writes.

What to do next time

  • Need to delete/trash/archive Notion rows? Skip the MCP — ship (or reuse) a workflow_dispatch Actions job with the verified IDs; dry-run, then execute.
  • Before scripting any external API from the shell, probe reachability first (a status code, not a guess); if blocked, move the call to Actions.
  • Adding requirements to in-flight agent work? Route them to the one owner; don’t fan out onto a shared file.

Promotion (curator note, added 2026-06-01)

  • Promoted to: the one-file-one-owner / single-writer learning is now standing practice — captured durably in docs/knowledge/2026-06-01-km-two-index-discipline-and-write-race.md and codified as Operating rule 5 of the Documentation charter (docs/units/documentation/charter.md) and in SOP-024/SOP-025 (knowledge-index single-writer). The Notion-destructive-ops + egress learnings remain PA/Operations operational know-how (no SOP home yet — see residual below).
  • Residual (not promoted): the “route destructive external-API ops through a workflow_dispatch GitHub Action” pattern is a candidate for a PA/Operations SOP but is not yet promoted into one. Flagged for the PA/Operations Lead; left here as the inbox record until a home exists (promote-and-link, knowledge-management.md §6.1).
  • Supersedes / superseded by: none.