Organizations can complete a project, resolve its problems, and still leave the next team to figure out many of the same things again.
The final deliverable may be documented. The decisions that led to it often are not. Why one integration was chosen over another, which assumptions turned out to be wrong, what failed during testing, or how anyone verified that the system worked can remain scattered across messages, tickets, files, and individual employees' memories.
That is a form of organizational loss. A project produces an outcome, but much of the knowledge acquired while producing it never becomes useful infrastructure for the work that follows.
The cost of relearning
This is not just an issue for software teams. Procurement, service operations, customer delivery, and internal process improvement all depend on decisions made under imperfect information. When those decisions cannot be reconstructed, the next team spends time rediscovering constraints that the organization has already encountered.
An April 2026 report from the U.S. Government Accountability Office found that four federal agencies it examined (the Departments of Defense, Homeland Security, and Veterans Affairs, and the General Services Administration) were not systematically collecting lessons learned from AI acquisitions. The report described missed opportunities to reuse practices involving contract terms, data rights, testing requirements, and procurement decisions. The finding was specific to the agencies reviewed, but the underlying problem is recognizable beyond government: experience is generated in one project without a reliable path into the next. [1]
Documentation helps, but documentation by itself does not guarantee that anyone will encounter the right lesson when it matters. A forgotten postmortem and a missing postmortem may produce the same result at the next decision point.
What actually accumulates?
Google's 2025 DORA research describes AI as an amplifier of existing organizational strengths and weaknesses. More capable tools do not, by themselves, repair unclear ownership, fragmented workflows, weak feedback, or poor engineering practices. The condition of the system around the tool shapes the outcome. [2]
That is consistent with a broader concept from economics. An August 2026 NBER working paper by Tania Babina, Alex X. He, and Renhao Jiang examines organization capital: durable, firm-specific knowledge acquired through learning-by-doing. The authors find an association between recent AI investment, accumulation of this capital, and productivity growth. Their results are not a demonstration that any particular company's internal knowledge system creates a measured return, but they provide a useful framework for thinking about where value may persist. [3]
A separate June 2026 NBER working paper by Andrew Caplin uses the term planning capital to describe the diagnostic understanding acquired through successive investments and inquiries. An investigation can change what a firm knows, which questions it can ask next, and how costly future discovery becomes. In that framework, a project can leave behind more than its immediate result: it can make the organization more capable of investigating the next problem. This is a theoretical framework, not a verified return-on-investment estimate for an individual implementation. [4]
The practical distinction is between retaining information and retaining capability.
A list of past incidents is information. A test that catches a previously observed failure before the next release is capability. A description of an authorization mistake is information. A permission boundary that prevents its recurrence is capability. A set of meeting notes is information. A decision record that clarifies a later trade-off can become capability when it is actually consulted and tested against new circumstances.
Even the research process illustrates the difference
There is a small example in how a publication gets developed. A new article does not need to begin with a blank page if earlier work has already established which sources were dependable, which claims required qualification, what the intended audience needs explained, and which writing choices worked poorly.
In preparing this piece, previous research on failure visibility informed the question, earlier editorial decisions helped establish the appropriate tone, and source review prevented us from treating a plausible thesis as a proven business outcome. A rejected direction was not erased; it remained distinguishable from the version that better fit the argument.
That is useful accumulated context. But it is not yet evidence of an autonomous learning system or quantified productivity savings. Editorial judgment, fresh verification, and deliberate selection were still required. The narrower point is that preserving prior decisions and the evidence behind them made it possible to refine the work without reconstructing the entire conversation from scratch.
The same principle matters much more when applied to recurring operational workflows, where the cost of relearning can include delays, duplicated effort, security exposure, and incorrect actions.
From lessons learned to usable controls
A reliable organization should be able to carry forward more than a folder of completed project documents. At minimum, subsequent work should be able to recover the original objective, the assumptions and evidence that informed decisions, the controls and tests that were accepted, the unresolved questions, and the outcomes observed after implementation.
Some of that can remain human-readable documentation. Some should become reusable templates, shared integrations, automated checks, escalation rules, or independently verifiable receipts. Not every historical observation deserves permanent enforcement; lessons can be wrong, context-specific, or obsolete. That is why provenance, review, versioning, and evidence of effectiveness matter.
DORA's platform-engineering guidance describes a related approach: shared tools and repeatable workflows should be treated as internal products, with usable pathways, clear feedback, and measurement of actual outcomes. It also warns that platform work can introduce its own friction when poorly designed. Reuse is not the same as adding bureaucracy. [5]
A sensible test of organizational learning is therefore operational, not rhetorical. Does the next project require fewer repeated investigations? Are known problems detected earlier? Is less time spent repairing familiar failures? Can another employee or team understand the choices that were made? Can the organization demonstrate that a reused control improved the result rather than simply adding another approval step?
The answers may differ across teams and projects. They should be measured, not assumed.
The advantage that survives the project
Models, vendors, employees, and software platforms will change. Some dependencies should be easy to replace; others will carry legitimate switching costs. Either way, an organization should not have to discard its accumulated understanding of its own operations every time the surrounding technology changes.
The more durable asset is the ability to preserve evidence, learn from actual outcomes, and translate useful lessons into practices that improve subsequent work.
A completed project should leave behind more than a deliverable. It should leave the organization better prepared to execute the next one.
Sources
- [1] U.S. GAO April 13, 2026, GAO-26-107859.
https://www.gao.gov/products/gao-26-107859 - [2] DORA / Google 2025 State of AI-assisted Software Development.
https://dora.dev/research/2025/dora-report/ - [3] Babina, He & Jiang, NBER Working Paper 35684, August 2026.
https://www.nber.org/papers/w35684 - [4] Caplin, NBER Working Paper 35349, June 2026.
https://www.nber.org/papers/w35349 - [5] DORA Platform Engineering, updated January 12, 2026.
https://dora.dev/capabilities/platform-engineering/