The dangerous moment is after execution
A network failure before a command starts is easy to retry. A failure after a file was written or a command completed, but before the result reached the control plane, is different: the caller cannot know whether the effect happened.
Treating every timeout as failure invites duplicate writes, duplicate deployments and repeated external actions. Treating every timeout as success hides real failures. The ambiguity must be represented directly.
Bind retries to the same identity
ADC requires a stable idempotency key for writes, process execution, templates, tests and custom MCP tools. The device combines the actor and key with the normalized input, so an exact retry can reuse a receipt while a different request using the same key is rejected as a conflict.
- Generate the key at the workflow boundary, not inside a retry loop.
- Reuse it only for the exact same intended effect.
- Keep invocation and attempt IDs in logs and audit correlation.
The device keeps the decisive evidence
Before a side effect runs, the Connector reserves the identity in a fsynced local ledger. After execution it persists the terminal receipt before reporting it. A reconnect can therefore reconcile completed local work even when the completion request was lost.
Unknown outcome is a safety result
If the device can prove neither a terminal receipt nor that execution never began, ADC returns unknown_outcome. Automation must stop and reconcile the target resource. It must not create a new idempotency key and try again.
This is less convenient than claiming exactly-once execution, but it is honest. Exactly-once side effects across a process, filesystem and network are not generally available without cooperation from the affected resource.