# Describe the failure: reports an agent can act on Turn 'it's wrong' into a seven-line report that an assistant or an agent can fix in one pass, and a rule for when to stop correcting and start fresh. Guides · v1.1 · draft · https://hayzlabs.com/guides/describe-the-failure/ In short: - Replace 'it is wrong' with seven lines: what you asked, expected and got, the evidence, a done check, your guess and what stays. - Put symptoms before theories and cut the failing input down to the smallest case that still fails. - If two corrections have not landed, paste the report and the original material into a fresh session. ## Short answer "That's wrong, try again" gives the assistant nothing to aim at, so it tends to produce another guess. A report it can act on says what you asked, what you expected, what happened, the evidence, and how you will check the fix. Write it as seven lines. If two corrections have not landed, paste the report into a fresh session instead of typing a third. The template and the habits are our suggestion. **Example (invented).** Beatriz asked an assistant to summarise a 12-page report for her manager. Point 3 of the summary says the survey reached 1,200 people. The table on page 4 says 120. ## The report, in seven lines ```text title="Failure report · v1.0" What I asked: What I expected: What happened: Evidence: Done when: My guess (it may be wrong): Do not: ``` Replace the following: - ``: the exact prompt or steps, and which files or pages were involved. Paste the prompt; do not paraphrase it. - ``: a specific value, format or behaviour, such as `a survey size of 120, as in Table 1`. - ``: the exact wrong output, with the wrong line quoted. - ``: the error message, the screenshot, the log lines or the source it should have used, with the page or location. - ``: a check someone can run, such as `every number in the summary matches a table, listed with its page`. - ``: your theory, if you have one, or `none`. - ``: what must stay as it is, such as `do not rewrite the other points`. ## Before and after For a quick correction, a sentence or two can do the report's job. | Before | After | |---|---| | "The summary is wrong." | "Point 3 says 1,200 people. Table 1 on page 4 says 120. Fix it, then check every other number against the tables and list each with its page." | | "The spreadsheet formula doesn't work." | "In cell F2 I used the formula you gave me, and it shows #REF!. Column C was deleted last week. Rewrite it for columns A and B only, and show the result for row 2 so I can compare it with 40.00." | | "The email sounds off." | "The second paragraph sounds like a complaint, and I wanted a request. Keep the facts, change that paragraph only, and keep it under 60 words." | | "It keeps getting the dates wrong." | "In the three rows below it wrote 2026-03-14 as 14 March 2025. I want ISO dates (YYYY-MM-DD) and the year taken from the invoice, never assumed." | ## Four habits - **Symptoms before theories.** Say what you saw before what you think caused it. A guess placed first can steer the assistant onto a cause you invented and away from the real one. Put it in the "my guess" line, labelled. - **Smallest case.** Cut the failing input down to the least that still fails: the one paragraph, the one row, the 20 lines around the error. - **A check it can run.** Without a "done when" line, "fixed" means whatever the assistant decides. Make it something you could check in a minute. - **Say what stays.** A fix to one thing can break others. A "do not" line costs a few words. ## Two strikes, then start fresh Anthropic's Claude Code guidance says to clear the context (wipe the conversation so far) and rewrite the prompt after two failed corrections ([Claude Code best practices](https://code.claude.com/docs/en/best-practices), vendor guidance). A chat holding two failed attempts is crowded with wrong turns, and the cheapest fix is a new session with a better report. > [!OUR RULE] > If two corrections have not landed, stop correcting. Write the seven lines, start a new chat or session, and paste them in with the original material. If the new session fails too, the problem may be the task or the tool and not the wording, so decide whether to take the work back (see [Checking agent work](https://hayzlabs.com/workflows/checking-agent-work/)). The same seven lines suit a note to a colleague, a message to support or a report to a tool's maker. Take out names, numbers and anything private first ([What not to paste](https://hayzlabs.com/start/what-not-to-paste/)). ## Limits > [!LIMIT] > The one source is vendor advice, not a measurement. Nothing here shows that a seven-line report fixes a failure faster than a short one. Some failures are not about wording at all: the model may not be able to do the task, or the material may be missing. If a clear report still fails, change the approach and not only the message. ## Try this next 1. Take the last correction you typed and rewrite it as the seven lines. (5 minutes) 2. For setting up an agent's job so it fails less, see [Long agent jobs](https://hayzlabs.com/workflows/long-agent-jobs/). ## Sources 1. Anthropic. Claude Code best practices, documentation. Vendor guidance. [Link](https://code.claude.com/docs/en/best-practices)