An agent is asked to reschedule an appointment. It checks another time, cancels the original booking, requests a replacement, updates a customer record, and sends a message. If one call times out, the conversation may end without establishing which of those actions completed.
The model’s reply cannot resolve that uncertainty. The workflow needs evidence from the systems that performed the actions.
Thinking about agent turns as transactions is useful when it encourages explicit boundaries and recovery. It becomes misleading if it implies that a turn provides atomicity across unrelated tools. A conversation turn can contain several committed operations, and the underlying business operation can continue after the turn ends.
The reliable unit of work is therefore the authorised business operation and its durable execution state.
Separate Planning From Authority
The agent can propose an action using the information available to it. The application must still establish whether that action is permitted and valid at execution time.
For rescheduling, relevant facts include the appointment owner, cancellation terms, replacement availability, and any required approval. Availability observed during planning may have changed by the time the tool runs.
A tool interface should expose a bounded business capability rather than unrestricted changes to arbitrary records. Where a booking service supports an atomic reschedule, using it is preferable to reconstructing the operation from independent cancel and create calls.
Where no such capability exists, the workflow needs explicit intermediate states and recovery decisions. The model should not be expected to invent those rules during an incident.
Give the Operation an Identity Beyond the Turn
A durable operation identifier connects the user’s intention to its execution attempts. It should remain stable across retries of the same logical operation, while a materially changed request needs its own identity or explicit revision.
Record enough information to establish the authorised request, relevant approval, current state, attempted actions, and known results. Avoid relying only on conversation text, which may be summarised or unavailable to the component performing recovery.
An illustrative workflow might use states such as:
These states describe execution, not the model’s confidence. An optimistic response does not move an operation to completed when the booking service has not confirmed the result.
Design Retries Around Effects
Suppose the replacement-booking request times out. The service may have created the appointment before the response was lost. Sending a fresh create request can produce a second appointment.
An idempotency mechanism lets repeated attempts refer to the same intended operation. AWS’s guidance on idempotent APIs explains why caller-provided identifiers and clear retry semantics are valuable.
The details matter. Determine how long the service remembers the key, what happens when the same key arrives with different parameters, and how a caller retrieves the original result.
The caller’s journal alone cannot guarantee exactly-once effects at a remote service. There can be a crash after the remote action completes but before the local success record is written. Remote deduplication or outcome lookup is needed to resolve that gap safely.
If the tool provides neither, classify the result as uncertain and use a reconciliation or review path. Blind retries are a poor substitute for missing evidence.
Rollback and Compensation Are Different
A local database transaction can roll back uncommitted changes within its boundary. It cannot unsend an email or automatically restore a booking that another customer has since taken.
Compensating transactions address earlier effects through new business actions. They depend on domain rules, may fail themselves, and need recorded progress.
For rescheduling, holding the replacement before releasing the original may reduce one risk if the booking system supports that sequence. It also creates a temporary double-hold state that must be permitted and bounded.
If the original slot is gone, creating a different appointment without agreement may be an unacceptable compensation. The workflow may need to explain the situation and ask for a decision.
Recovery should aim for a known, acceptable state. It cannot always restore the exact world that existed before execution.
Make the Commit Boundary Reviewable
For consequential actions, approval should refer to a concrete operation: the appointment being changed, the proposed time, applicable costs, and any other material conditions.
If those conditions change, the workflow should determine whether the approval still applies. A stale approval should not silently authorise a different outcome.
The application should enforce permissions and preconditions when calling the downstream system. These controls belong outside model-generated prose, even when the model correctly described them during planning.
Keep the coordinated boundary as small as practical, following the same principles used in systems with critical consistency requirements. Confirmation messaging can often follow a committed operation through a separately recoverable step.
Cancellation Must Reach the Workflow
Stopping generation does not necessarily stop a tool call already in progress. Similarly, cancelling the user interface’s request may leave downstream execution running.
Define what cancellation means at each stage. Before execution it may simply abandon the proposal. During execution it may request a stop while reconciliation determines which effects already occurred. After commitment it may require a new reversal operation.
The user-facing response should reflect that distinction. “Cancellation requested” and “appointment unchanged” are different claims.
A background recovery worker may need to continue after the conversation ends. Its authority should remain bounded by the original operation and the system’s recovery policy.
Report Outcomes From Evidence
A useful completion message identifies what succeeded and any remaining work. If the appointment changed but notification failed, report the confirmed booking separately from the notification problem.
For operators, keep a trace from the operation to its tool attempts and downstream identifiers. This supports investigation without treating the model’s narrative as the authoritative record.
The transaction analogy is valuable when it leads to bounded commitments, durable state, and deliberate recovery. The resulting workflow remains dependable even when the model stops, a tool times out, or the conversation moves on.
Key Takeaways
- A conversation turn is not an atomic transaction across tools.
- Track the business operation durably beyond the model’s execution.
- Use downstream idempotency and reconciliation to handle uncertain outcomes.
- Treat compensation, cancellation, and user-visible completion as explicit workflow behaviour.
