Thanks, you put it better than I did: “step 3 isn’t a stable coordinate” is exactly it.
Today we don’t classify at all: any recorded tool call blocks the automatic replay, reads included. Deliberately blunt, for exactly the cases you list. The cost is refusing some safe replays.
Agreed that the decision belongs in the tools, with one catch: a key hashed from the args breaks when the LLM rewrites them on replay. The key has to come from stable intent, never from generated content. That’s what we do in production where we’ve built it: Outlook webhooks are deduped on the provider’s message identity, dataset imports on a SHA-256 of the content, and outbound campaigns need human approval.
What’s missing is that rule generalized to every tool, and you’ve clearly already shipped that design. I’m opening an RFC issue on tool-level idempotency keys, and I’d love your help shaping it: a comment, a counter-proposal or a PR, whatever suits you.
The project is young, so early contributors really set the direction. Every contribution is credited by name, I’m happy to pair on a first PR, and I share contributors’ work with our network. Your comment already inspired my next post, and I’d love to credit you there too.
Thanks, you put it better than I did: “step 3 isn’t a stable coordinate” is exactly it.
Today we don’t classify at all: any recorded tool call blocks the automatic replay, reads included. Deliberately blunt, for exactly the cases you list. The cost is refusing some safe replays.
Agreed that the decision belongs in the tools, with one catch: a key hashed from the args breaks when the LLM rewrites them on replay. The key has to come from stable intent, never from generated content. That’s what we do in production where we’ve built it: Outlook webhooks are deduped on the provider’s message identity, dataset imports on a SHA-256 of the content, and outbound campaigns need human approval.
What’s missing is that rule generalized to every tool, and you’ve clearly already shipped that design. I’m opening an RFC issue on tool-level idempotency keys, and I’d love your help shaping it: a comment, a counter-proposal or a PR, whatever suits you.
The project is young, so early contributors really set the direction. Every contribution is credited by name, I’m happy to pair on a first PR, and I share contributors’ work with our network. Your comment already inspired my next post, and I’d love to credit you there too.
Repo: github.com/apowerb/apowerb
Thanks for the exchange!