An agent can correctly recommend moving a support case to another queue while still lacking permission to apply the change. It can also receive permission and then encounter a failure during execution. A product that displays both situations as “done” loses an essential distinction.
I separate the proposal from the side effect. Planning describes an intended operation. Execution attempts that operation under current application rules. Confirmation records the result that the destination actually accepted.
Represent the proposed change explicitly
For a case reassignment, a proposal might identify the case, its current version, the destination queue and the reason for the move. The application can inspect that structure before any mutation occurs.
The proposal should contain the actual target set. “Move similar cases too” is not a stable batch definition. If a later lookup adds records, the proposal has changed and may need another review.
Customer-support work on Conviro provides a concrete setting for this design. A useful assistant can prepare an operational decision while the backend remains responsible for access and state changes. The pattern is about a controlled interface, not a claim that every imagined action is already implemented.
Run a preflight against current state
A preflight can check whether the targets still exist, whether their versions match and whether the requested operation is currently permitted. It can also identify records that would need a different treatment.
A successful preflight is still a preview. State can change before execution, so the write path must enforce the same relevant conditions. The interface should describe what the preview checked without suggesting that it reserved the entire system indefinitely.
This is why approval has to remain attached to the reviewed proposal. A person’s decision and a technical preflight answer different questions.
Give execution its own identity
I would assign an operation identifier that connects the approved proposal, the execution attempt and the observed result. Repeated attempts can then be recognized as attempts to complete the same operation, rather than unrelated requests.
The destination’s behavior still matters. If it supports duplicate protection, the caller should use it consistently. If the result is uncertain, the system needs a lookup or reconciliation strategy before deciding whether another attempt is safe.
A timeout should not be translated automatically into either success or failure. It says that the caller did not obtain a timely confirmation. The remote operation may require further investigation.
Expect partial completion in batches
A batch can succeed for some records and fail for others. Reporting one generic status hides useful information. I would retain per-item outcomes and enough context to retry only the unfinished work when appropriate.
Recovery may require another operation rather than a simple rollback. Moving a case back might restore its queue while leaving an already-sent notification in someone’s inbox. A compensation plan should describe the effects it can reverse and the effects it cannot erase.
The durable state of the job should retain these distinctions so a restarted worker does not treat partial completion as a clean beginning.
Report the confirmed outcome
The final message should say what was accepted, what remains pending and what needs attention. A generated recommendation can be useful even when execution is blocked, as long as the product makes the boundary clear.
I would review the workflow with a stale target, a denied operation, an uncertain response and a partially completed batch. Each case asks whether the application can still explain the difference between intention and effect.
That separation lets an agent contribute judgment without becoming the sole authority on what happened. The application keeps an inspectable record from proposal through confirmation.
Updated 30 September 2026.