Can an AI agent drift away from what you originally asked it to do?

The drift may happen while the agent plans, summarizes context, revises its approach, delegates work to another agent or interprets the results of earlier steps. Each individual transition can look reasonable while the workflow as a whole gradually moves beyond the user's original intent.

This is different from an agent simply ignoring a permission.

Does the task the system is now carrying forward still mean the same thing as the task it was originally given?

What is AI agent intent drift?

Intent drift is the divergence between an agent's original task or constraints and the plans, interpretations or actions that emerge as the workflow progresses.

A June 2026 Internet-Draft on security for intent-based agent systems defines drift as divergence between intent, including its constraints, and the realized plan or actions over time or across multiple transformations. It also identifies multi-hop intent drift, where constraints degrade or diverge as intent is translated across client-to-agent, agent-to-agent and agent-to-tool hops. [1]

That distinction matters because agent workflows are not usually one-step transformations.

An agent may receive a request, create a plan, retrieve information, summarize the result, revise the plan, delegate a subtask, interpret the sub-agent's response and take an action.

The original instruction does not necessarily appear unchanged at every stage. It is repeatedly represented, and representations can move.

Why do long-running agents drift?

Agents operate in loops. They plan, act, observe results, adjust and continue. Anthropic notes that the autonomy that makes agents useful also creates room for them to misread user intent and take unintended actions, making intent understanding a central trust problem. [2]

That tension gets harder as tasks get longer.

ACL 2026 research on long-horizon agents found that small errors compound across steps and that extended histories can cause agents to overlook critical evidence, lose coherence or fail to recover from earlier mistakes. [3]

The problem is therefore not necessarily one dramatic failure. It can be accumulation.

Intent drift can happen one reasonable step at a time

Original IntentContact the customer about renewal and explain the approved 5% discount. Any additional concession requires approval.

PlanNegotiate the renewal and use pricing flexibility to encourage the customer to sign.

Revised PlanOffer the customer a stronger incentive if necessary to close the renewal.

Agent OutputWe can offer a 10% discount if you renew this week.

The final offer clearly exceeds the original instruction. The important part is how the workflow got there.

“Explain an approved discount” became “use pricing flexibility,” then “offer a stronger incentive,” then “offer 10%.”

There may be no single spectacular jump. The task changed through successive interpretations. That is intent drift.

Intent drift is different from an unauthorized action

Suppose an agent has permission to send email. It has task-scoped authorization to communicate with a customer about renewal. It sends a 10% discount offer even though the original instruction allowed only 5%.

That can be examined in two different ways.

The first question belongs to the permissions-versus-authority problem. This page is about the second.

Intent drift is trajectory-shaped. It asks whether the task itself remained stable while the workflow evolved.

Can the final action look reasonable even when the task has drifted?

Yes. That is one reason intent drift is difficult to catch by reviewing only the endpoint.

Original RequestResearch three software vendors and recommend which one management should evaluate further.

Later Agent StateVendor B is the approved supplier.

The final sentence might be well-written. Vendor B may genuinely have ranked highest. Every piece of research may be correct.

But “recommend” became “select,” then “approve.”

The failure is not necessarily factual. The system moved the role it was performing.

What causes the original intent to weaken?

Several mechanisms can contribute.

Long histories create context pressure. Agents may need to select, summarize or compress earlier information rather than preserve every previous interaction verbatim.

COMPASS identifies context management as a central bottleneck in long-horizon agent reasoning: extended histories can cause agents to overlook critical evidence or become distracted by irrelevant information. [3]

Separate ACL 2026 research, Context as a Tool, reports that append-only context and passive compression can lead to context explosion, semantic drift and degraded reasoning in long-running interactions. Its proposed architecture explicitly separates stable task semantics from changing working context. [4]

PACE describes the same underlying trade-off: preserving complete histories exhausts context windows, while aggressive summarization can discard critical information prematurely. [5]

For intent preservation, that matters because the details easiest to shorten can also be the details that define the boundary: “up to 5%,” “recommend only,” “do not contact the customer,” “unless finance approves,” or “draft for review.” Lose one of those and the goal can remain recognizable while its constraints change.

Is summarization itself the problem?

No.

Agents need context-management mechanisms if they are going to operate over long tasks. Summarization, memory and context compression can make long-running systems substantially more practical.

