Who Gets to Move the Goalposts?

How agentic systems can adapt without redefining success

An agent receives a customer's refund request. It checks the purchase, reads the policy, and prepares to refund the original charge. Halfway through the work, it discovers that the customer has already received a partial credit.

The original plan is now wrong. Following it would refund too much. The agent needs a new plan.

But what else may the agent change? Could it close the request, issue an unrequested voucher, or claim success after writing a recommendation without recording the refund?

Long-running agents need to adapt as they learn. A fixed plan leaves them following assumptions that new evidence has disproved. If every part of the plan can change, the agent can redefine success until its result appears correct.

An agentic system needs permission to change the plan. It must not have permission to redefine success.

That requires two layers: an end set by a person and held fixed for the run, then recorded decisions about how to reach it that the system may revise between increments.

The opening paper, When Nobody Is Watching, asked who owns purpose when the supervisor leaves. The next question is how to keep that purpose fixed while the system revises its plan.

Freeze the end, not the plan

During supervised work, a person can revise the calculation while keeping the original request in view. In agentic work, planning and execution happen inside the same loop. The plan can respond quickly to evidence. A decision that makes sense in the moment can also add scope, abandon a requirement, or change what counts as done before the next human review.

The refund request therefore needs a brief set by a person. The brief might require the system to:

• resolve an eligible request according to the stated refund policy, including previous refunds and credits;
• stay within a stated refund limit;
• offer no substitute benefit; and
• leave the account and transaction records accurate.

The run must satisfy this brief. The agent may change a faulty calculation or sequence. It may not ignore the previous credit, increase its refund limit, or substitute a different benefit.

The brief stays fixed until the run ends. Changing the policy, refund limit, or desired outcome requires a person to approve a new brief and start a new run. The active worker cannot rewrite the definition of success for its current work.

From product intent to buildable increments

I have been exploring this problem while building SuperDomestique. SuperDomestique provides the planning and governance needed for an autonomous delivery loop. Given a Product Requirements Document supplied by a person in a target repository, the loop can break it into decisions and build the software in increments.

The Product Requirements Document, or PRD, expresses the end set by a person: product outcomes, required conditions, exclusions, and what will count as success. A Product Requirements Decision Record, or PRDR, records one choice about how to reach that end.

PRDRs borrow the record-and-supersede pattern used for architecture decisions, but apply it to product choices.

A PRDR defines one increment with a clear boundary, such as a releasable feature, a product idea to test, a research task that answers a product question, or a migration stage. It records the context, decision, scope, exclusions, and definition of done. Delivery evidence may later show that its assumptions were wrong.

The same pattern repeats at each level. A PRDR is one means towards the PRD. It becomes the fixed end for the specifications and execution in that increment. The work it governs cannot rewrite it and still use it to judge its own success.

flowchart TD
    P["PRD supplied by a person<br/>end set for this run"]
    R1["PRDR 1<br/>chosen means"]
    S1["Buildable specifications"]
    X1["Increment"]
    E1{"Evaluation"}
    O1[("Recorded outcome")]
    Q{"Does the evidence<br/>change a product decision?"}
    R2["PRDR 2<br/>replacement means"]
    N["Next live PRDR"]
    S2["Buildable specifications"]
    X2["Next increment"]
    H["Human decision"]
    P2["Revised PRD<br/>new run"]

    P -->|bounds| R1
    R1 --> S1 --> X1 --> E1 --> O1 --> Q
    Q -->|no| N --> S2 --> X2
    Q -->|yes, within the PRD| R2 --> S2
    Q -->|would change the end| H --> P2
    P -->|bounds| N
    P -->|scope and coverage checks| R2
    R1 -. superseded by .-> R2

Keeping that end fixed lets the delivery loop break down, sequence, test, and revise the work without waiting for approval at every step.

Delivery evidence can change a product decision

Consider a passwordless sign-in feature. Its PRD requires passwordless access, one-time credentials, an accessible sign-in path, and account recovery.

The first PRDR selects email magic links for a staff pilot. Specifications turn that choice into buildable slices. The pilot tests that choice while the PRD remains incomplete.

Testing reveals that corporate link scanners consume some one-use links before the user opens them. This shows that magic links are the wrong choice while leaving the desired outcome intact. A replacement PRDR can select emailed one-time codes and retain the test result that explains why the earlier decision was replaced.

Engineering can establish that scanners consume the links. Product must decide whether one-time codes still satisfy the intended experience. The PRDR records that decision and its evidence without giving the delivery loop permission to change the PRD.

