Lesson 4 of 4 · 35 min

Resume approval without changing its meaning

Bind approval to a concrete action and detect stale approval.

Human review often happens between drafting and acting. During that pause, the draft, target resource, or external state can change. A safe resume path checks that the approved action is still the action about to run. Approval should be a record tied to the user, payload, destination, scope, and relevant version.

Separate approval from a general conversation message. A user saying "looks good" may approve a shown draft in a well-defined interface, but the application must know which draft was shown. Store its content hash or version. If a later worker changes the recipient list or adds an attachment, the old approval no longer covers the new payload. This is true even when the model thinks the change is helpful.

Revalidate authorization at execution time. A user may lose access while the task is paused. A target object may be deleted or reassigned. An approval permits the intended action; it does not bypass current service rules. Some changes are harmless under the contract, such as a display-only timestamp. Define those allowed changes explicitly rather than letting the agent decide after approval.

Represent cancellation as a state transition with a race boundary. A queued action can be cancelled before it starts. Once a remote service commits, cancellation may require a compensating operation and may not be possible. Tell the user which state applies. Do not claim that stopping a worker reverses an email that already left the provider.

Worked example

A fictional assistant prepares a message to two interview panelists. Draft D6 has body hash H6, recipients R1 and R2, and no attachment. The user approves D6. Before execution, another worker creates D7 with a candidate résumé attached.

The execution check compares the pending payload to the approval. D7 does not match, so it cannot send under D6's approval. The system can send the unchanged D6 if that is still intended and authorized, or request approval for D7. It must not silently treat the attachment as a minor correction. The resulting send operation also gets a stable ID so a lost response does not produce two messages.

Exercise and solution

A user approves booking room R4 for 14:00 at price 50. At resume, R4 is unavailable and R5 costs 80. The model proposes substituting R5 to finish the task. State the valid next step and the stored evidence.

The system records that the approved booking cannot execute under its original terms. It presents the alternative with the changed room and price if user input is available, or returns a blocked result. It retains the approval for R4, the failed precondition, and the proposed alternative as separate records. Award one point each for detecting the material change, preventing substitution, preserving evidence, and reporting the task honestly.

Inspect the approval record

A concrete approval can be represented without storing unnecessary private content in every log. This teaching record references an immutable draft and its destinations.

code

1approval_id: A442user_id: trusted-session-user3task_id: interview-message-84draft_id: D65content_hash: H66recipient_ids: [R1, R2]7attachment_hashes: []8action: send_message9approved_at: 2026-09-22T09:00:00Z10expires_at: policy-defined

The record is evidence of what was approved, not proof that execution is still allowed. At resume, the service checks current access, destination validity, payload identity, and any expiry rule. The application should not let the model edit the approval record to match a changed draft.

A content hash helps detect change, but only if the hashed representation includes everything material. Hashing the body while excluding attachments and recipients leaves a gap. Canonicalize the representation deliberately so harmless serialization differences do not create false mismatches, while changes in meaning do. This is a contract design problem, not merely a hash-function choice.

A second worked case: cancellation races

A user cancels at nearly the same time that a worker starts sending. The following table distinguishes outcomes the application can truthfully report.

Execution state	Cancellation result	User-facing meaning
Queued, no provider call	Cancelled atomically	The send did not start
Claimed locally, provider not called	Cancel if claim protocol permits	Confirm after the worker observes cancellation
Provider outcome unknown	Reconciliation pending	The send may have happened
Provider confirms sent	Cannot undo through worker cancellation	A separate recall/compensation may be unavailable

Stopping a process is not an undo operation. If the provider has already sent the message, the local cancellation cannot pull it out of recipients' inboxes. If the provider offers recall, that is a distinct service operation with its own limits. The system should not promise that recall succeeds merely because a request was accepted.

A useful race test places a barrier before the provider call. Cancel while the worker waits, then release the barrier. The expected result is no provider send if the state transition guarantees cancellation at that boundary. A second test lets the provider commit and drops the response before cancellation. The correct result is uncertain until reconciliation, not an immediate "nothing was sent".

Material change versus permitted variation

Some workflows allow a narrow approved range. A user may authorize a booking up to a stated price or a message with specified formatting corrections. Record the range as part of the approval rather than pretending every change needs a new decision. The application must still verify that the actual action falls within it.

For example, approval for any room in building B, at 14:00, with capacity at least 20 and price at most 60 can permit a substitution from R4 to R5 if all constraints hold and the user's wording grants that discretion. Approval for specifically R4 at price 50 does not. The difference comes from the approved scope, not the model's confidence that R5 is a good choice.

Misconceptions to reject

"Any earlier yes covers the final action" ignores which payload and constraints the user reviewed. A later recipient or attachment can materially change the action.

"Cancel means no external effect occurred" ignores the race with remote commit. Cancellation can stop future work without reversing completed work.

Transfer exercise

A user approves a room in building B for 20 people at 14:00, costing no more than 60. The selected room becomes unavailable. Another room in building B fits 25 people at 14:00 and costs 55. A third room costs 70. Explain the allowed decision.

If the approval explicitly permits any room within those constraints, the second room is within scope after current availability and authorization checks; the third is not. If the approval named only the original room, neither substitution is covered without a new decision. Score one point for each conditional interpretation and one for checking current state before committing the booking.

Interview probe

Original practice: How do you prevent a draft from changing after approval? A strong answer binds approval to immutable content and target versions, then rechecks at execution. Follow up with a cancellation after remote commit. A weak answer treats any earlier 'yes' as permanent authority.

Sources

docsLangGraph: persistencedocs.langchain.com docsMCP: security best practicesmodelcontextprotocol.io

Checkpoint

An attachment is added after message approval. What should execution check?

AWhether the complete payload and destinations remain within the approved scope.BWhether the model considers the attachment helpful.COnly that the attachment file exists.DOnly that the message body hash is unchanged.

Checkpoint

Approval covers any room in building B, capacity >= 20, price <= 60. Which available room is in scope?

ABuilding C, capacity 25, price 55.BBuilding B, capacity 18, price 50.CBuilding B, capacity 25, price 55.DBuilding B, capacity 25, price 70.

Checkpoint

The provider committed a send before local cancellation. What can local cancellation guarantee?

AThe provider rolls back automatically.BA recall request will certainly succeed.CThe recipient never received it.DOnly that future local work is stopped under the cancellation protocol, not that the committed send is undone.

Checkpoint

A user loses access while an approved task waits. What should execution do?

ARevalidate authorization and reject or pause if access no longer permits the action.BLet the model choose a broader credential.CSend first, then record the access change.DUse the old approval to bypass current access checks.

Checkpoint

The approved message body is unchanged, but recipients and attachments can change independently. What should approval identity cover?

AOnly the body, because it contains the message's wording.BThe body and timestamp, leaving destinations to the model.CThe complete material payload, including recipients and attachments, under a defined canonical representation.DOnly the task ID, because every later draft belongs to that task.

Explain how you would resume or cancel an approved action when payload or provider state has changed. Name the record that justifies each transition. Rate confidence from 1 to 5 and state the unresolved boundary.

Not yetGetting thereConfident

Wrap-up

Approval belongs to a specific action. Compare the resumed payload and current preconditions before executing it.

Sources

Free to read · better with Enzo

Learn it with Enzo

Save your progress, answer the checkpoints, and let Enzo quiz you on what you just read.

Continue with Enzo Sign up free