Defining Intent Drift in Agentic Workflows
Why agent systems need Delta Intent and Drift Detection, not just logs and better prompts
Intent Drift names the failure.Delta Intent records the change.Drift Detection observes runtime divergence.
The agent completed the task. The workflow reached its terminal state. The trace is full. The dashboard shows green. The log records success.
That does not mean the system carried the intent.
The AI industry has built a strong vocabulary for one kind of failure: the model says something false. Hallucination, confabulation, factual grounding failure — these words describe a real problem, and real investment has gone into solving it. Better retrieval, better grounding, better evaluation, better safety layers. When the failure is visible — a wrong fact, a fabricated citation, a dangerous instruction followed — the remediation path is clear. Fix the model. Fix the prompt. Fix the guardrail.
But across the work that led me from a Web3 launch automation project in 2024 through the design of SoloCrew, Cognitive OS, and eventually the Multi-Agent Lifecycle Protocol, I kept encountering a different kind of failure. The model did not say something false. The model said something reasonable, fluent, and locally correct — and yet the work had stopped carrying the meaning it was supposed to carry. The output looked complete. The system reported success. And the intended work had quietly become a different piece of work, without any mechanism registering the change.
I now call this Intent Drift.
Intent Drift is the lifecycle degradation of intended meaning across human input, model interpretation, and long-running agentic execution. It is not hallucination. It is not prompt injection. It is not context window overflow. It can co-occur with any of those, but it can also occur when none of them are present. The model can be truthful, the context can be sufficient, the tools can be correctly configured, and the work can still drift. That is what makes it dangerous — and that is what makes it a distinct lifecycle failure class that the industry has still not adequately separated from hallucination, context loss, and orchestration failure.
But naming the failure is only the first step. Diagnosis is not defense. A system cannot protect itself against Intent Drift by acknowledging that intent may drift, any more than a building can protect itself against fire by acknowledging that fires may happen. The building needs detection, suppression, evidence, and recovery — not just a name for the danger.
This essay defines three concepts that together form the minimum defense. Intent Drift names the failure. Delta Intent records the difference. Drift Detection observes the runtime discrepancy. These three are linked but structurally distinct, and collapsing them is the most common architectural mistake I see in governance discussions today.
Intent Drift is not hallucination
The distinction between Intent Drift and hallucination is not cosmetic. It determines the remediation path.
If the problem is hallucination, the answer is a better model, better grounding, or better evaluation. Those are execution-layer answers, and they work at the execution layer. But if the problem is that the intended meaning of the work degraded across time, interpretation, delegation, and tool execution — that is a lifecycle problem, and it requires lifecycle-layer answers.
A model can be truthful and still carry the wrong work.
Consider what happens when a founder uses an AI agent system to produce a governance essay. The founder’s intent evolves across several rounds of interaction: the first request is broad, the second narrows the scope, the third specifies a conceptual axis, the fourth adds constraints about what the article should not become. By the time the system produces an output, the active intent is a layered, contextual object with history, constraints, and implicit expectations. If the system executes against the first version of the request while the intent has moved to the fourth, the output may be fluent, well-structured, and completely wrong — not because the model hallucinated, but because the work drifted from the intended axis while appearing to remain on track.
This distinction matters for infrastructure builders and enterprise teams because it changes where the control surface must sit. If every failure is treated as a model-layer problem, every solution will be a model-layer solution: more reasoning, more safety, more internal checks. But Intent Drift cannot be fully solved inside the model, because the model does not own the whole lifecycle of the work. The changing human intent, the project history, the downstream tools, the repository state, the human acceptance boundary — these all exist outside the model. The defense must exist at the same level as the failure.
The three layers of Intent Drift
Intent Drift does not come from one source. It accumulates across at least three layers, each with a different character and a different remediation path.
Human-input drift
The first layer happens before the model makes any visible mistake. Human intent is not fixed. It changes through work — sometimes because the user discovers the real requirement only after seeing the first output, sometimes because business conditions shift, sometimes because the first request was deliberately vague and the real constraints surface later. A founder begins with “prepare a launch article.” After several rounds, the real intent becomes “prepare a launch article that positions this as a protocol-level argument, avoids certification claims, and connects to the AI Agent Lifecycle thesis.” Those are not the same task. If the system keeps executing against the first version, it is already drifting before the model has done anything wrong.
In my own building process, the clearest projects were never the ones where requirements stayed frozen. They were the ones where requirement changes were recorded, compared against the previous version, and propagated to downstream work. The dangerous projects were the ones where intent changed gradually, naturally, invisibly — and nobody registered the delta until the output looked subtly wrong. This is why long-running AI work often feels off without anyone being able to pinpoint the moment it went wrong. The model is competent. The wording is fluent. The task appears complete. But the system is still carrying an earlier version of the work, and it has not failed at language — it has failed at lifecycle continuity.
Single-model interpretation drift
The second layer happens when the user’s intent is relatively clear, but the model silently converts it into a different kind of task. The user asks for a boundary review; the model rewrites the document. The user asks for an architecture critique; the model produces a product roadmap. The user asks for an essay in a specific public writing style; the model produces a structured protocol note.
This failure mode is especially dangerous because it is disguised as helpfulness. The model does not refuse, crash, or hallucinate something absurd. It simply reframes the work into the kind of work it knows how to produce well. The result looks competent. The system moves forward. The downstream planner, executor, and reviewer all operate on the model’s reframing without knowing that a substitution occurred. A reasoning trace can explain how the model arrived at an interpretation. It cannot prove the interpretation preserved the original intent. The missing object is comparison — a structured record of what the user intended versus what the model interpreted, and where the two diverged. That comparison is not a prompt trick. It is a governance object.
Multi-agent semantic-loss drift
The third and deepest layer occurs when intent passes through multiple agents, tools, memory, delegation, and time. A planner receives the full intent. A researcher receives a compressed instruction. A writer receives a narrowed brief. A reviewer sees only the final artifact. A tool receives only parameters. Every handoff can drop constraints, weaken boundaries, or compress meaning. Every local step may look reasonable. The global work still drifts.
I made the same argument when I wrote about how the industry misdefined multi-agent AI: more agents do not automatically create governance. More handoffs simply create more places for meaning to disappear. A workflow graph can coordinate execution. It cannot by itself preserve lifecycle responsibility. That is why Intent Drift must be defended through Delta Intent and Drift Detection, not just through better routing.
What the three layers share
Across all three layers, the structural pattern is the same: the system continues to execute while the intended meaning degrades. The degradation is not catastrophic. It is gradual, invisible, and often disguised as reasonable progress. Human-input drift is natural — requirements change, and they should. Interpretation drift is subtle — the model reframes rather than refuses. Multi-agent drift is structural — each handoff is locally correct. What makes Intent Drift a distinct failure class is precisely this combination: not one bad output, not one wrong tool call, but the accumulated loss of meaning across the lifecycle of work.
A green dashboard can still hide a drifted intent
Consider a financial-services team using an agent workflow to prepare a compliance briefing. The first intent is straightforward: summarize the latest internal risk findings for the quarterly review. The agent plans the work, retrieves prior reports, drafts the briefing, routes it through an internal review step, and produces a polished document. The dashboard is green. The trace is complete. The workflow ends successfully.
But halfway through the process, the business intent changed. The team no longer needed a summary for the quarterly review. They needed a board-facing escalation memo that separated operational risk, regulatory exposure, and evidence gaps — a document with a fundamentally different audience, structure, authority requirement, and acceptance boundary. The workflow continued executing the older task. Nothing crashed. The model did not hallucinate. The tool calls were valid. The trace was full.
The failure was not execution failure. The failure was that the system completed the wrong lifecycle intent. And the system had no mechanism to detect that the intent had moved, no comparison record that showed what changed, and no runtime observation that flagged the divergence between the expected work state and the actual output.
This is why Intent Drift is not an academic concern. It is a production concern. The more consequential the work becomes — financial reporting, legal analysis, compliance documentation, clinical decision support, infrastructure deployment — the more dangerous it is that a system can show green while delivering against an expired intent. The dashboard measures execution. It does not measure whether meaning survived.
Delta Intent: the missing comparison object
Naming Intent Drift is necessary. It is not sufficient.
A system that can say “intent may drift” has diagnosis. It does not have defense. The gap between diagnosis and defense is the gap that Delta Intent fills.
Without a comparison layer, drift remains a feeling. The user says “this is not what I meant.” The agent says “the task is complete.” The trace says “the system executed.” The log says “no error.” Everyone can see something is wrong. Nobody can point to where it happened, because the system has no structured record that compares what was intended against what is now being performed.
I define Delta Intent as the recorded difference between intended work and observed or proposed execution. It asks a simple but powerful question: what changed between the work that was intended and the work the system is now carrying?
That change may be semantic — an article that was supposed to define a mechanism became a general opinion piece. It may be procedural — the system was supposed to review, but it rewrote. It may be authoritative — the agent was allowed to draft, but it published. It may be evidential — the system recorded activity, but failed to preserve why the activity was authorized. It may be outcome-based — the workflow completed, but the result was never accepted under the original criteria.
Delta Intent is the object that makes each of these differences explicit, structured, and reviewable. It turns drift from a narrative judgment — “I feel like this is not right” — into an inspectable comparison: “the intended axis was X, the delivered axis is Y, and the gap is Z.”
This is the layer most agent frameworks still lack. Current systems can show state, traces, tool calls, messages between agents, and checkpoints. They often cannot say: this is where the intended work changed; this is where the agent began executing a different version of the task; this is where readiness language became certification language; this is where completion was mistaken for accepted outcome. Without that comparison layer, observability becomes a mirror. It shows the system moving, but not whether the movement still serves the original work.
Drift Detection: when expected lifecycle state meets observed reality
Delta Intent compares meaning. Drift Detection observes reality. Those two must not be confused, and collapsing them is the architectural mistake that turns governance discussions vague.
Delta Intent is semantic and comparative. It asks whether the meaning, scope, authority, or accepted outcome of the work changed between intended and actual execution. Drift Detection is runtime-observational. It asks whether the state the system expects — based on its current intent, plan, authority boundaries, and lifecycle position — matches the state that actually exists in the world.
The expected state may include the active intent version, the approved plan, the authority boundary, the agent role assignment, the allowed tool scope, the evidence obligation, and the accepted outcome criteria. The observed state may be a file that changed, a tool that executed, a repository that moved, a memory record that updated, a published artifact that contains language the authority boundary forbids, or an external system that now holds a consequence the plan did not anticipate.
The runtime question is direct: did the system observe a state that should not exist under the current intent and plan? If yes, the system has detected drift. But detection alone is not governance. A changed file is not always a failure. A modified plan is not always wrong. Work requires change. Drift Detection needs Delta Intent to interpret the meaning of what changed. A runtime can observe that an article was generated — Drift Detection confirms the artifact exists. Delta Intent tells us whether the article followed the requested conceptual axis. A runtime can observe that a tool call modified a configuration file outside the expected scope — Drift Detection catches the discrepancy. Delta Intent tells us whether that modification altered the project’s direction or violated an authority boundary.
Why both are necessary and neither is sufficient
Drift Detection without Delta Intent is noise. The runtime observes changes constantly — files are written, tools are called, states transition. Without a comparison layer that interprets which changes matter to the meaning of the work, every observation triggers equal alarm. The system cannot distinguish a planned modification from a scope violation. Detection becomes a stream of undifferentiated signals, and the operator learns to ignore it.
Delta Intent without Drift Detection is policy theater. The system can record that the intent changed, and it can compare intended work against a proposed plan. But if it never checks what actually happened in the world — whether the file was actually modified, whether the artifact actually contains forbidden language, whether the tool actually crossed the authority boundary — then intent governance remains a declaration. The system reasons about what should be true without verifying what is true. That is the difference between governance and aspiration.
A trace can prove movement. It cannot prove meaning survived. A workflow graph can show where work went. It cannot show whether intent arrived. Delta Intent is the missing record between “the user meant this” and “the system did that.” Drift Detection is the missing observation between “the lifecycle expected this” and “the world now looks like that.” Together, they form a control loop. Apart, they are fragments.
Logs show activity. They do not prove intent continuity.
This is the point where many teams deceive themselves. They add logs and believe they have governance. They add traces and believe they have accountability. They add dashboards and believe they have oversight.
Logs matter. Traces matter. Workflow histories matter. Tool-call records matter. Without them, post-hoc reconstruction is impossible, and I do not argue against them. But they are not evidence of intent continuity.
A log can tell you that a tool was called. It does not prove the tool call was authorized under the current intent. A trace can show that an agent passed work to another agent. It does not prove the receiving agent inherited the correct constraints. A dashboard can show that a workflow completed. It does not prove the outcome should have been accepted. A human approval event can show that someone clicked approve. It does not prove that the right human role approved the right action with sufficient evidence.
LOGS VS LIFECYCLE EVIDENCE
- Ordinary log
- Activity happened.
- Trace
- Execution path is reconstructable.
- Drift Detection
- Something diverged from lifecycle plan.
- Delta Intent
- Divergence altered the meaning of work.
- Accepted Outcome
- Work became, or did not become, delivery.
The distinction is structural. Logs record activity. Drift Detection observes divergence. Delta Intent explains what changed. Evidence connects activity to responsibility. Accepted Outcome determines whether the work became delivery. A system that has only logs and traces is observable after the fact. A system that also has Drift Detection, Delta Intent, and Accepted Outcome semantics is governable during the lifecycle. That is the difference between execution visibility and lifecycle control — and it is the difference that decides whether agentic AI can move from demos into consequential enterprise use.
Existing agent frameworks are not the enemy. They are not the control layer either.
LangGraph can represent state. CrewAI can coordinate roles. AutoGen can manage multi-agent conversations. LangSmith and Phoenix can make execution more observable. These tools are useful. They solve real engineering problems. They are not weak systems.
But state is not intent.
A checkpoint can show where the workflow paused. It does not prove that the work still carried the confirmed intent. A trace can show how agents moved information. It does not prove that meaning survived the handoff. A human approval step can interrupt execution. It does not prove that the right human role accepted the right outcome under the right authority boundary.
The problem is not that these frameworks are useless. The problem is that they are being asked to carry a lifecycle-governance burden they were not designed to own. They operate at the execution orchestration layer. They answer questions like: who runs first, who runs next, where does the graph checkpoint, how do we retry on failure. They do not systematically answer: what was intended, what changed, where did meaning diverge from execution, and whether the final result should be accepted as delivery.
That is not a criticism of their architecture. It is a statement about the layer they occupy. The execution layer and the lifecycle layer are not the same layer. Orchestration, observability, and checkpoint infrastructure can become part of the answer. But only if another layer defines what must remain true while execution moves. That layer is where Delta Intent and Drift Detection belong — not inside any particular framework, but above all of them.
You cannot solve a distributed lifecycle failure inside a single model
There is a tempting response to Intent Drift: put more governance inside the model. If it drifts, make the model’s internal reasoning stronger. If it loses context, expand the window. If it follows the wrong interpretation, build a deeper internal safety hierarchy. If it fails to preserve intent, embed a cognitive integrity mechanism inside the neural architecture.
Some of that work may improve local model safety. But it misunderstands the boundary of the problem. Intent Drift is not primarily a neural-local failure. It is a distributed lifecycle failure. The model does not own the whole work unit — not the changing human intent, not the project history, not all external tools, not downstream repository states, not published artifacts, not human acceptance, not remediation closure.
When I traced how AI Agent Lifecycle grew from real engineering failures, the core finding was that projects lost control not because the agent was incapable, but because project state had no lifecycle structure to hold it. Intent drifted. Context decayed. Confirmation had no downstream consequence. Delivery had no acceptance state. The same principle applies directly here: the model can help interpret intent, detect contradictions, summarize evidence, and propose recovery. But it should not be the only governance boundary, because the failure it is defending against extends beyond its own execution surface.
This follows the same pattern that every other layer of serious infrastructure has already learned. A database is trusted not because every query is clever, but because transactions, permissions, constraints, and recovery semantics exist outside the query. An operating system is trusted not because every process behaves nicely, but because privilege boundaries, isolation, and audit mechanisms exist outside the process. A distributed system is trusted not because every node is honest, but because protocols define how state, consensus, failure, and recovery are handled across nodes. Agentic AI needs the same structural shift. The model is not the governance layer. The lifecycle is the governance layer.
Where MPLP fits
MPLP matters here because it separates three questions that most agent stacks collapse.
What was intended? What changed? What did the runtime observe?
Intent Drift answers the first failure question: the intended meaning degraded. Delta Intent answers the comparison question: this is how intended work diverged from proposed or observed execution. Drift Detection answers the runtime question: this is where expected lifecycle state no longer matched external reality.
In MPLP, that distinction matters because Trace should not merely record activity — it should preserve the relationship between intent, authority, evidence, and accepted outcome. Confirm should not merely interrupt execution — it should protect the boundaries where meaning, scope, or authority requires human revalidation. Plan should not merely list steps — it should express the execution path against which Drift Detection can observe divergence and Delta Intent can compare meaning.
MPLP is not the only possible path. Others may design different lifecycle implementations for the same problem. But MPLP is one protocol path designed around the object that agent systems keep losing: lifecycle responsibility. It should not be overstated as legal proof, certification, or exclusive solution. That boundary has mattered throughout this series, and I maintain it here.
Execution is not delivery if the intent did not survive
The next generation of agent infrastructure will not be judged only by how many tasks agents complete. It will be judged by whether the work can carry meaning across time.
That requires more than prompts. More than traces. More than orchestration. More than a human approval button at the end.
The industry currently has the components: prompts, traces, tools, evals, human approval, memory, workflow graphs. But components are not a control loop. A trace without intent comparison does not prove alignment. A tool permission without authority boundary does not prove authorization. A human approval without responsibility mapping does not prove oversight. A workflow completion without accepted outcome does not prove delivery. A runtime observation without Delta Intent does not prove semantic drift.
The components exist. The lifecycle object model that connects them has been missing.
Intent Drift names the failure.
Delta Intent records the change.
Drift Detection observes the divergence.
Accepted Outcome decides whether execution became delivery.
Intent Drift names the failure mode. Delta Intent is the record of how intended work changed. Drift Detection is the runtime mechanism that observes divergence between expected lifecycle state and actual system state.
Logs tell us what happened. Delta Intent tells us what changed. Drift Detection tells us where the system diverged. Trace makes it reviewable. Accepted Outcome decides whether the work became delivery.
Without that chain, agent systems will keep producing green dashboards for work that no longer means what it was supposed to mean. That is not delivery. That is execution with semantic loss.
And execution is not delivery.
Related ideas
Recommended proof path
If you only follow one next step after the thesis, continue from MPLP to Cognitive OS.