AI evaluation
EvolvingIntent Turns Static Benchmarks Into Conversations With Changing Requirements, Exposing Gaps in Agents’ Ability to Track Revised Instructions
Microsoft Research introduced EvolvingIntent, which transforms existing math, SQL, search, and programming tasks into multi-turn conversations in which requirements are progressively disclosed, revised, or redirected. Experiments show that models’ performance on single-turn benchmarks does not transfer reliably to scenarios where requirements continually change. The data-construction and evaluation code has been released publicly.
Microsoft Research researchers submitted EvolvingIntent on July 22 to address an agent failure mode often overlooked by static benchmarks: when users add constraints during execution, withdraw previous values, or even redirect the request to a different task, can a model complete the work according to the latest intent instead of continuing with an earlier plan?
Rather than creating a new set of dialogue tasks that can only be evaluated manually, the framework first decomposes existing samples into a primary function, required arguments, and a reference answer. It then generates counterfactual values for the parameters and constructs a related but distinct predecessor function. Using these components, a simulator arranges multi-turn interactions across four scenarios: progressively disclosing parameters, revising parameters midway, switching the primary task, and combining all three. The framework continues to use the original benchmarks’ execution-based evaluation or reference-answer scoring, allowing score declines to be attributed more directly to changing intent rather than to a different evaluation methodology.
The public implementation currently covers GSM8K, BIRD-SQL, BrowseComp+, and SWE-bench Verified, spanning arithmetic, text-to-SQL, agentic search, and repository repair. The team reports that several model families deteriorate substantially after only a few intent changes, even when they perform strongly with complete, single-turn prompts. This is especially important for coding agents: if a user first asks an agent to fix a defect and later adds a constraint prohibiting API changes, the agent cannot simply append the new instruction to its original plan. It must reassess which assumptions, tool results, and pending tasks are no longer valid.
The repository provides a deterministic `eval` mode, a randomly sampled `train` mode, and a naturalizer that rewrites structured turns into more natural language. Model calls use the OpenAI Python SDK to connect to OpenAI or Azure OpenAI. This also creates the main limitations: some conversations and counterfactual data are synthesized by models, so their naturalness and difficulty may be influenced by the generating model; the tasks currently covered are also insufficient to represent real-world work involving ambiguous preferences, multi-person collaboration, or long-running changes in external state.
Developers can incorporate the framework into agent regression testing and separately record which version of the requirements was ultimately followed and whether obsolete tool actions were reversed after a change. Key questions for future study include whether third parties can reproduce the data and complete results, and whether explicit state machines, plan-invalidation markers, or event-sourced memory can narrow the gap.