The launch needs a durable pair of artifacts: documentation in a private GitHub repository and a brief in Notion, with the Notion URL recorded in the repository’s README. This example is the write-side workflow that creates both and cross-links them - without trusting a success message.

​
The sequence

  1. Query both connections first. Confirm the intended repository and page do not already exist. Re-creating something that exists is the classic connected-write mistake.
  2. Checkpoint one: the repository. The agent presents the owner, the visibility, the name, and the files it will create. You approve. The repository and its initial files are created.
  3. Checkpoint two: the Notion page. A separate checkpoint presents the workspace, the page title, and the planned sections. You approve. The page is created.
  4. Checkpoint three: the cross-link. The agent updates only the new README with the page’s live URL. You approve.
  5. Verify at the provider. The agent rereads both GitHub and Notion and compares the actual state against the promised end state.
Each checkpoint is a tool-approval card: Allow once while you are learning the flow, always-allow for tools you trust. Connection authorization decides what the provider permits; the approval decides what runs now.

​
”Tool returned success” is not the finish line

The run is done when you have verified it, not when the last tool call returned. The verification pass:
  • Open every created record at its provider.
  • Check its visibility: private means private.
  • Follow every cross-link.
  • Compare what each record says with the agent’s summary.
Summaries drift from reality in both directions: a step marked complete that is not, or a claim about the product that nothing supports. The provider-side check catches both. Where a record is wrong, correct it before anyone consumes the artifacts.

​
Correct tightly, then verify again

When a record needs a fix, run a follow-up that touches only that record and does only that fix. Re-run the same provider-side check afterward. A correction that rewrites three artifacts to fix one field is how a verified state becomes an unverified one.
Scope every correction: one follow-up, one target, one change. If the fix is bigger than that, it is a new run with its own checkpoint, not a correction.

​
What good looks like

  • Both providers were queried before anything was created.
  • Each write had its own checkpoint naming owner, visibility, and contents.
  • Every created record was opened at the provider, and every cross-link was followed.
  • The corrected state, not the first summary, is what got handed off.