Turn a correction into a better repeatable method.

Preserve the failure before fixing its wording

Save the input version, the actual output, and the correction that made the problem visible. Write a short factual observation such as “the allocation table counted a pending request as committed stock.” This is more useful than labeling the whole answer bad or asking the Agent to be more careful.

Distinguish the incorrect result from your diagnosis. The source might have changed after the task, the correct file might have been unavailable, or the instructions might have been ambiguous. Record what is known first. A failure note that jumps straight to a new rule can conceal the actual cause.

Find the component that owns the correction

An approved reservation amendment belongs in the Project’s current evidence. A rule that pending requests must remain distinct from approved commitments belongs in reusable behavior. A multi-step overlap calculation may fit a Skill. A missing operation may require a selected Tool or connection, but incorrect reasoning does not automatically justify broader access.

Check the files the Agent actually read and the assumptions behind its answer. If an old reservation snapshot was clearly marked current, fix that source organization before rewriting the whole role. Keep the Agent’s purpose stable while investigating. Several unrelated changes at once make it difficult to know what solved the problem.

Write a rule that describes an observable decision

Replace “avoid overbooking” with “sum only approved reservations whose time intervals overlap, show the arithmetic against serviceable stock, and list pending demand separately.” Name the evidence needed, the output behavior, and the condition that should trigger a question. This gives both the Agent and reviewer something concrete to use.

Do not paste a team’s entire correction thread into a role intended for other Projects. Extract the general decision rule and leave confidential or changing facts with their work. Review the resulting instructions for contradictions. Adding a second rule that disagrees with the first leaves the next task with the same unresolved choice.

Replay the failure and an earlier success

Run the unchanged example that exposed the error. Open the new saved result and check whether the exact failure is gone. Then rerun a previous normal case. The new rule should preserve correct behavior when the input has no conflict, rather than making every straightforward task stop unnecessarily.

Record observations with the file and source locations. For a correction to an existing report, inspect the summary, tables, next actions, and handoff for stale text. If the Agent fixed one occurrence but left another, refine the review step and test again. Changing the source packet midway makes that comparison less informative.

Save the reviewed setup with a useful history note

Save the Agent after checking the edited setup. Keep a brief note with the failure, changed component, tests run, remaining limits, and review date. Use Agent version history when an earlier setup needs to be restored. The note should explain the reason for a change without requiring someone to reconstruct every conversation.

Where learning proposals or saved evaluations are available, inspect their actual scope and evidence before applying a change. These controls are availability-dependent, and a completed trial is not universal proof. This guide’s manual method works with ordinary files and review notes; it does not assume that private conversations become permanent Agent training.

Keep improvements narrower than the next ambition

A corrected drafting role has earned another drafting trial. It has not automatically earned permission to email clients, change external records, or run unattended. Revisit access and the acceptance set when you expand the role. Keep the earlier tests so the next improvement can be checked against established behavior.

Look for patterns across failures without overfitting to one example. If several Projects need the same evidence rule, consider a shared method. If one client has an exception, keep it explicit in that Project. A maintained Agent stays understandable: a clear job, a small set of justified rules, and examples showing why those rules exist.

Try it with a small example.

Before you use the result.

• The failure observation is separate from its suspected cause.
• Source updates and reusable behavior changes are distinguished.
• The proposed rule has a visible expected behavior.
• The original failure and an earlier success were both retested.
• The saved version note records evidence and remaining limits.