Persist operation state, separate proposing and executing, bound retries, and reconcile uncertain outcomes. A model conversation alone is not a durable business transaction log.
1. Represent the business operation explicitly
Give a proposed action an operation identifier and a lifecycle independent of the chat transcript. Record its inputs, authenticated actor, target, review state, execution result, and any external record identifier. An interface should distinguish a draft, a pending action, a completed action, and an unresolved outcome.
Persist enough state to investigate or resume the process after an interruption. Do not infer success from the model’s final message. The system that performs the action supplies the result, and a durable operation record ties it to what the user actually requested.
2. Separate transient failures from business decisions
A temporary connection failure may justify a bounded retry. Invalid arguments, denied access, an expired approval, or a rejected business rule usually require a different response. Classify these outcomes so the runner does not ask the model to repeat every failed request.
Set limits for attempts, elapsed time, and tool turns. Use appropriate backoff for temporary failures and show the user when work remains pending. A timeout after submission is especially important: the target might have completed the operation even though the application did not receive its response.
3. Reconcile before repeating side effects
Use a stable idempotency or operation key where the target system supports it. Make repeated execution of the same approved intent refer to the same business operation. Keep a durable uniqueness boundary in your own integration where appropriate, and check the target state after an uncertain result.
A request ID attached to each network attempt is not automatically the same as a business idempotency key. If every retry generates a fresh intent, the target may treat each one as new. Document how a repeated user click, resumed run, or retried job is recognized.
{
"operation_id": "example-followup-42",
"action": "send_approved_followup",
"target_record": "example-opportunity-7",
"approval_status": "approved",
"execution_status": "outcome_unknown",
"next_step": "Check the target delivery record before retrying"
}4. Bind review to the action being performed
Show the proposed recipient, amount, content, or record change when asking for review. Preserve the approved version and the identity of the reviewer. If the proposal changes materially, the earlier decision may no longer describe what will execute.
Recheck permissions and business constraints at execution time. A user’s access or a target record’s state may have changed while an operation waited. Design pause, resume, rejection, and expiry explicitly. An SDK can help carry run state, but the application still owns the authorization and business meaning of the action.
5. Provide a recovery queue and useful evidence
Give operators a view of failed and uncertain operations with the reason, last known target state, and an allowed next step. Preserve enough context to resolve the issue without replaying an entire conversation or exposing unnecessary private information in logs.
Test process restarts, repeated callbacks, unavailable tools, expired reviews, and timeouts after the target has acted. Track completion, duplicate prevention, recovery time, and user communication alongside model quality. A bounded agent with understandable recovery is more useful than an ambitious loop that leaves people guessing about what happened.
6. Frequently asked questions
Can we retry every failed tool call?
No. Some failures are permanent or indicate denied access. A timed-out write might already have completed. Classify the outcome, reconcile where needed, and retry only through a defined bounded policy.
Does saving the conversation make the workflow durable?
It preserves conversation history, but a business operation also needs explicit state, target results, review decisions, and recovery rules. Keep those responsibilities distinct.
What should happen when an operation has an unknown outcome?
Show it as unresolved, inspect the target system using the operation identifier or other agreed evidence, and reconcile before repeating an action that could create another side effect.
7. Related articles and next steps
Bring representative inputs, expected outputs, and the systems involved. Discuss your requirements with OdooMatrix.