I was implementing an audio path and found something interesting about the memory.
There was a bug with my first implementation, so the model responded that it couldn't process audio attachments.
After I fixed the issue, the model would sometimes still completely fail, or state that it couldn't process the audio when it actually could. After debugging, I found that the earlier failures had been saved to memory and were constantly being recalled, convincing the model that it couldn't process audio when it actually could.
The screenshots below show a conversation where I argued with the model that it can, which seemed to override the poisoned memory. However, that's not always the case, sometimes it continued to fail.
This creates a vicious loop where a temporary failure can keep reinforcing itself through memory.
As a workaround, I had my coding agent delete the two poisoned memories and their associated anchor from netclaw.db. After deleting them, a fresh session processed the audio correctly on the first try. I used a prompt along the lines of:
“Find the memories related to the agent being unable to process audio attachments and the system transcribing audio before giving it to the agent. Delete those memory documents and their associated anchor, but don't delete any unrelated memories.”
The implementation I was testing is here:
https://github.com/salma-marei/netclaw/tree/feat/audio-model-input
If anyone could help me figure out how to handle this properly, or has any tips on how these kinds of failure/capability statements should be dealt with in memory, I'd really appreciate it.
I was implementing an audio path and found something interesting about the memory.
There was a bug with my first implementation, so the model responded that it couldn't process audio attachments.
After I fixed the issue, the model would sometimes still completely fail, or state that it couldn't process the audio when it actually could. After debugging, I found that the earlier failures had been saved to memory and were constantly being recalled, convincing the model that it couldn't process audio when it actually could.
The screenshots below show a conversation where I argued with the model that it can, which seemed to override the poisoned memory. However, that's not always the case, sometimes it continued to fail.
This creates a vicious loop where a temporary failure can keep reinforcing itself through memory.
As a workaround, I had my coding agent delete the two poisoned memories and their associated anchor from netclaw.db. After deleting them, a fresh session processed the audio correctly on the first try. I used a prompt along the lines of:
“Find the memories related to the agent being unable to process audio attachments and the system transcribing audio before giving it to the agent. Delete those memory documents and their associated anchor, but don't delete any unrelated memories.”
The implementation I was testing is here:
https://github.com/salma-marei/netclaw/tree/feat/audio-model-input
If anyone could help me figure out how to handle this properly, or has any tips on how these kinds of failure/capability statements should be dealt with in memory, I'd really appreciate it.