Deleting the poisoned page doesn't undo what your agents did with it

Description and use

Deleting the poisoned page does not undo what your agents did with it. kintsugi uses a provenance graph in FalkorDB to selectively re‑execute only the affected steps, correcting refunds and emails while preserving unaffected work.

Problem

A poisoned policy page caused support agents to issue incorrect refunds and emails, and deleting the page did not reverse the already executed actions.

Outcome

Selective re‑execution via kintsugi fixed the incorrect refunds and emails without discarding all prior work, preserving the integrity of unaffected tickets.

Workflow

• 1. Detect poisoned source (policy page).
• 2. Build provenance graph in FalkorDB from the bad source to all dependent actions.
• 3. Identify actions that depend on the poisoned fact via FEEDS and HANDED_OFF edges.
• 4. Re‑run only those actions against clean memory, stopping early when re‑execution yields the same output.
• 5. Apply corrections to refunds and notifications.
• 6. Verify that unaffected actions remain unchanged.

Evidence

Deleting the page fixes none of that.

Source

kintsugi: it walks a provenance graph in FalkorDB from the bad source to everything that depended on it, across agent handoffs, re‑runs only those steps against clean memory, and stops early wherever the answer comes out the same.

Source

agents touch memory only through the recorder

Source