Blog
Updating a procedure after a workaround
Coding agents are running for longer and reading more context before they return. That makes the current procedure more important because an agent can follow an old workaround much further before anyone notices.

Anthropic's September data on Claude Code sessions says context per request grew 2.6 times between March and September 2026, while agents worked longer with fewer interruptions. That makes the current procedure more important. An agent can follow an old workaround much further before anyone notices. When someone has to work around a procedure to finish the job, I want the failed step recorded while the details are still available. The next person, or agent, needs to know what to do when they reach the same point. Take a routine data import as an example. The instructions say to upload a file and check the completed status. The file is accepted, but some records are rejected. A team member finds the rejection report, fixes the affected rows and uploads them again. The immediate work may be finished. There is still a question about what belongs in the procedure, because repeating the whole upload could affect records that were already accepted.
I would ask the person to note the step they reached, the result they expected and what appeared instead. Add the action they took and how they checked it. A short note attached to the procedure is enough to start with. They shouldn't have to rewrite the document while they are still dealing with the problem. Then review the workaround before adding it to the normal instructions. It may depend on an administrator's access, or on a temporary change that needs to be removed afterwards. It might have succeeded only because the particular file had no duplicate identifiers. Those conditions belong in the review. "This worked for me" is useful information, but I would still want someone to explain when the same action is safe to repeat. The amendment can usually be quite small. In the import example, it might explain where to find rejected rows, how to distinguish them from accepted rows, and which file should be used for the retry. Add the expected result beside the step. If the retry can create duplicates, the instructions need a check against the destination before another upload is attempted.
AWS's guidance on runbooks covers the same practical details: the desired outcome, required tools and permissions, error handling, an owner, and validation by another team member. Those are useful requirements for an ordinary office procedure too. Someone following it should be able to tell whether they have the access to perform it and what to do if the result is different. Keep the procedure in one place that people can find. An emailed correction helps the recipient today, but the link in next month's task may still open the old instructions. Update that linked document, retain its revision history, and tell the people who use it which step changed. Where a process requires approval, keep the amendment as a draft until the responsible person has approved it.
I'd test the revised steps with someone who wasn't involved in the workaround. Use a safe test case and let them follow the document without filling in the gaps verbally. If they have to ask which account to use or where the report is stored, add that detail where they needed it. The author being able to complete the task doesn't tell you whether the instructions are sufficient for someone else. The same check applies when an agent reads the procedure. Give it the current approved version and the task's actual scope. An old incident note may describe a temporary exception, so it needs to remain recognisable as history. A retrieved paragraph about a previous workaround should not silently authorise the agent to repeat it on a different set of records.
If the procedure becomes partly automated, update the human steps at the same time. Show what the automation now handles, what still needs checking and where someone can see unresolved work. Keep manual recovery instructions for the cases that still require them, including who is allowed to use them. The workflow recovery guide includes a way to document those cases without making every operator reconstruct the original failure. For the next procedure amendment, ask the reviewer to record which revision they tested and any questions they had to ask. Put the answers into that revision before publishing it, then replace the old link wherever the task is assigned.
Discussion
Continue the thinking.
Comments are public and hosted in an open-source GitHub Discussions repository.
Loading comments connects your browser to GitHub. A GitHub account is required to post.