Updating a procedure after a workaround

Anthropic's September data on Claude Code sessions says context per request grew 2.6 times between March and September 2026, and agents are working longer with fewer interruptions. So if a procedure is out of date, an agent can follow the old workaround a long way before anyone notices. When someone has to work around a step to get the job done, I want that step recorded while they still remember the details, so the next person (or agent) knows what to do when they hit the same point.

Take a data import as an example. The instructions say upload the file and check for the completed status. The file's accepted, but some records are rejected, so someone finds the rejection report, fixes those rows and uploads them again. The work's done, but what goes in the procedure? Repeating the whole upload could mess with records that were already accepted. I'd ask the person for a short note on the procedure: the step they were on, what they expected, what they got instead, what they did and how they checked it. They shouldn't have to rewrite the document while they're still sorting out the problem.

Then I'd review the workaround before it goes into the normal instructions. It might rely on an admin's access, or a temporary change that has to be undone, or it might only have worked because that file had no duplicate IDs. "This worked for me" is useful, but I'd still want someone to say when it's safe to repeat. The change itself is usually small. For the import, that's where to find rejected rows, how to tell them apart from accepted ones, which file to use for the retry, and the expected result next to the step. If a retry can create duplicates, add a check against the destination before anyone uploads again.

AWS's guidance on runbooks covers the same practical stuff: the outcome you want, the tools and permissions needed, error handling, an owner, and having another team member validate it. That works for an ordinary office procedure too. Keep it in one place people can find, though. An emailed correction helps whoever got it today, but the link in next month's task will still open the old version, so update the linked document, keep the revision history and tell people which step changed. If the process needs approval, leave the change as a draft until the right person signs off.

I'd test the revised steps with someone who wasn't involved in the workaround, on a safe test case, without filling in the gaps for them out loud. If they have to ask which account to use or where the report lives, that detail goes in the document right where they got stuck. It's the same when an agent reads the procedure: give it the current approved version and the actual scope of the task, and keep old incident notes clearly marked as history, because a retrieved paragraph about a past workaround shouldn't quietly authorise the agent to repeat it on a different set of records. If parts of it get automated later, the workflow recovery guide has a way to document the manual recovery cases that are left.

Back to the import where someone fixed the rejected rows and uploaded them again: that workaround only helps the next person once it's in the approved procedure, along with the checks that make it safe to repeat. So I'd get the short note while the details are fresh, review it, update the linked document and test it with someone who wasn't there. Then the next person, or an agent working through a long session, reaches that step and finds the current instructions instead of the old workaround.