skip to content

Your agent retried deliveries the receiver had permanently refused — what do you add to the request?

level: middleimportance: must knowfreq 56%

answer

  1. The result is evidence about the request
  2. Which word carried the distinction?
  3. Add a fact, not emphasis
  4. Name the wrong behaviour as a non-goal

basics

~20 s

Add the fact that tells the two cases apart — a refusal the receiver would repeat is not retried, a silence is — and name the wrong behaviour as an explicit non-goal. Emphasis carries no information; a fact does.

solid answer

~50 s

A confidently wrong result is evidence about my request, so I go back and find the sentence that permitted it. "Retry failed deliveries" covered a refusal and a silence alike, and the run picked the wider reading. Then I add three things, in order of how much work they do. The distinguishing rule: the fact the two cases differ on. The wrong behaviour as an explicit non-goal, because a negative is checkable and this run has just proved I need it. And the acceptance I would hold the diff against. What I do not do is restate the goal with more force — "be careful to retry only when appropriate" adds a word whose meaning was exactly what was ambiguous. If added facts change nothing, the ambiguity is probably not in the sentence I keep editing.

code

text · 16 lines
text
FIRST REQUEST
  Retry failed deliveries from the webhook sender.

WHAT CAME BACK
  Every failure retried, including payloads the receiver had rejected as malformed.

THE LOUD REWRITE - adds no fact, leaves the same decision open
  Please be careful to retry only when it is genuinely appropriate.

THE TIGHTENED REQUEST - adds the fact that tells the cases apart
  Retry a delivery only where a later attempt could succeed: no answer at
  all, a dropped connection, or the receiver saying it is overloaded. Never
  retry a delivery the receiver rejected as malformed - the same payload
  will be rejected again for the same reason.
  Worked case: delivery 4417, rejected as malformed, gets one attempt and
  no retry, and is recorded where an operator will find it.

go deeper

for a junior

Resist repeating yourself louder. Say exactly which behaviour was wrong, then add the one fact that separates it from the behaviour you wanted, and check that fact could be held against the result.

for a middle

Explain why emphasis fails: the ambiguous word stays ambiguous however firmly it is delivered. Show the diagnosis — name the behaviour, find the words that permitted it, add the fact that excludes them — and why a negative is easy to check.

for a senior

Show you treat a wrong result as information about your own request. Talk about the counter-example as a cheaper instrument than a rule, and about knowing when added facts are landing on the wrong sentence entirely.

for a principal

Own the case where no wording helps: the team has not actually decided which failures are worth retrying, and the request is being asked to carry a decision nobody made. Settling that is the work, not rephrasing.

## A confidently wrong result is evidence about your request The run did not malfunction. It read *retry failed deliveries from the webhook sender*, found that "failed" covered both a delivery the receiver rejected as malformed and a delivery that got no answer at all, and treated them the same way. The output is wrong about the parcel-tracking service and faithful to the sentence. **That makes the result diagnostic**: it tells you which of your words was load-bearing and which was doing less than you thought. The instinct is to describe the goal again, with more conviction. That is the move least likely to help, and it is worth being precise about why. ## Find the sentence that admitted the reading Before adding anything: 1. **Name the behaviour you got, exactly** — "it re-sent a payload the receiver had rejected as malformed", not "it did retries wrong". 2. **Find the words that permit it.** Usually one noun or adjective is carrying a distinction it cannot carry: *failed*, *invalid*, *safely*, *appropriate*, *robust*. 3. **Ask what fact would have excluded it.** Whatever answers that question is the line you add. If nothing does, the problem is not in this sentence. ## What to add, and what each addition does | the addition | why it discriminates | how it reads | |---|---|---| | the distinguishing rule | names the fact the two cases differ on | "retry only where a later attempt could succeed; a malformed payload will be rejected again" | | an explicit non-goal | a negative is checkable against the diff | "never retry a delivery the receiver rejected as malformed" | | a counter-example | shows the case rather than describing it | "delivery 4417 was rejected as malformed: one attempt, no retry" | | observable acceptance | gives the run something to finish against | "no payload rejected as malformed appears twice in the delivery log" | | more emphasis | nothing at all | "be careful to retry only when appropriate" | The last row is in the table on purpose. **"Appropriate" was the ambiguous word**; wrapping it in "be careful" and "only" leaves the run with the same decision it already got wrong, plus a stronger impression that you care about it. Emphasis raises the priority of a distinction it does not draw. ## Why the negative is worth writing down Requests are usually all positives — do this, produce that — and a positive statement is satisfied by anything that includes it. "Retry transient failures" is satisfied by a policy that also retries permanent ones. An explicit non-goal closes that door, and it has a second virtue: **it is checkable**. You can hold "never retry a payload rejected as malformed" against a diff and get an answer, which is not true of "handle failures sensibly". The counter-example does the same job in a different register. One concrete case — this delivery, rejected for this reason, gets exactly one attempt — often lands where a rule does not, because it removes the need to interpret a category boundary at all. ## Where the added fact belongs Put it in the request, not only in the next message. Whether you carry on from here or start the work again is a separate call; either way, the rest of the run is measured against the intent as it now stands, and a fact that lives only in one passing correction is a fact the later turns were not graded on. ## The limit of this move, honestly Adding facts works when the ambiguity is in the words. Two rounds of adding facts that change nothing is not a reason to add a third: it usually means you are editing a sentence that was never the problem, or that the goal itself is not yet statable — you do not actually know which failures are worth retrying, and no wording can supply a decision you have not made. That is a different problem with a different fix: settle the decision, then write it down. Two signs you are editing the wrong sentence: - **the corrections keep landing on a part that is already precise**, while the surprising behaviour moves somewhere new each round; - **you cannot state the fact that would exclude the wrong behaviour**, because nobody has decided it yet. ## What a good answer sounds like Quote your own sentence back and show the two readings it allowed. Then give the specific line you would add, and say what it makes checkable. An answer that stops at "I would be more specific" has not said what about, which is the entire content of the question.

  • Why is an explicit non-goal worth a line when you have already stated the goal?
    Because a positive statement is satisfied by anything that includes it: "retry transient failures" is satisfied by a policy that retries everything. A negative excludes, and it is checkable — you can hold "never retry a payload rejected as malformed" against the diff and get a yes or no.
  • The second attempt is wrong in a new way. What does that tell you?
    That the fact you added landed, and a different sentence is now the loose one. Repeat the diagnosis on the new behaviour rather than re-editing the line you just fixed — the risk at this point is piling emphasis onto the part you have already made precise.
  • Does any of this change if the wrong behaviour was caught by a failing check rather than by you reading it?
    The repair to the request is the same: find the words that allowed the behaviour and add the fact that excludes them. How an automated signal is fed back to steer a run mid-flight is a separate subject; this one is about what the request should have said.

saying these in an interview costs you the question

  • Repeat the goal more firmly and it will comply next time
  • A wrong first result means the model cannot do this task
  • Only say what you want; naming the wrong behaviour confuses it
  • Whether the first draft lands is luck, not what the request said
  • Once a run has started, the original request has done its job