CLAUDE CODE AGENTS: ADVANCED ORCHESTRATION - Chapter 8, Exercise 2
What to Check Before Rewriting an Agent's Definition After One Failure
====================================================================================

QUESTION:
A coding agent produces incorrect code once, and a developer immediately
concludes the agent's definition needs to be rewritten. Using this
chapter's own material, explain what should be checked first before
reaching that conclusion.

SOLUTION / EXPLANATION:

This chapter is explicit on two points relevant here: first, that a single
anecdotal failure doesn't necessarily mean an agent's own definition is
broken - it could simply be one unusual edge case; second, that before
concluding an agent itself is unreliable, it's important to confirm what it
was actually working from was correct in the first place.

Before rewriting the agent's definition, the developer should check:

1. WAS THE BRIEF ACTUALLY GOOD? Following this chapter's own "brief vs.
   definition" distinction, the first thing to verify is whether the brief
   given to the coding agent was itself clear, complete, and unambiguous -
   per Fundamentals' own brief-writing standard. A vague or incomplete
   brief can cause a perfectly well-designed agent to produce a wrong
   result, and that's a problem with the brief, not the agent's own
   underlying definition.

2. WAS THE INPUT IT WORKED FROM CORRECT? If this coding agent was working
   from an earlier step's output (research findings, a plan), that input
   should be checked for correctness too - a coding agent implementing a
   flawed plan faithfully isn't itself at fault; it's a case of bad input
   propagating forward, exactly as Chapter 7 describes.

3. IS THIS A REPEATED PATTERN, OR ONE INCIDENT? Per this chapter's own
   warning box, one incident alone doesn't prove the agent's definition is
   the problem. The genuinely informative test is whether the SAME good
   brief, given again (or given to check a similar task), produces a
   correct result or repeatedly produces the same kind of wrong result.
   Only if the failure repeats with an already-good brief and correct
   input does it point toward the agent's own definition needing revision.

Jumping straight to rewriting the definition based on one incident skips
all three of these checks, and risks "fixing" something that was never
actually broken while leaving the real cause (a poor brief, bad input, or
simply an unusual one-off case) unaddressed.

--------------------------------------------------------------------------
WHY THIS WORKS AS AN ANSWER:
It lays out three specific things to check before blaming the agent's
definition (brief quality, input correctness, and whether the failure
repeats), each grounded directly in this chapter's own stated distinctions,
rather than treating "rewrite the definition" as an acceptable first
response to one incident.