G.3 Learning from Delegated Work
No initial environment will capture everything that matters. Early agents will misunderstand local conventions, cross boundaries that were obvious to experienced engineers, satisfy tests while violating an unstated requirement, or produce results that expose weaknesses in the tests themselves. Human reviewers will continue to catch important problems. These interventions are useful not only because they repair the immediate work, but because they reveal where the environment failed to carry knowledge or enforcement that the work required.
The first response to a failure is often local: correct the artifact and continue. Sometimes that is enough. A one-off misunderstanding does not justify a new model, validator, or organizational rule. Repeated failures deserve a different diagnosis. If several work units reconstruct the same architectural fact incorrectly, the problem may be missing representation. If an obligation is repeatedly stated but violated, the environment may lack enforcement. If a validator reports success while reviewers consistently reject the result, the evaluator may not measure the property the organization actually cares about. If an agent cannot determine which rule applies, the relevant knowledge may exist but be unavailable at the point of reasoning.
Governance conversion is the process of turning such recurring discoveries into changes to the engineered environment. A correction may become a model entry, invariant, schema constraint, test, validator, permission rule, measurement, operating procedure, or reusable skill. The choice depends on the failure. The objective is not to mechanize every review comment, but to stop paying repeatedly for engineering knowledge that the organization has already acquired. When the same judgment is likely to recur and can be represented usefully, later work should inherit it. This is the governance-conversion loop developed in Section 3.4 (Figure G.2-2), read here at organizational scale: delegated work produces evidence and failures, diagnosis identifies what the environment was missing, a representation or enforcement change encodes it, and later delegated work inherits the result.
This is where adoption begins to compound. A conventional productivity rollout asks whether the next model, prompt, or tool lets a worker complete today's task faster. Governance conversion asks whether today's work leaves the environment better prepared for tomorrow's. The distinction is important because model capability is externally supplied and will continue to change. An organization that depends mainly on prompting skill must repeatedly reconstruct its local practices around each new tool. An organization that has encoded consequential knowledge, evidence, and enforcement into durable engineering structures can expose those structures to new reasoners as they arrive.
The resulting assets also have different lifetimes. A test tied closely to one implementation may depreciate during a rewrite. An architectural boundary, ownership rule, accessibility obligation, provenance requirement, or deployment invariant may survive several implementations. Some assets can be shared across a product; others remain local to one component or workflow. Adoption therefore creates an ordinary maintenance problem: engineering capital has carrying cost, can become stale, and must remain connected to the reality it claims to describe. More machinery is not automatically better. Models that no longer answer useful questions and controls whose expected benefit no longer exceeds their cost should be revised or retired.
The DocAble case illustrates the scale this supporting environment can reach without establishing a general target. At the final measured snapshot, approximately 491,000 lines of production source were accompanied by about 1.50 million lines classified as support apparatus, a ratio of 3.06 to 1; the ratio had been higher during the preceding hardening period. Those counts include models, tests, validation, control machinery, and related support code, and are tabulated in the evidence ledger (Appendix I). They describe one repository under unusually intensive agentic development, not an optimal ratio for other organizations. The useful observation is structural: as autonomous realization expanded beyond what one engineer could inspect conventionally, substantial engineering effort accumulated in the environment used to understand, constrain, and evaluate that realization. Part V records the same shift in where engineering judgment went.