I tried using GPT-Dot to plan a website update, starting with visual cleanup as the main priority. Partway through, I told it that fixing keyboard navigation mattered more and that the visual work could wait. Its next plan still put some cosmetic changes ahead of the navigation fixes, so I’m not sure whether I changed direction clearly enough.
Does GPT-Dot usually handle changing priorities within the same conversation, or can earlier instructions keep carrying more weight? I don’t know whether this counts as a context issue. Do I need to explicitly say which earlier priorities no longer apply?
That doesn’t establish a context problem, and your description sounds clear enough to expect a reordered plan. I’d treat this as a failure to apply the revised priority, rather than proof it forgot your message. This example alone doesn’t tell us how reliably it handles changes in general, or whether earlier instructions actually received more weight.
I’d make the replacement explicit without throwing away the useful project details: “Replace the earlier visual-first priority. Keyboard navigation fixes now come first. Defer unrelated cosmetic work until those fixes are complete. Rewrite the existing plan in that order, and identify anything you’re moving to the backlog.” You shouldn’t need a special cancellation phrase, but that wording leaves less room for interpreting “matters more” as “give it more attention while continuing everything else.”
The distinction I’d check is whether those apparently cosmetic tasks actually support keyboard navigation. If it puts a visible focus indicator first, I wouldn’t count that as ignoring your change. If it puts decorative spacing or color tweaks first, I’d ask it to justify that ordering against your new priority. Judge the revised task list, not merely its acknowledgment that it understands.
The new priority has to stay after the next reply. I agree on the nuance between forgetting and failing to act, but I would be more interested in what it produces corrected plan. Continue with an ordinary request such as ‘Break the first task into steps’, without reminding the priority again. This helps you check whether the change brings a carry-through or requires constant supervision.
I would also check whether it changed the release criteria. If keyboard navigation is first on the task list, but the website update still waits on every cosmetic task, it has not really treated the visual work as deferrable. A useful revision should make clear what has to be finished before shipping and what can be delayed. For me, that’s what the practical standard for this is: does it affect the following decisions, or only rearranges a list?
Ask it to explain why each remaining visual task still belongs in the revised plan. That would help distinguish an old task it forgot to remove from work it considers necessary for keyboard navigation. A visible focus indicator, for example, involves appearance, but I wouldn’t lump it in with polishing the site’s colors or spacing.
I agree with checking what blocks shipping, but “visual work can wait” needs that small caveat. Dropping every appearance-related task could be an overcorrection rather than good priority tracking. I’d want the revised plan to separate cosmetic polish from changes that support the new goal, with a short reason for anything it keeps. If it can’t explain that distinction, I wouldn’t trust the reordered list very much. The issue may be understanding what the priority change means, rather than remembering that you requested it.
The explicit replacement wording might get you the project moving, but I wouldn’t take success there as proof it copes well with priorities shifting. You’ve moved from an ordinary request to explaining precisely how it should interpret that request. Useful workaround, but a different standard.
If you want to make a cleaner comparison, give a fresh conversation the same project details with keyboard navigation as the priority from the start. Keep the scope and constraints the same, but skip the history of your changing your mind. Compare that resulting plan to the one from your current conversation. You don’t need identical wording or task lists. You’re looking for whether the old visual-first direction has some unnecessary work attached to the revised plan.
If both plans prioritize decorative work ahead of keyboard fixes, that would be less evidence as to changing priorities being the specific problem. If the fresh plan follows your priorities, but the revised plan is still dragging along the postponed work, that’s stronger evidence that it was the transition which caused it to fail. Neither prove what it ‘remembers’ internally, but the comparison provides more to evaluate than another acceptance of a change followed by a correction.
That’s important, because restarting is a workaround with a cost: you get to carry over the useful project details yourself. I’d be less interested in whether you can get it to eventually prompt in the correct order than how much extra edit work the change creates for you. A planning assistant which requires its plan to be reconstructed on every shift in the priorities is leaving a large chunk of the planning work to you.
Had any visual work actually started, or was this still an untouched task list? That changes what I’d expect from the revised plan. If nothing had started, leaving decorative work at the front would be hard to justify. If a change was already half implemented, I’d want the assistant to distinguish stopping that work from leaving the website in an unfinished state.
There are two separate decisions here: what deserves the next block of effort, and what to do with work already underway. Your new instruction answers the first. It doesn’t necessarily say whether to revert an unfinished change, save it separately, or finish a small piece so the keyboard fixes can proceed. A planning assistant should surface that decision if it matters, rather than quietly treating the original sequence as binding.
For example, suppose the visual cleanup included replacing the header, and that replacement was only partly done. I could accept a brief task to set the unfinished replacement aside before working on keyboard behavior. I wouldn’t accept “finish the header redesign” without an explanation of why the keyboard work requires it. “We already started” isn’t enough. Any exception should have a stopping point, otherwise the postponed work can swallow the next session under the label of finishing up.
That’s a caveat I’d put on @leo82’s fresh-conversation comparison. Carry over the progress state as well as the project requirements. A fresh plan for an untouched website and a revised plan for a partially modified website may legitimately differ. The useful comparison is whether both choose the same next action when they have the same requirements, constraints, and unfinished work.
I’d judge this case by whether the assistant makes that handoff explicit. Which work stops now? Does anything need to be saved, reverted, or brought to a safe stopping point? When does the keyboard work actually begin? Those are operational consequences of changing priorities, separate from moving headings around.
If this was only a planning conversation, though, that caveat disappears. There’s no implementation state to protect. I’d count continuing with unrelated visual cleanup as a missed priority change, without needing to settle whether the model “forgot” anything internally. It may still have the instruction available and simply produce the wrong next action. For a planning tool, that distinction doesn’t make the next action less wrong.
A plan which leaves cosmetic work first misses your change. A plan which switches to keyboard work but turns a small update into a sitewide overhaul misses the constraints you never changed. I’d check for both before calling the revision a success.
I agree with @kernelfoxzone about checking what blocks release, with a caveat: changing the priority shouldn’t give the assistant permission to expand the assignment. Suppose you’d limited the update to a few pages and a fixed afternoon of work. Those limits should survive the switch. If the keyboard fixes won’t fit, the useful response is to flag that conflict and ask what can move, rather than quietly inventing a larger project.
That makes me less concerned about the new plan looking more thorough. I’d want to see the unaffected decisions preserved while replacing the one that you changed. Based on the details that you gave, it missed the switch that was requested, but an overly zealous rewrite would not get a pass either. Being forced to reassert the deadline, page scope, and available effort after every change in priorities is a losing game of its own.
What nobody’s asked is how far into the conversation the switch happened. If you dropped the new priority twenty messages deep, after the model had already repeated the visual-first plan a few times, you’re fighting its own earlier output as much as your correction. It tends to treat its last structured plan as the source of truth and nudge off that, not off your one-line change. That’s a different failure than forgetting.
So I’d push back a little on framing this as priority tracking at all. @greenpanda’s split between ‘what gets effort next’ and ‘what to do with started work’ is the right cut, but even in a pure planning chat the real tell is whether the model anchors to your instructions or to its own prior plan. Quick way to find out: instead of restarting cold like @leo82 suggested, just ask it to restate the current priority order in one line before it plans anything. If it parrots back keyboard-first and then still hands you a cosmetic-heavy plan, the instruction landed and the planning logic is the weak spot. If it can’t even state the order right, that’s your answer and no amount of careful rewording fixes it.
If that visual-first order ever got baked into a titled plan the model generated, it’ll keep steering off that artifact no matter how you phrase the correction. @swiftbot’s restate-the-order check catches whether the instruction landed, but the cleaner fix is to tell it to delete and rewrite the plan outright, not amend it. Patching a plan it still treats as canonical is where the postponed cosmetic stuff keeps sneaking back in.