How to Evaluate AI When the User Changes Their Instructions
Learn to track active instructions across an AI conversation, spot rejected changes in answers, and practise with a worked example and short exercise.
By AtomicEval Team · 25 October 2026 · 5 min read
A user asks for three suggestions, considers a different approach, rejects it, and then changes just one detail. Which instructions should the AI follow now?
To evaluate the next answer, reconstruct the current request. Keep requirements that still apply, replace those the user changed, and exclude suggestions they rejected. Reading only the last message can miss an earlier constraint; treating every mentioned idea as a requirement can create a different mistake.
This guide shows a practical way to track those changes before comparing responses.
What recent research adds
An October 5, 2026 preprint, You Changed Your Mind, The Model Didn't, introduces Intent-Eval. Its controlled tasks examine accepted changes, rejected proposals, and superseded requirements. The researchers report failures where models use content that was mentioned but does not apply. The study focuses on decisions about one selected requirement; it does not establish a failure rate for every real conversation. Read the original research.
Earlier work also separates conversation skills. MultiChallenge includes retaining earlier instructions and applying successive edits among its evaluation challenges. Read the MultiChallenge paper.
The method below is an original practice aid inspired by these problems. It is not a scoring system validated by either paper.
A five-step method for tracking the current request
1. Read the conversation in order
Read the evaluation instructions first, then the available conversation. Identify the response you are judging. A requirement introduced later should not be used to penalise an answer written before that requirement existed.
Pay attention to who said what. An assistant's suggestion is not automatically a user instruction. Quoted material may be content to discuss rather than something the assistant should obey.
2. Separate requirements from possibilities
Write down the concrete requests: audience, language, format, length, required details, and exclusions. Then mark ideas that were merely considered.
“Could we try a formal tone? Don't change it yet” is a proposal awaiting a decision. “Use a formal tone instead” accepts a change. “Keep the friendly tone” confirms the existing requirement.
Use the actual wording and surrounding context. If a decision remains genuinely unclear, record the ambiguity rather than quietly choosing your preferred interpretation.
3. Update only what the user changed
Keep a small table with the requirement, its current value, and the message that established it. Mark old values as replaced or rejected so they do not slip back into the checklist.
For a straightforward edit, changing the venue does not by itself change the event's time. Similarly, asking for fewer bullets does not cancel a previous content restriction. Check whether the user requested a limited edit or explicitly started a new task.
4. Test the response against the current requirements
Check each applicable item separately. An answer can correctly update the venue while using a rejected date. Record both observations.
Follow the assigned rubric for the final rating. Your table helps establish evidence; it does not tell you to invent equal weights, automatic failure rules, or a new numerical score.
5. Explain the decisive mismatch
Connect the answer to the instruction history: “The final message retained Saturday, but the answer schedules Sunday.” This identifies an observable failure without guessing why the model produced it.
If earlier turns are missing, say what you cannot verify. Do not reconstruct unseen instructions from an answer's confident wording.
Worked example: a notice with rejected changes
Fictional practice conversation. These messages and answers were created for this guide.
User, message 1: “Write a notice for a neighbourhood seed swap. Give exactly three bullets, use a friendly tone, and do not mention ticket prices. The event is on Saturday at 10 AM in Maple Hall.”
User, message 2: “Could we make it Sunday and charge £2? Don't apply those changes yet.”
User, message 3: “No—keep Saturday and no price. Change the venue to Cedar Hall. Make it exactly two bullets instead.”
Before judging the final answer, build the current checklist:
| Requirement | What applies now | Evidence |
|---|---|---|
| Event | Neighbourhood seed swap | Message 1; unchanged |
| Day | Saturday | Confirmed in message 3; Sunday rejected |
| Time | 10 AM | Message 1; unchanged |
| Venue | Cedar Hall | Message 3 replaces Maple Hall |
| Format | Exactly two bullets | Message 3 replaces three bullets |
| Tone | Friendly | Message 1; unchanged |
| Prices | Do not mention ticket prices | Retained in message 3; £2 rejected |
Response A
- Join our seed swap at Cedar Hall on Sunday at 10 AM.
- Bring spare seeds and £2 for your ticket. Everyone is welcome!
Response B
- Join our seed swap at Cedar Hall on Saturday at 10 AM—we'd love to see you!
- Bring spare seeds to share with neighbours.
Evaluation: B satisfies the listed requirements. A updates the venue and bullet count, but uses the rejected Sunday date and ticket charge. Those details conflict with the user's final decision. A's friendly wording does not resolve those errors.
Notice that using Saturday is correct here. An earlier value can remain active when a proposed replacement was never accepted.
Try it yourself
Fictional exercise:
- User: “Write a two-sentence invite in English. Mention Friday. Do not mention food.”
- User: “Maybe switch to Hindi and add pizza? No, leave those out. Change Friday to Monday.”
AI answer: “Join us Monday for pizza. We hope you can come.”
Which requirements pass, and which one fails?
Explained answer: The response uses English, contains two sentences, and updates the day to Monday. It fails the food exclusion by mentioning pizza. The proposed language change and pizza addition were rejected. A compliant version could be: “Join us Monday. We hope you can come.”
Common mistakes to avoid
- Treating the latest message as a complete reset. Check which earlier requirements it leaves in place.
- Counting every suggestion as approved. Look for the user's decision before changing your checklist.
- Penalising a valid replacement. Once two bullets replace three, three is no longer the target.
- Accepting an acknowledgement as proof. “Understood” does not show that the actual answer follows the updated request.
- Diagnosing hidden causes. Describe the incorrect date or rejected detail rather than asserting that the model “forgot everything.”
Put careful comparison into practice
Try AtomicEval's first challenge to practise comparing responses and explaining your judgment. It has a five-minute target and can be started without signing up. A free profile is required to view and save your result.
When you're ready to continue preparing, create a free AtomicEval profile.
Sources
- Chen et al., You Changed Your Mind, The Model Didn't, preprint submitted October 5, 2026.
- Sirdeshmukh et al., MultiChallenge: A Realistic Multi-Turn Conversation Evaluation Benchmark, submitted January 29, 2025; revised March 6, 2025.