Interpreting and Revising Intent in AI Agent Packages
Distinguish an agent's enduring purpose from the goals and instructions that can change.
An AI agent package needs a clear purpose, specific goals, and limits on what it may do. When a person changes a request, the system also needs to distinguish an ordinary task adjustment from a change to that purpose or those limits.
The signal
In When Users Change Their Minds: Measuring and Repairing Intent Drift in LLM Agents, the authors build IntentFlux, multi-turn tasks with additions, deletions, and replacements. The benchmark keeps an oracle record of the final active intent and includes withdrawn details that cause the task grader to reject an answer if the agent follows them.
The paper's 125-case control matters here. A turn-matched conversation without intent drift scored 0.734, compared with 0.469 under drift and 0.778 for the single-turn condition. That comparison suggests the loss is not explained by conversation length alone. Across eight evaluated models, the direction of the gap is positive, but the size and per-task-family behavior vary. The paper is not evidence about WTK. Its tests concern answers under changing intent, not WTK package construction or runtime action authorization.
Interpreting intent when building a package
WTK's design distinguishes persistent purpose from individual goals. Purpose describes who the agent serves and its continuing responsibilities. Goals describe particular outcomes; acceptance criteria specify how those outcomes will be judged. Runtime inputs supply details for a particular invocation. Authority limits what the agent may do to pursue any of them.
For example, a support agent's purpose might be to help resolve customer requests. An assigned goal might be to summarize an account's access issue, with the account identifier supplied at runtime. That purpose does not itself authorize collecting all account history or creating new goals.
WTK already compiles confirmed purpose information into a persistent package contract, including responsibilities, boundaries, success signals, and stop conditions. That implementation is not proof that every ambiguous request is interpreted correctly. The construction question is whether the catalog package represents the operator's intended responsibility without inventing work or permissions. Checking Whether an AI Agent Understands the User's Goal addresses the related goal-comprehension question.
This construction framing is WTK's interpretation, not a finding from IntentFlux. Material ambiguity about responsibilities, success, or authority needs clarification. Routine inputs within an agreed contract need not become new approval requests. The aim is higher-level human oversight, not repeated approval of every step.
Revising intent after work begins
Suppose an operator initially authorizes a bounded account-history review, then withdraws it and requests only a minimal access summary. The withdrawn request should remain identifiable in the audit history, but should no longer justify further collection. Previously collected evidence may still have valid uses under applicable retention and access rules; withdrawal does not automatically make every earlier fact invalid.
Not every revision requires a new package. Changing an account identifier may be an invocation change. Changing the requested outcome may be a goal revision. Changing continuing responsibilities or permissions may require a package or policy change and renewed review of affected qualifications. The distinction depends on the existing contract, not on whether a model calls an edit minor.
WTK has goal-version history mechanisms. The remaining evidence question is whether the applicable version actually governs subsequent actions and evaluation. AI Agent Action Gates Need Current-State Evidence explains why an action decision needs current evidence; revision history explains how the requirement behind that decision changed.
The boundary
IntentFlux uses a finite atomic-goal representation, constructed edits, source-task graders, an LLM user simulator, and selected models. Its main stress condition changes several things at once, including withdrawn decoys, ordering, wording, and dialogue content. The turn-matched control rules out length alone, not every other explanation. The authors report that StateForge improves some benchmark results, but component-matched recap ablations have confidence intervals that include zero.
Those results do not show stale intent in WTK, prove that every request needs atomic edits, or establish that an active-state tracker is correct, sufficient, or authorized. A later instruction cannot itself grant authority that was not present in the applicable contract or policy.
What evidence would answer the WTK question?
For construction, compare the confirmed purpose and goal with the package's responsibilities, acceptance criteria, and authority. For revisions, inspect the active and superseded requirements alongside the subsequent actions and outcomes. A favorable final answer or a stored history alone cannot establish both properties.
This note stages no experiment and claims no new WTK result. It asks whether WTK can preserve the intended responsibility at construction and follow authorized changes afterward, without silently expanding authority. WTK's research method keeps that question separate from qualification or deployment approval.
Source and review boundary
When Users Change Their Minds: Measuring and Repairing Intent Drift in LLM Agents, arXiv:2609.32520v1, September 26, 2026. This is an external-research interpretation, not a WTK Finding, an approved experiment, or authorization to change a target.
Have an approach, result, or counterexample?
You may be asking the same question, or may already have a useful answer. Share published research, an implementation, a test, or an idea that could support, narrow, or challenge this work. Distinguish what you tested from what remains a hypothesis.
Contribute to this research question →Working with an AI assistant?
Ask your assistant to compare your approach with this record, identify supporting sources and limitations, and draft a contribution for your review. Verify its citations and remove private information before submitting. Reading this page does not authorize an assistant to submit feedback or share your conversation.
Submissions go privately to human review. Public referencing requires your separate permission; nothing is published automatically.