June 14, 2026
AI Drift Is Scope Creep
Holly Prole
Human projects drift.
A team begins with a clear mandate, a defined scope, an approved budget, and a set of deliverables. Then execution starts. One requirement gets interpreted broadly. One exception becomes a side project. One stakeholder asks for a “small” addition. A developer improves something that was not requested. A researcher follows an adjacent question because it is interesting. A vendor review turns into a market map. The work continues, and much of it remains useful. But gradually, the project becomes something other than what was approved.
Organizations have a name for this: scope creep.
They also have a discipline for managing it. Serious projects are not governed by good intentions alone. They use charters, scope documents, acceptance criteria, status reports, risk logs, change requests, steering committees, and project managers. These mechanisms exist because human work does not automatically remain attached to the original mandate. Execution has to be governed.
AI systems now have the same problem, but faster.
Autoregressive drift is scope creep at machine speed.
A generative model or agent can begin with the right instruction, the right documents, and the right objective, then gradually move away from the task it was supposed to serve. The movement may not look like failure. The system may remain fluent, useful, and apparently professional. Each intermediate step may look locally reasonable. But the work can still depart from the governing objective.
A threshold becomes a general concern. An exception becomes background context. A narrow task becomes a broader, easier one. A constraint that was supposed to govern the work becomes one consideration among many.
That is not simply a prompting problem. It is an execution-governance problem.
The vendor-selection agent
Consider an enterprise that deploys an AI agent to support a vendor-selection workflow.
The mandate is narrow. The agent is asked to identify three compliant vendors for a specific internal workflow. It must use approved sources, exclude vendors without required certifications, flag unresolved data-handling risks, and escalate any vendor that fails a required control. The output should be a recommendation memo with evidence attached.
The prompt may be clear. The source universe may be available. The policy documents may be retrievable. The agent may even begin correctly.
Then the drift begins.
A required certification becomes a “preferred” certification. A missing control attestation becomes “not disclosed” rather than disqualifying. A vendor outside the approved source universe is included because it appears well funded or widely used. The agent adds a market landscape section because it seems helpful. The memo becomes more polished, more expansive, and more impressive, but less faithful to the actual mandate.
This is exactly how scope creep works. The project does not fail by stopping. It fails by continuing in a plausible but increasingly misdirected way.
In a human project, this drift may unfold over days or weeks. A project manager can catch it in a standup, a status report, a milestone review, or a steering committee meeting. With AI, the same movement can happen in seconds, across hundreds or thousands of intermediate steps. By the time a human reviewer sees the final memo, the system may already have built a coherent recommendation on top of a softened constraint.
That speed asymmetry matters. It is why periodic review alone is not enough. When execution moves at machine speed, governance has to move closer to execution.
Prompt engineering is too narrow
Prompt engineering was built around a simpler mental model: the user asks, the model answers. Within that model, better instructions matter. They can improve relevance, tone, format, reasoning, and source use. But agentic AI changes the frame because the system no longer merely answers. It executes.
An agent searches, summarizes, classifies, routes, compares, calls tools, updates records, drafts communications, and produces intermediate states that influence later steps. The question is no longer only whether the initial instruction was clear. The question is whether the system stayed attached to the mandate while work unfolded.
That is the execution-to-mandate gap: the distance between what the organization asked the system to do and what the system actually does as the workflow develops.
Prompt engineering can improve the starting point. It can make the mandate more explicit. It can tell the model what matters. But a project plan is not the same as project management. A charter does not enforce itself. A scope document does not prevent scope creep simply by existing.
The same is true of prompts.
A prompt can state the objective. It cannot, by itself, guarantee that every later step remains governed by that objective. In long outputs and agentic workflows, the work product becomes part of the state from which the next step proceeds. Once drift enters the sequence, it can feed forward.
That is why the right enterprise analogy is not only communication. It is project management.
| Project management | Agentic AI governance |
|---|---|
| Project charter / scope | Semantic contract |
| Scope creep | Drift |
| Status reporting | Runtime telemetry |
| PM oversight | Runtime control |
This table is not just a metaphor. It is a translation between two operating disciplines.
A project charter defines what the work is supposed to accomplish; a semantic contract defines the governing objective, constraints, evidence requirements, exclusions, and escalation rules for an AI workflow.
Scope creep is what happens when execution gradually departs from the approved mandate. Drift is what happens when generated behavior gradually departs from the governing objective.
Status reporting and runtime telemetry both serve the same governance function: they make the state of execution visible before failure has to be reconstructed after the fact.
PM oversight and runtime control both sit between mandate and deliverable. Their purpose is not to replace the work, but to keep execution in active relation to the plan while the work is being produced.
The point is not that AI systems are employees or that project managers and runtime systems do the same thing. The point is that serious execution requires an intermediate governance function. There has to be something between mandate and deliverable.
Why agentic workflows make this unavoidable
For simple tasks, a prompt may be enough. If the user asks for a short paragraph, a translation, or a brainstorming list, final review may be sufficient. The cost of drift is limited because the task is short and the stakes are low.
But enterprise AI is not moving toward isolated short answers. It is moving toward workflows. The system does not just write a paragraph; it gathers information, applies policy, makes recommendations, updates systems, and initiates downstream action.
That is where prompt engineering reaches its limit.
In the vendor-selection workflow, softening a certification requirement is not merely imprecise writing. It changes the decision boundary. Treating a missing control attestation as “not disclosed” rather than disqualifying changes the governance outcome. Adding vendors outside the approved source universe changes the scope of the assignment.
The same pattern appears in adjacent workflows. An underwriting assistant that treats an exclusion as a preference is altering risk appetite. A compliance workflow that converts a binding escalation trigger into a general caution is changing governance. These are not merely output problems. They are mandate problems.
They are also not always visible in the final output. A polished recommendation can hide the fact that the system left the approved source universe in step four, relaxed an exclusion criterion in step seven, and treated an unresolved risk as immaterial in step eleven. By the time the final answer appears, the problem is no longer a sentence. It is a trajectory.
This is why agentic AI needs project governance, not just better prompts.
The system needs a mandate. It needs scope. It needs acceptance criteria. It needs escalation rules. It needs evidence obligations. It needs process visibility. And when it begins to drift, the organization needs to know before the drift becomes the new plan.
The missing layer
This is the context in which Assiduity’s work sits.
If AI drift is scope creep at machine speed, then the missing layer is not simply better prompting. It is runtime control: infrastructure that keeps generative behavior attached to the governing objective while work unfolds.
That does not eliminate the need for good prompts, policies, retrieval, fine-tuning, guardrails, or human review. Project management does not eliminate the need for a good project plan. It makes the plan operational during execution.
The same is true for enterprise AI. The plan cannot remain a passive document in the prompt window. The mandate has to remain active while the system works.
This is especially important in regulated, multi-step, high-consequence settings. The enterprise question is not only whether an AI system can produce a useful output. It is whether the organization can show that the work stayed inside the mandate that made the output legitimate.
In human organizations, that is why project managers exist.
In agentic AI, that is why runtime control becomes necessary.
Prompt engineering was the craft of asking. Agentic project governance is the discipline of keeping execution answerable to purpose.
Series note: This article is part of AI Drift Is Scope Creep, a three-part follow-on to Losing the Thread. The series argues that agentic AI turns prompt engineering into a project-governance problem: once AI systems begin executing multi-step work, organizations need mandates, contracts, runtime controls, and process evidence showing whether execution stayed attached to purpose. Assiduity is building the runtime control layer for that execution-to-mandate gap.