Changing an AI Agent’s Priorities During a Long Task

When a user changes an agent's priorities, make the transition visible: what becomes urgent, what pauses, 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.

Compare three messages: do the mobile issue first; pause 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.

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.

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.

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.

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.

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.