Skip to main content
Before any tool call reaches the outside world, Invoke commits a durable execution record. This record is the primitive that makes observability, replay, debugging, and audit possible.

​
What is an execution record?

An execution record is a persisted object created before a side effect lands. It captures:
  • Execution ID — a unique identifier for the action
  • Tool name and parameters — exactly what the agent asked to do
  • Agent ID — which agent made the call
  • Idempotency key — the deduplication handle for this action
  • Safety class — how Invoke classified the tool
  • Timestamp and workflow context — when it happened and in what run
The record exists before the API call goes out. If the network drops, the agent crashes, or a retry fires, Invoke has the full context to reconcile the outcome.

​
Why records come first

Writing the record before the side effect is the key design choice. It means:
  • No silent duplicates — if a second attempt arrives, Invoke checks the existing record and blocks it if the first already succeeded
  • No lost context — even if the agent restarts, the execution history is intact
  • No untracked actions — every risky tool call is accounted for before it happens

​
What you can do with execution records

Every execution record feeds into:

​
Record lifecycle

An execution record moves through these states:
  1. created — record committed before the tool call
  2. attempted — tool call dispatched
  3. succeeded / failed / unknown — outcome from the API
  4. reconciled — unknown outcome resolved via live state check
  5. blocked — duplicate attempt stopped by idempotency enforcement
Every state transition is timestamped and appended to the execution trace.

​
Next steps

  • Reconciliation — how Invoke resolves unknown outcomes using execution records
  • Traces — the full timeline attached to every execution record
  • Tool Safety Classes — how safety class affects record handling