The gap between what was intended and what was built is rarely the result of unclear writing. It is almost always the result of clear writing that stopped being consulted.
Every requirement document is a bet. The bet is that the understanding a person holds at the moment of writing can survive the handoff to whoever builds the thing. For three decades, software teams have been redesigning that bet. The form changed repeatedly. The underlying problem did not.
Business Requirements Documents placed the entire bet upfront. Exhaustive, locked, expensive when wrong. Agile's response was deliberate thinness: Epics and User Stories kept specs sparse and relied on ongoing conversation to fill the gaps.
What held intent together was not the writing. It was the relationship between the people doing the work.
The agentic era broke that relationship. An AI agent cannot pull a product manager aside to clarify what was meant. It cannot carry the institutional memory of why a previous approach was abandoned. It has what it is given. If what it is given is incomplete, it fills the gaps, confidently and silently. This is what drove Spec-Driven Development, and later Intent-Driven Development. Both addressed real problems. Neither solved what is now breaking inside agentic delivery pipelines.
The Specification That Becomes a Historical Artifact
Spec-Driven Development asks teams to write a precise, structured specification before handing work to an agent. The insight is correct: an agent without clear rules is not a collaborator, it is a guesser operating at machine speed. SDD disciplines the handoff. For the initial build, it works.
The blind spot is what happens after.
SDD produces a specification document. That document exists outside the agent. The agent does not carry it continuously. When a new session starts, a new pipeline runs, or an engineer makes a change six months into delivery, the question becomes: was the specification consulted? In practice, after the initial build, the answer is increasingly no.
The spec becomes a historical artifact, not a governing one. The rules it contains stop traveling with the decisions being made.
Consider a company that builds an AI-assisted customer support pipeline. At the outset, the team documents a clear rule: the agent must always check the live pricing database before referencing any price in a customer conversation. The rule is in the specification. It is correct. Everyone agrees with it.
Eighteen months later, a performance engineer optimizes a slow database call by switching to a cached pricing lookup. The change is scoped, reasonable, and solves the problem it was introduced to solve. The agent inherits the cached lookup. Nobody flags the substitution because nobody consulted the original specification when making the optimization. The rule that said "always check live pricing" was not in the room when the decision was made.
The agent continues operating. Tickets resolve. Satisfaction scores hold. Months pass before a pricing discrepancy surfaces and the team traces it back to a caching change that had long since become invisible in the delivery history.
This is Implementation Drift. The intent was never wrong. The original rules were never questioned. The system drifted away from them, one plausible substitution at a time, across months of normal delivery. The principle being violated is precise: Traceability Must Be Designed In, Not Added After. The rules existed. They simply stopped traveling with the decisions.
SDD did not prevent this. It could not. SDD governs the initial handoff. It has no mechanism that ensures the specification is present and active when subsequent decisions are made, by agents across sessions, by engineers across months, or by pipelines across deployment cycles.
The Intent That Stops Reflecting Reality
Intent-Driven Development goes one layer deeper. Rather than specifying how to build, IDD asks teams to first articulate the outcome they are trying to achieve. "Convert leads most likely to become long-term customers" rather than "prioritize companies under 200 employees." An outcome statement is more durable than a rule because it can flex as context shifts. This is IDD's genuine contribution to agentic delivery.
The blind spot is different, and equally consequential.
IDD does not tell you when the outcome itself is no longer the right outcome.
Consider the same company, now running a lead qualification agent. When the agent was configured, the company was a startup targeting small and mid-sized businesses. The intent was clear: qualify leads efficiently, move fast, keep the process lightweight. The agent was given an outcome to pursue and pursued it faithfully.
Eight months later, the company shifted strategy. Enterprise customers became the focus. The sales team knew. Marketing knew. Leadership had made the call in a board meeting. Nobody updated the agent.
The agent continued qualifying leads against its original intent: deprioritizing enterprise accounts because they were too large for the profile it was optimizing for, and fast-tracking smaller accounts that the sales team no longer had appetite to pursue. It was performing flawlessly. The intent it was given was simply no longer the right intent.
This is Intent Drift. The execution was faithful. The agent did exactly what it was told, consistently and correctly, across months of changed business reality. The failure was not in the agent's behavior. It was in the absence of any mechanism to ask whether the governing intent still reflected what the business actually needed.
The principles violated here operate at a strategic level. Commitment to Outcome Intent requires accountability not to the instructions that were written but to the outcome that was meant. Embrace Change requires that new information, including a strategic shift, be treated as a legitimate input to what the system is being asked to do. Empiricism requires that what the business learns about its direction changes what its delivery systems pursue.
IDD did not prevent this. It could not. IDD disciplines how intent is expressed at a point in time. It has no built-in cadence for revisiting whether that intent still holds when the business reality around it keeps moving.
The Gap Neither Methodology Addresses
These are two distinct failure modes, and the distinction matters for leaders designing agentic pipelines.
In Implementation Drift, the intent is still right. The execution drifted away from it because the governing rules were absent from subsequent decisions.
In Intent Drift, the execution is still faithful. The intent became wrong because the business moved on and nobody updated what the agents were told to pursue.
SDD was built to solve Implementation Drift. It addresses the handoff, not the months that follow. IDD was built to solve Intent Drift. It addresses clarity at the moment of intent-setting, not the ongoing validity of that intent as business reality shifts.
A team can practice both methodologies with genuine discipline and still be exposed to both failure modes, because both conditions develop in the space between handoffs, across the delivery cycles, strategic pivots, and quiet optimizations that no specification or intent document automatically tracks.
This is what the PPA Method surfaces when applied to agentic delivery systems: both drift conditions are governance failures, not methodology failures. The Unintended System Conditions they produce are predictable and diagnosable before they become visible through failed outcomes. The question the PPA Method asks is not which tool the team failed to use. It is what governance structure would have caught the drift while there was still time to correct it.
For Implementation Drift, the answer is a mechanism that keeps governing rules present and active across every session, pipeline boundary, and engineering decision, not just the first one. For Intent Drift, the answer is a review cadence with explicit accountability for asking, at regular intervals, whether the intent given to agents still reflects what the business actually needs.
Neither answer is a document. Both require someone to own the question.
If you want to find out whether Implementation Drift or Intent Drift is already active in your agentic delivery system, the Entrowise Guided Diagnostic is designed to surface exactly that, or bring the question directly to the AI Coaching Agent.