Resume an abandoned agent patch with a failing test, not a fresh prompt

An agent has changed a retry helper, left a short note about “finishing the defaults,” and stopped. The developer who started the task is unavailable. Another teammate can run the project, but the conversation alone does not establish what the patch actually does.

Instead of starting with “continue the previous agent's work,” give the next runner a small failing behavior to investigate. A reproducible boundary turns a vague recovery assignment into a task someone else can execute and a reviewer can assess.

Here is a deliberately small, hypothetical example. The function and input contract are invented for this tutorial; they are not taken from a production incident.

Establish the input contract first

Suppose an internal worker accepts a retry limit. The agreed contract is:

• None means use the default of three retries.
• Zero means do not retry.
• A positive integer is an explicit limit.
• Negative values, booleans, strings, and floats are invalid.

Those choices belong to the application owner. If zero might mean “unlimited” in the real service, settle that decision before implementing this example. An agent should not infer the contract from a convenient language idiom.

The partial patch contains:

def retry_limit(value):
    return value or 3

That looks compact, but it collapses two different inputs into one result. Both None and 0 return three. It also accepts values the contract rejects.

Turn the uncertainty into a reproduction

Create a scratch file, retry_example.py, with the function above and this check beneath it:

assert retry_limit(None) == 3
assert retry_limit(0) == 0, "zero must disable retries"
assert retry_limit(2) == 2

Run it with an approved local Python interpreter:

python3 retry_example.py

The zero assertion fails against the partial implementation. That is useful evidence about this function. It is not evidence that a deployed worker has retried a real job, nor that fixing this helper will repair every call site.

In a real repository, record the exact revision and runtime version beside the reproduction. Keep existing uncommitted changes intact. Use the project's normal isolated-work workflow before experimenting, especially when another person may resume their own branch later.

Prepare a handoff that names the next action

The recovery coordinator writes a record like this. Replace the bracketed fields with observed values, rather than copying an old agent's assurances.

task: preserve explicit zero in retry policy
prepared_by: [recovery coordinator]
source_revision: [full commit identifier]
state:
  available: partial retry helper and original requirement
  unavailable: original author's unsaved local work
  acceptance: pending
evidence:
  reproduction: retry_example.py
  observed: zero is converted to three
  integration_checks: not run
next_action:
  implement: validate the agreed input contract
  verify: default, zero, positive, and rejected input cases
boundaries:
  exclude: queue behavior changes, deployment, new dependencies
  stop_if: a caller relies on coercing strings or booleans
handoff:
  runner: [teammate with authorized repository and tool access]
  reviewer: [owner of retry behavior]
  return: revision, diff, test output, unresolved callers

The coordinator prepares the work. The runner uses their own approved tools and identity to inspect and change it. The reviewer decides whether the result satisfies the contract. A task brief transfers context; it does not transfer an account, credentials, or another person's tool allowance.

An AI work handoff needs these boundaries even when everyone uses the same coding assistant. Wagglet for startups describes routing prepared work to teammates or agents without sharing accounts. The concrete artifact being routed here is the reproduction plus its acceptance record, not an instruction to trust a previous conversation.

Make the smallest change the contract supports

One implementation for this specific contract is:

def retry_limit(value):
    if value is None:
        return 3
    if type(value) is not int or value < 0:
        raise ValueError("retry limit must be a non-negative integer")
    return value

The exact-type check is intentional: Python booleans behave as integers in several contexts, but this contract rejects them. A service that accepts integer subclasses would need a different validation decision.

Extend the reproduction with rejected inputs:

for invalid in (-1, True, False, "2", 2.0):
    try:
        retry_limit(invalid)
    except ValueError:
        pass
    else:
        raise AssertionError(f"unexpected acceptance: {invalid!r}")

These checks exercise the chosen function contract. The runner must still inspect callers: configuration parsing may already coerce inputs, or another component may treat zero differently. Finding such a dependency is a reason to report a scope decision, not silently broaden the patch.

Return a reviewable result

The final handoff should distinguish the failing baseline from the submitted change. Include the tested revision, exact command, result, and any checks that were not run. Do not describe a successful scratch reproduction as a passing repository test suite.

The reviewer can then ask a focused question: does the patch preserve the agreed retry semantics at the relevant boundary? They may accept the helper change while requiring integration evidence before deployment.

This process will not recover inaccessible edits or resolve missing product decisions. It gives the replacement runner a concrete starting point, and makes the remaining uncertainty visible to the person responsible for acceptance.