Chapter 14. Configuration Management When Agents Commit

Learning objectives

After this chapter you should be able to:

Define configuration item, baseline and the four activities of configuration management (CM), and apply them to a small project.
State the load-bearing assumption and its two halves, apply the negation test, and separate generation-process configuration, delivered-product configuration, causal provenance and human approval.
Summarize the evidence that behavior depends on items a repository does not hold, separating measurement from projection.
Build an expanded baseline manifest, a provenance trailer block and a change policy.
Run a recertification after a model change, with a pass rule stated before the run.
Audit a handed-off project's configuration and name the missing item that cost the inheritor the most time.

Opening case

A composite case, not a real engagement.

Dispatch has been live for five months. The consultant who built it left two engineers, Marcus and Aiko, to maintain it with coding agents. Customer service reports a defect: when a dispatcher reassigns a delivery, customers get a delay text fifteen minutes before the new arrival time is confirmed, then a second, contradictory text.

The chapter continues from here.

What the chapter covers

14.1 The classical method
- 14.1.1 What configuration management is for
- 14.1.2 Identification, version control and change control
- 14.1.3 Status accounting and audit
- 14.1.4 Continuous integration, builds and bills of materials
- 14.1.5 A worked example: Dispatch before agents
- 14.1.6 What it got right, and what teams do instead
14.2 The assumption it depends on
14.3 What agents change
- 14.3.1 Behavior depends on more than the source
- 14.3.2 Changes at volume
- 14.3.3 Who produced the change, and who answers for it
- 14.3.4 Convention files, permissions and recertification
14.4 The verdict
14.5 What replaces it: the expanded baseline
- 14.5.1 The expanded baseline
- 14.5.2 Provenance on every change
- 14.5.3 Policy as code, and humans merge
- 14.5.4 Recertification
- 14.5.5 Worked example: a model upgrade mid-project
- 14.5.6 The handoff package as a configuration audit
14.6 Lab: Put the agents under configuration control
14.7 What would make this verdict false

Lab and prediction

Lab: Put the agents under configuration control

Feeds milestone M4 (package); M5 (handoff audit). How the labs fit the project

The lab tests this prediction from the working paper the book grows from (Smith 2026a):

P8 Fuller (more complete, not longer) convention files and decision records at handoff predict lower comprehension hours for the inheritor

This chapter's own prediction: Changing only the model version changes measured behavior on a project's eval suite.

A result that contradicts a prediction, honestly reported, is a result. You are graded on accurate records and reasoned interpretation, not on agreeing with the book.

Summary

Classical CM answers four questions through identification, control, status accounting and audit.
Load-bearing assumption: behavior is determined by versioned source, and the version history records how each change was produced. Four things need separate records: delivered-product configuration, generation-process configuration, causal provenance and human approval. Classical CM still fits the first.
Evidence: model behavior has changed under the same service name, and provider documentation says serving infrastructure can alter behavior under a fixed ID. No study measures incident rates from unversioned changes.
Verdict: breaks, because a hosted model is recordable, not restorable, and changes arrive without a commit. Accountability does not break: a named person who approves and ships a change answers for it, whoever typed it.
Replacement: an expanded baseline manifest, harness-written provenance trailers, a tiered change policy as code, human merge for anything that can change behavior, and recertification.
Prediction: changing only the model version changes measured behavior on the eval suite.

Key terms

Generation-process configuration: the model, harness, prompts, convention files, skills and permissions that steer the agent writing changes.
Delivered-product configuration: the code, tests, build configuration and lockfile that ship.
Causal provenance: the record tying a change to the mission and process configuration behind it.
Expanded baseline: a baseline that also lists generation-process configuration and eval results.Also used in 15
Recordable, not restorable: an item whose identifier you can note and whose change you can detect, but whose state you cannot recreate on demand.
Provenance trailer: a commit-message line recording model, mission, baseline, autonomy, evidence, director and approver.
DecisionBOM: Hassan's record of how a change was decided.
Protected path: a file agents may propose changes to but never merge.Also used in 13
Recertification: rerunning the qualification and eval suites after any change to an item that steers the agents.Also used in 16, 17
Configuration drift: configuration in use that differs from the recorded baseline.

Connections

Where this chapter and another point to each other most often.

Chapter 2: The Assumption Audit: A Method That Outlasts the Tools
Table 14.2 runs the negation test (Section 2.3).
Chapter 6: Cost and Schedule Estimation After COCOMO
Chapter 6 assumed γ = 2.0, so a 6,000-line system presents about 12,000 lines for review.
Chapter 9: Risk Management: Project Risk and Adversarial Risk
From Chapter 9: The rate is specific to model and prompt and will move with every release (Chapter 14), so treat it as a prior and replace it with a count from your own log.
Chapter 10: Design for Change, and for Agents
From Chapter 10: Unless the harness persists context or memory (Section 10.3.1), an agent begins each session without what the last one learned, and a persistent store the team cannot read or version is a hidden input (Chapter 14).
Chapter 12: Reviews: Inspecting Evidence, Not Diffs
A classical board giving each one six minutes, with three people present, spends 80 × 6 × 3 = 1,440 person-minutes, 24 hours, about 23% of the 105-hour agent-aware estimate (Chapter 6), all of it duplicating the review of Chapter 12.
Chapter 13: Testing, Evaluation, and Tests as Steering
Run the eval suite. The product-level properties of Chapter 13, same k, by running whole missions.
Chapter 15: Reliability of Nondeterministic Systems
Not audited here: the run-time behavior of a model that a product calls (Chapter 15), and an organization's accountability policy, which this chapter argues does not break.
Chapter 16: Roles and the Four Conditions for Assurance
Accountability follows approval and ownership of policy, so it needs approval records and a named policy owner, not an author field (Chapter 16, condition 4).
Chapter 17: Coordination Without Communication: The Bound and the Leak Test
From Chapter 17: Treat a score above the bound as a trigger to audit the rig, and separate what is proved, measured and conjectured. ## Opening case A composite case, not a real team. Marcus and Aiko maintain Dispatch (Chapter 14), an internal dashboard for a regional logistics company.
Chapter 18: Running the Whole Life Cycle: The Engineer as Manager of an Agent Team
Before changing anything, the inheritor makes five checks, the evidence for the first handoff-audit question (Section 18.4.4): could you rebuild the baseline from the package alone? 1.

See it on the map

14 Configuration Management When Agents Commit