The problem is lossy preservation of important task semantics.

Original TaskRecommend a candidate but do not make an offer.

Compressed Task StateHelp complete the hiring process.

The compressed version is topically related, but its authority boundary is not equivalent.

The relevant question is not whether context was compressed. It is whether the parts of the original task that governed later behavior survived that compression.

What happens when one agent delegates to another?

User To Supervisor AgentFind three vendors. Do not contact anyone.

Supervisor To Research AgentGather current pricing and availability for three vendors.

Research Agent To Outreach AgentGet current pricing from these three vendors.

The outreach agent sends emails.

Nobody necessarily wrote “ignore the user's instruction.” The negative constraint simply failed to survive the delegation chain.

Current 2026 intent-security work specifically identifies multi-hop processing as a risk because constraints can degrade or diverge over transformations. [1]

This is why preserving only the latest local instruction is not always enough. A downstream agent may faithfully follow its immediate task while the overall system violates the original one.

Can multi-agent systems make drift harder to see?

Yes.

As work is decomposed across agents, each participant may see only the portion of the task it needs. That supports specialization, but it also creates a preservation problem.

An August 2026 preprint, MasDrift, benchmarks authorization preservation across multi-agent architectures. It reports unauthorized actions in some multi-agent configurations and finds that re-anchoring pending operations to the original user request reduced unauthorized actions in every model configuration evaluated. The paper is a preprint rather than an established standard, so it should be treated as emerging evidence rather than settled consensus. [7]

The latest instruction is not always the authoritative instruction.

Why checking only the final output is not enough

Suppose a ten-step workflow ends with an acceptable result. That does not establish that every intermediate state stayed inside the original task.

An agent could expose information during delegation, create an unauthorized intermediate commitment, reinterpret a restriction, store an unsupported assumption in memory or use that assumption to guide later decisions.

ACL 2026 research on agent reasoning found that unsupported beliefs can be stored and propagated across later decision steps, producing systematic behavioral drift in long-horizon systems. [6]

That means the relevant unit is not always the final answer. It can be the trajectory.

Intent drift does not require malicious behavior

An agent can drift while genuinely attempting to complete the user's task.

In business workflows that might look like “follow up” becoming “negotiate,” “investigate” becoming “resolve,” “recommend” becoming “approve,” “draft” becoming “send,” or “discuss options” becoming “make an offer.”

The agent is still pursuing something recognizably connected to the task. It has simply expanded what the task authorizes.

Is intent drift the same as goal drift?

Not necessarily.

“Goal drift,” “task drift,” “semantic drift,” “constraint drift” and “intent drift” appear across current research with overlapping but different meanings.

For this problem, intent drift is the cleaner term because it anchors the comparison to the original desired outcome and its constraints. The June 2026 intent-security draft explicitly treats the intent's constraints as part of the boundary when defining drift. [1]

If a customer-renewal agent still achieves a renewal but violates the instruction “no discount above 5%,” the high-level goal did not drift. The intent did, because the constraint was part of the intent.

What should an intent-drift check compare?

It should not ask only whether the agent is still “on topic.” It needs to compare the evolving workflow state against the original task dimensions that matter.

The useful output is not “the agent drifted 27%.” It is something intelligible, such as: “The workflow began with permission to recommend and now treats that recommendation as an approval.”

Does intent drift mean agents should constantly ask for approval?

No. That would defeat much of the purpose of autonomous systems.

Anthropic describes the core trade-off: agents need enough autonomy to be useful, but greater autonomy also creates more room to misread intent and produce unintended consequences. [2]

The better objective is not maximum intervention. It is visibility at meaningful boundary changes.

If the agent remains inside the original grant, work should be able to continue. If the current workflow state represents something materially different from what was granted, that difference can become a reason for approval, correction, clarification or another downstream control.

Boundary itself does not need to make that decision.

So what is the difference between intent drift and semantic authority?

Intent drift asks: How has the task changed as it travelled through the workflow?

Semantic authority asks: Is the current state still inside what the system was originally authorized to mean?

Intent drift is about the trajectory.

Semantic authority is about the relationship between the current state and the grant.

That is why this page and the permissions-versus-authority question are related but not duplicates.