flowchart LR
    P["PRD<br/>passwordless access<br/>one-time credentials<br/>accessibility and recovery"]
    R1["PRDR 1<br/>product decision: magic-link pilot"]
    B1["Delivery work<br/>specify, build, and test"]
    F[("Engineering evidence<br/>link scanners consume links")]
    R2["PRDR 2<br/>product decision: one-time codes"]
    B2["Next specifications<br/>and increment"]

    P -->|bounds| R1 --> B1 --> F
    F -->|informs product| R2 --> B2
    P -->|still bounds| R2
    R1 -. superseded by .-> R2

Adding social sign-in would go beyond the PRD. Removing account recovery would drop a PRD condition. Calling the feature complete after the staff pilot would change what counts as done.

Check what the plan adds and drops

A new or replacement PRDR needs two product checks.

The scope check asks whether the increment advances the supplied PRD without adding an unauthorised capability. The coverage check asks whether every PRD goal still has at least one live PRDR after the change.

The checks catch opposite kinds of drift. Scope stops the system from adding new ends. Coverage stops it from dropping existing ones. Social sign-in fails the scope check. Removing the only recovery PRDR fails the coverage check.

Authority and timing matter too. The worker building an increment cannot replace the PRDR that will judge it. The planning loop above the worker may propose a replacement between increments. If the loop proposes replacing a decision made by a person, that person must approve or refuse it. If the same decision keeps changing, a configured limit returns it to a person.

flowchart TD
    N["New or replacement PRDR"] --> S{"Within the supplied PRD?"}
    S -->|no| R["Refuse"]
    S -->|yes| C{"Are all PRD goals still covered?"}
    C -->|no| H["Return to a person"]
    C -->|yes| A{"Who is changing what, and when?"}
    A -->|current worker replaces its own PRDR| W["Refuse<br/>the worker cannot move its own goalpost"]
    A -->|revision limit reached| H
    A -->|loop replaces a person's decision| Q["Ask that person to approve"]
    A -->|authorised planning loop| Y["Authorise for the next increment"]
    Q -->|approved| Y
    Q -->|refused| R

When one PRDR supersedes another, SuperDomestique links the two records and marks the earlier one as superseded. The earlier decision and its reasoning remain in the record. The product history shows what changed and why.

The same topology applies beyond software

Outside software, the decision record may have another name. The same boundary still applies: the goal remains fixed while the worker revises decisions about how to achieve it.

In the refund process, the request, policy, and refund limit define the end. Decisions about how to reach it divide the work into useful stages: rebuild the case history, determine eligibility and amount, then apply and reconcile the payment. A prior credit changes the amount without changing the end. An unrequested voucher goes beyond it. Dropping reconciliation abandons part of it.

Each completed stage creates a checkpoint: a rebuilt case history, a checked refund decision, and a reconciled payment. Each checkpoint makes partial work reportable, inspectable, and independently testable. A decision record says what the next stage should achieve. A checkpoint records what the stage established.

Coverage is not completion

Coverage means every PRD goal is assigned to at least one live PRDR. It shows that the plan accounts for every goal. It says nothing about delivery.

The passwordless plan may cover every PRD goal while account recovery still fails in the current build. Coverage describes the plan. Completion describes delivered and verified outcomes.

SuperDomestique treats the product as complete only when every PRD goal remains covered by a live PRDR and every live PRDR's definition of done has been verified against delivered work. The CLI records a verified outcome as met. No verdict means incomplete.

Passing these checks cannot tell us whether the product was worth building. A delivered increment may still be a poor use of time because the supplied PRD chose the wrong strategy or its definition of done measures the wrong outcome. The records preserve intent and revision history. People still own product purpose and business judgement.

What the implementation checks

The faff CLI includes commands to create, validate, and supersede PRDRs. faff prdr admit checks whether a new or replacement PRDR may govern the next increment. It returns admit, propose-only, or reject.

The command applies deterministic rules to facts supplied by its caller: who made the decision being replaced, whether the current worker is replacing its own governing PRDR, how often the same decision has been revised, and the scope and coverage verdicts. The command does not establish those facts itself.

faff prdr coverage checks whether every PRD goal remains covered and every live PRDR has a verified met verdict. A missing verdict remains incomplete.

These commands enforce the rules when they are called. The whole workflow is governed only if the orchestrator supplies trustworthy inputs, calls the checks at the right time, and obeys their results.

Keeping the end fixed lets a delivery system revise its plan without changing the meaning of success. Before delegating a long-running build, ask: Which goal was set outside the delivery loop? Who may revise the decisions about reaching it? What evidence must remain when one decision replaces another?

The next paper, Review the Work Without Watching the Worker, examines the checkpoints that make partial outcomes visible and testable during long-running work.

Implementation and evidence

• PRDR admission authority
• Coverage and completion
• PRD and PRDR commands
• Current evidence and claim status