When a user changes an agent's priorities, make the transition visible: what becomes urgent, what s, what continues and which pending action still needs an outcome check. The agent should preserve useful work without quietly continuing a task the user has displaced.
This guide addresses scheduling and scope while a long task is running. It is distinct from correcting an incorrect fact. The transition method is proposed, with documentation reviewed September 12, 2026; no scheduler implementation or agent behavior study was executed.
- 01Priority does not always mean replacement.Determine whether the new request reorders, s or ends earlier work.
- 02Cancellation is a request with an outcome.A running operation may finish before the cancellation reaches it.
- 03Keep one current work order.Late messages and results need to be checked against the latest accepted priority.
01 — Practical decisionInterpret the new request against the original objective #
Compare three messages: do the mobile issue first; this until tomorrow; stop this and prepare the customer summary instead. The first changes order, the second changes timing and the third replaces the current work. Treating all three as a fresh task loses useful context and can leave old work running.
Use the user's words and the active task state to infer the intended transition. If an ambiguity changes whether a consequential action should proceed, ask one focused question. Continue independent safe work where possible, but do not treat silence as authorization to choose an irreversible interpretation. Record the accepted objective and priority together. A task can retain the same objective while its next step changes. The user-correction guide handles a different question: which results became invalid because the facts or requirements changed.
02 — Practical decisionChoose a queue behavior deliberately #
The LangGraph SDK run reference exposes named multitask strategies including reject, interrupt, rollback and enqueue. Those are examples of runtime choices, not universal definitions for every agent product. Do not assume their names describe what happens to external systems.
For product design, use a plain-language work-order table. State the intended user experience and then check that the selected runtime can support it. A feature called interrupt may stop generation while a separately launched job continues.
| Digital Applied proposed decision aid; reviewed September 12, 2026. No measured outcomes. | ||
|---|---|---|
| User intent | Proposed work-order behavior | What the interface should show |
| --- | --- | --- |
| Add a follow-up | Queue after the current bounded step | The new task is accepted and waiting. |
| Make another task urgent | or stop at a safe boundary | The switching point and any still-running action. |
| Replace the objective | Supersede remaining old work | What was completed and what will no longer run. |
| Temporarily defer work | Preserve a resumable record | The resume condition and its owner. |
| Request conflicts with active work | Resolve the conflict before writing | The shared file, record or resource in contention. |
| Request cannot be accepted yet | Reject or request a specific clarification | The reason and the information needed. |
03 — Practical decisionDistinguish cancellation requested from cancellation confirmed #
The MCP cancellation specification describes optional cancellation notifications for in-progress requests. A receiver may ignore one when processing already finished or the request cannot be cancelled. Task-augmented requests use a separate tasks/cancel mechanism. The distinction matters when interpreting a late result.
A user-facing transition should therefore separate requested, confirmed and unknown states. If a report generation can stop before upload, that may be the safe boundary. If an upload already completed, preserve its result and decide whether the new task still needs it. Do not announce that nothing happened merely because the cancellation was sent.
Keep the operation identifier alongside the task revision. That lets the application connect a late acknowledgment to the correct attempt without allowing it to overwrite the new work order. For the related timing boundaries, see the agent time-limits reference.
04 — Practical decisionPreserve useful work without letting it block the new task #
Suppose an agent is improving a desktop page when the user makes a broken mobile navigation issue the priority. The desktop changes may remain valid. Save their state and identify shared files before starting the mobile fix. Two tasks editing the same component at once can create a conflict even when both goals are legitimate.
The transition record should say which files or artifacts are preserved, which process is still running and what resource the urgent work needs. If an existing job holds a shared environment, determine whether it can finish its current safe step or needs to release the resource first. Urgency does not make resource contention disappear.
Our handoff ownership guide covers responsibility transfer between workers. Here the owner may stay the same; the important change is the work order. Preserve the old task's resume instructions so the agent can return without asking the user to reconstruct the entire history.
Illustrative working record
Illustrative acknowledgment: mobile navigation is now first. The desktop layout patch is saved for later review. The current build is still finishing; after it releases the workspace, the next edit will address the mobile menu. No release is queued.
This record separates the accepted priority from the operation that has not yet reached its stopping point. It is an example, not a captured agent run.
05 — Practical decisionProtect the new work order from late results #
A background result can arrive after the agent has switched tasks. Attach enough identity to determine which task and revision requested it. The application can retain the result as evidence while deciding whether it remains relevant to the active objective. Stale does not necessarily mean useless, but it does mean the result needs classification.
Use a single authoritative current priority record. If two user changes arrive close together, preserve their order and scope. A late acknowledgment of the first change should not overwrite the second. Where different people can steer the same task, the product needs a rule for whose change controls the shared work. Do not confuse priority with permission. A request to hurry a draft does not authorize sending it, and a request to fix an issue first does not authorize a production release. The delivery-state reference supplies the vocabulary needed to keep those outcomes explicit.
06 — Practical decisionVerify the transition with controlled race cases #
A proposed evaluation should cover a new request while the agent is planning, editing, waiting on a tool and reconciling an external operation. Include a result that arrives just before the cancellation and another just after it. Use a stubbed or otherwise controlled action for the race cases.
Inspect whether the new priority is acknowledged, the old task reaches the intended boundary and the latest work order remains current. Check that preserved artifacts can be found when work resumes. Keep any unknown operation outcome visible until read-back resolves it; a smooth progress message is not sufficient evidence.
The acceptance result should describe behavior, not just response speed. A quick switch that leaves duplicate jobs or conflicting edits is not a successful transition. AI transformation teams can use this method to specify the required scheduling behavior before selecting a runtime or interface.
Evidence and scope
- Dates
- Editorial allocation: September 11, 2026. Sources retrieved and article reviewed September 12, 2026. Event dates are stated separately.
- Sources
- MCP cancellation specification and LangGraph SDK run reference, retrieved September 12. The SDK reference was retrieved directly as Markdown after the browser fetch rejected its content type.
- Method
- Original six-row work-order table, illustrative acknowledgment and proposed race-case checks. SDK strategy names are examples; no default behavior is assumed.
- Limits
- No scheduler, cancellation endpoint or external action was tested. Cancelling a run does not establish rollback of external side effects. Priority changes do not extend authorization.
07 — Next stepMake the switch observable and resumable #
Make the switch observable and resumable
Record the latest priority, settle the stopping point of active work and preserve what remains useful. The user should be able to see what the agent is doing now, what is waiting and which operation still has an unresolved outcome.