FlowDrop Workflow Specification 1.0-draft

A tool call executes at most once per run

A tool call has side effects. One node can be reached twice in a run (by a fan-in, or by a re-ask after a human approved a gated call), and the same batch of calls arrives with it.

The rule

Normative: this is the rule
  1. A run records each tool call it has executed, keyed by the call identifier, and does not invoke a call whose identifier it has already recorded.
  2. The repeat is reported on a skipped output, and the stored result of its first execution (the tool-role message and whether it succeeded) is re-emitted among the run's tool messages and results and counted in the batch's outcome.
  3. Re-emitting rather than dropping is required: a batch that paused midway never delivered the already-executed call's message downstream, so dropping the repeat would leave a declared call identifier unanswered and invite the model to retry it under a fresh, unguardable one.
  4. A call is recorded only once it has returned a result, success or a recoverable error, and never before it is invoked, so a call that interrupts the node for human approval is re-asked and executed once approved, rather than looking already-executed and being silently dropped.
  5. A call that carries no identifier cannot be guarded and always runs.
Rule identifiers are permanent and are never renumbered. Each implementation publishes its own standing against these rules; this specification does not.spec 1.0-draft · RT-TOOL-9 · changed in spec 1.0