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.

Retrieve the requirement through MCP

Proof's MCP interface exposes requirement queries and trace traversal. The calls below use registered tool names and arguments; the component and requirement refer to the illustrative project above. These are tools/call parameters, not a transcript of a completed run.

{
  "name": "reqproof_query_requirements",
  "arguments": {
    "component": "reservation_api",
    "status": "approved"
  }
}

Read the matching requirements and their sources. Querying by component is useful here because the new task never uses the word “retry.” For a relevant requirement, inspect its recorded relationships:

{
  "name": "reqproof_trace_analysis",
  "arguments": {
    "id": "SW-REQ-241",
    "direction": "both",
    "depth": 2
  }
}

Traversal follows recorded trace links. It cannot find an obligation that was never recorded or a dependency that was never linked. Inspect relevant draft conflicts and linked artifacts too; the approved-status filter is a starting view, not an exhaustive investigation.

Turn retrieval into a better decision

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.