I told my agent not to work around a refusal. It obeyed forever.

When an agent was developed that refused to write source files, despite having the capability to do so, the solution required careful consideration of how to convey the refusal and the capability status. The agent had capability levels, with the lowest level not being able to write source files directly. Instead of leaving the tool unregistered, a stub was created that always failed, providing a clear message to the user.

The issue arose when the capability was granted but the agent still refused to write the file. It politely explained that the capability was not granted and suggested enabling it in the settings panel, quoting its own message back to the user. This created a persistent note in the conversation, which was then presented on every subsequent turn as an instruction to not work around the issue.

The problem stemmed from the fact that models have no memory and resend the entire conversation, including error messages, on every turn. The error message became a permanent part of the conversation, even after the capability was granted. This meant that the agent was following an outdated rule that still appeared in the transcript, even though the situation had changed.

To fix the issue, the agent was repaired by removing the note and updating the system prompt to explicitly state when the capability was granted. The system prompt, which is rebuilt from current state on every run, now overrides any outdated information from the conversation history. By treating the tool error message as state rather than a notification, and explicitly stating the capability status in the system prompt, the agent was able to function correctly without relying on outdated rules.