a-write-that-reported-success-and-changed-nothing

Work out why a change made through an integration reported success while the far system shows the old value — a lock, a cache, a stale binding, or the wrong identity.

Procedure

  1. start start. Goes next to s1
  2. action Read it back from the far side, RO (read-only). Goes on_fail to s9; next to s2
  3. decision Did the value change?. Goes if changed to s3; if default to s4
  4. action The write landed; look at what reads it, RO (read-only). Goes on_fail to s9; next to s8
  5. decision Was the write refused quietly?. Goes if locked_or_gated to s5; if default to s6
  6. action Apply it by hand, then fix the path, RW (reversible-write), requires approval. Goes on_fail to s9; next to s8
  7. decision Did the request reach the right place at all?. Goes if stale_binding to s7; if default to s9
  8. action Rebind it to something that survives, RW (reversible-write). Goes on_fail to s9; next to s8
  9. check The connection still has the access. Goes on_fail to s9; next to __end_success
  10. escalate Escalate with what was read back. Terminal
  11. end success. Terminal

Open the graph on its own page — larger, printable, and an address you can send.

Walk it without running it — you answer what your environment would answer, and the path, the capabilities, the approvals and the distance back to an undo come out of the document. Nothing executes; there is no Run button here and there will not be one.

Trust

T2 · attested 2026-10-11 · runbooks.directory

Nobody has attested this record. That is the ordinary case: T2 is what the catalog can check on its own, and T3 needs somebody to run the procedure and sign for it.

  • Link liveness has not been checked: it needs a network and the catalog builds without one. Run pnpm gates --online where there is one.

Steps

  1. s1 action — Read it back from the far side (read-only)
  2. s2 decision — Did the value change?
  3. s3 action — The write landed; look at what reads it (read-only)
  4. s4 decision — Was the write refused quietly?
  5. s5 action — Apply it by hand, then fix the path (reversible-write) — requires approval
  6. s6 decision — Did the request reach the right place at all?
  7. s7 action — Rebind it to something that survives (reversible-write)
  8. s8 check — The connection still has the access
  9. s9 escalate — Escalate with what was read back

Capabilities

This is a privilege request. Check it against your own allowlist before running.

    Provenance

    Source
    https://github.com/microsoft/ai-agent-runbooks/blob/083f33eec889/01-scenarios/F%26O-User-Onboarding-Agent/3.Runbook.md
    Fetched
    2026-09-04
    Source last checked
    not since it was captured on 2026-09-04 — recorded as current
    Licence
    MIT
    How it got here
    Rewritten here from the source above, under its licence. The words and the steps are this catalog's; the procedure it describes is not this catalog's invention, and the source is where to check it.
    Highest risk in this procedure
    reversible-write

    Take it with you

    Run it under supervision

    Runs here, on your machine, under supervision: every step is proposed before it happens, an approval gate stops for you, and a failed expectation goes where the procedure says rather than on to the next step. Nothing is sent anywhere. To supervise an agent that is doing the work instead, runbooks hook sits in its tool-call path.

    npx @runbooks/cli run adapted/a-write-that-reported-success-and-changed-nothing@1.0.0 --as "$(whoami)" \
  --input record_id=<the thing that was supposed to change> \
  --input far_system=<the system the change was made in>