Actions with receipts

1. Propose. A synth proposes the action inside its response — grounded in the context it just argued from (the Gmail thread it read, the Linear ticket it cited).
2. Skeptic review. Before the proposal ever reaches you, the Skeptic reviews it for risk. Destructive actions always go through this review.
3. Your approval. You see a clean preview of exactly what will run — recipient, content, target record — and nothing executes until you approve it.
4. Execute, with undo. The action runs, and you get a 30-second undo window to reverse it on the spot.

Each action that runs is logged with its full provenance: which synth proposed it, what the Skeptic flagged, when you approved it, what actually executed, and whether it was undone. The session record keeps these receipts alongside the memo — so the decision and its follow-through live in one place.

• Disable per session — run any session with tool execution off entirely.
• Restrict by tool — allow only specific tool slugs (for example: Gmail drafts only, Linear reads only). Over the API and MCP the same control ships as integrations_enabled and allowed_tool_slugs on the session config.
• Reads vs. writes — reading context (a thread, a ticket, a deal) and proposing an action are separate steps; connecting an integration never grants silent write access.

• Integrations — the 62 providers your board can read from and act on.
• Security posture — how tool-execution governance fits the wider trust model.
• Your World Model — the memory layer that makes proposed actions contextual instead of generic.