What should the next agent remember from a completed change?

The second request leaves out the first promise

Illustrative two-task sequence. First, a team adds idempotent reservation retries. It approves a requirement to retain retry keys for 24 hours and records why: a client may retry after losing the original response. Later, a fresh agent receives a cost-reduction task: “Reduce storage used by the reservation cache.”

A 12-hour expiry looks reasonable if the agent sees only storage code and the latest request. The earlier requirement makes the conflict visible. The useful retained fact is the 24-hour promise and its authority, not that a previous agent once chose a particular cache implementation.

Requirement: SW-REQ-241, revision 2
Component: reservation_api
Promise: the same key and payload return the original reservation
  within 24 hours, without a second reservation.
Reason: clients may retry after a committed response is lost.
Authority: API owner; approval recorded for revision 2.
Related evidence: retry-after-timeout and conflicting-payload checks.
Evidence basis: code A, test T4, retention 24h, environment E2.
Remaining gap: concurrent requests across replicas not established.
Change history: record the chosen design and rejected alternatives.

The behavior has now been exercised locally

The public teaching fixture executes the 24-hour, 12-hour and repaired 24-hour configurations with the same implementation and expected cases. At 12 and 23 hours, the shorter retention creates a second reservation. The downloaded Git history and result files let the next person inspect that failure without reconstructing this explanation.

The requirement in this fixture is author-supplied and remains a draft; it is not the approved requirement from the hypothetical team sequence above. Proof ran the configured test command and produced real packages. The repair’s package remains not_assessed, with incomplete mapping and evidence disclosed.

The second-agent experiment is still unrun. The fixture executions establish observed behavior, and the scripted MCP probe below establishes a narrow retrieval result. Neither shows that a fresh agent independently found the requirement, preserved the promise or saved time. The evaluation procedure remains proposed.

What the local MCP probe actually retrieved

A scripted client opened revision C of the teaching fixture with proof mcp --transport stdio, initialized the session and listed its tools. Its first requirement query supplied only a behavior keyword:

{
  "name": "reqproof_query_requirements",
  "arguments": { "search": "retry" }
}

The server returned one record, SW-REQ-241, with its 24-hour description and draft status. The client used that returned ID to read the full requirement resource, including the rationale that a client may lose the first response. The initial query supplied no requirement ID or component.

These results matter to the proposed workflow. A matching keyword retrieved the draft; the task wording alone did not. The approved filter excluded the relevant draft conflict. No trace connected this record to the retention configuration. A later agent still needs to choose a useful search, inspect authority and establish the affected relationships.

The server also emitted a protocol error. It rejected notifications/initialized with -32601. The scripted client continued and completed the reads, but recorded the error and exited 1. Compatibility with a fresh agent’s client has not been established.

Read the actual request transcript, server responses and replay instructions and limits. This is executed local retrieval, not a measured improvement in agent behavior.

Test whether retrieval improves the next decision

In the hypothetical approved-requirement scenario above, evaluate whether the agent can take these steps. The actual teaching record remains a draft and requires its authority to be resolved.

1. State the conflict. Expiring keys after 12 hours would remove the data needed to honor the approved 24-hour retry promise.
2. Find an implementation within scope. Explore compression, a smaller record or a different storage tier while preserving the retention window.
3. Escalate an actual amendment. If the team wants a shorter window, identify affected clients and request authorization under the existing policy. The new prompt alone does not supersede the requirement.
4. Renew the relevant evidence. The old retry result identifies a useful check. It does not establish behavior for the new storage implementation.
5. Retain the second decision. Update the Change record with the chosen approach, renewed results and every material open issue.

For this example, a useful agent response would name the retained requirement, explain the expiry conflict, and propose a storage change that preserves it. That is a testable outcome for a pilot.

Measure whether the record saves work

Give a new agent session the second task without retelling the first discussion. Observe whether it retrieves the obligation before changing code, identifies the conflict, selects relevant checks and reports stale or missing evidence. Measure human correction and investigation time, including the effort spent creating the original record.

Proof provides the retrieval primitives shown here. This sequence is an evaluation procedure, not evidence that a customer has already achieved the described reuse or time saving.

Supplier handover is a separate exercise: it also requires export scope, access, runnable environments and a receiving owner. This guide concerns continuity between tasks inside a project.