Rework does not start when code breaks. It starts when one person's understanding of the work diverges from another person's understanding, and neither of them knows it yet.
Every organization that has ever shipped software has run into the same wall. A requirement gets written. It travels through two conversations, one meeting, and three Slack threads. By the time a developer acts on it, the original intent has degraded in ways nobody can trace. The output is technically correct and functionally wrong. The rework begins.
This is not a new problem. It is one of the oldest problems in organized human effort. What changes is the form of the receiver on the other end of the communication.
For most of software history, that receiver was another human being. Humans are remarkably good at filling gaps. When a requirement is ambiguous, a developer asks a question, makes an assumption, or draws on experience to navigate it. The system absorbs imprecision through the social fabric of the team. It is inefficient, but it works well enough.
Agile frameworks recognized that "well enough" was costing organizations enormous rework, misalignment, and lost time. The answer they reached for was structural: if informal communication degrades intent, formalize the moments of communication. Sprint Reviews exist to close the gap between what was built and what was wanted. Backlog Grooming exists to clarify intent before work begins. PI Planning exists to surface cross-team dependencies before they become mid-quarter collisions. PO Syncs keep business intent and delivery reality pointed in the same direction.
Every ceremony Agile introduced was an answer to the same question: how do we stop losing information between minds?
The artifacts followed the same logic. Product backlogs captured prioritized intent so it would not live only in a product manager's head. Definition of Done made completion criteria explicit so "done" meant the same thing to everyone. Architectural guidelines preserved design decisions so they could not be relitigated in every sprint. Each artifact was a vessel for information that could not afford to stay inside a single person. This architecture was thoughtful. It was also expensive. Large teams running Agile at scale can spend twenty to thirty percent of their capacity in coordination overhead. That is not a failure of Agile. That is the cost of transmitting intent across human minds at scale.
What Changes When the Receiver Is Not Human
The shift to AI-augmented delivery pipelines changes one variable in this equation fundamentally. The receiver on the other end of the communication is no longer another human being.
AI agents do not fill gaps with intuition. They do not draw on ten years of delivery experience to interpret an ambiguous acceptance criterion. They do not read the room in a refinement session and understand that the product manager's real concern is customer churn, not the feature description on the card.
The agent does not fill gaps with intuition. It fills them with its best statistical guess. That is not the same thing.
Consider a mid-size fintech company rolling out an AI coding agent to accelerate feature delivery. The team feeds it a backlog of user stories written in the same format they have used for years: functional, clear enough for a developer, silent on business rationale. The agent delivers. Velocity numbers improve. Six sprints in, the compliance team raises a flag: several features technically satisfy the written requirements but bypass a fraud detection rule that every experienced developer knew to check against, because they had been in the room when that rule was established three years ago. The agent had not been in that room. Nothing in the backlog referenced it. The rework costs more than four months of productivity gains. This is Implementation Drift: the system builds what was written, not what was meant. The agent did not fail. The context layer did.
Carnegie Mellon research places rework costs from poor requirements at 25 to 40 percent of total project budgets in human-driven teams. In agentic pipelines, that figure becomes a floor, because the agent's capacity to proceed confidently on an incomplete specification is significantly higher than a human developer's willingness to do the same.
The principle being violated is one of the most consistent warnings in the Entrowise principles library: Vague Guidance Creates False Alignment. When a human developer receives an ambiguous requirement, they ask, push back, or make a judgment call that gets reviewed in standup. When an agent receives an ambiguous requirement, it proceeds. The ambiguity becomes invisible until the output surfaces it.
The Context Layer Is Not Optional
A 2025 MIT research report found that 95 percent of enterprise generative AI pilots delivered no measurable business impact. The researchers did not blame the models. They identified the gap as contextual: agents operating without the organizational knowledge needed to make judgment calls that align with business intent. The models are capable. The context layer is missing.
This is where AI can do something that traditional stakeholder mapping never could at scale.
In human-driven delivery, a stakeholder map was a static artifact. A product manager would plot influence against interest, assign names to quadrants, and use the map to navigate conversations. It was useful, and it aged badly. By the time a project reached sprint ten, the map from the kickoff session bore little resemblance to the actual dynamics in play.
Stakeholder mapping was always a communication tool. The difference now is that the receiver reads documents, not body language.
An AI agent, fed with the documents your organization already produces, can synthesize a living stakeholder context layer from existing material. Fed your PRDs, it will surface where requirements conflict or carry assumptions without stated rationale. Fed your meeting summaries and Slack threads, it will identify which stakeholders have consistently introduced late-stage objections and on what grounds. In the fintech scenario above, the fraud detection rule had been discussed in a compliance review meeting two years prior. That meeting summary existed in Confluence. The decision rationale was in a Slack thread that three senior engineers remembered but nobody had linked to the backlog. An agent with access to that layer would have flagged the gap before the first sprint began.
The output is not a power-interest grid. It is a context document: who cares about what, why particular decisions were made, which constraints are regulatory versus organizational preference, and where the historical fault lines between business intent and delivery execution have appeared before. That is what an AI coding agent can actually use.
GitHub's engineering team made this point directly when they released their Spec Kit framework in late 2025: "We're moving from 'code is the source of truth' to intent is the source of truth." For that to be true in practice, the specification has to carry the full weight of organizational intent, not just a functional description of the feature.
Three questions worth asking your team now. If your AI agents were the only receivers of your current PRDs, what would they build, and how different would that be from what you actually want? Does your stakeholder map exist as a structured, queryable document, or does it live in the memory of senior people who have been around long enough to know the history? When a decision was reversed mid-project in the last twelve months, was the reasoning written down anywhere an agent could find it?
If the honest answer to any of those is no, the context layer is not yet built. The agent will proceed anyway.
If you want a structured way to assess where your delivery system's communication gaps are most exposed before AI agents make them visible in the worst way, the Entrowise diagnostic is a good place to start.