Tweet fixado
I Tested an AI Tool Pipeline and Found a File-Identity Bug. Here it is.
We ran a simple but revealing experiment that tested the difference between “can the model understand what to do” and “can the toolchain reliably execute what it understands.” The task was basic on paper: I recorded a short MP4 video of myself saying a single sentence, uploaded it, and asked ChatGPT to transcribe what I said. This should be straightforward: speech is contained in the audio track, so the ideal pipeline is MP4 → extract audio → feed audio into speech-to-text → return transcript. Instead, what happened exposed multiple failure points: tool planning issues in agent mode, file identity issues (caching / wrong file referenced), and weak self-verification when the output was wrong.
In the first run, the MP4 was about five seconds long. I asked for a transcription, and it did not succeed on the first pass. But it was able to do something critical: it extracted the audio from the MP4 and produced a waveform audio file (WAV). That was the first big insight: you don’t need to search the internet for “MP4 to text” sites if the system can do internal conversion. The correct workflow is to treat the video as a container, strip out the audio cleanly, then run a speech model. I then asked it to send the WAV back, re-uploaded the WAV while in agent mode, and agent mode used an external Whisper web tool to transcribe the audio. That worked: the external tool returned the phrase correctly (the “I like chocolate milk…” line), proving that the pipeline itself is valid and that the barrier wasn’t conceptual-it was orchestration and tooling.
Then we ran the experiment again, but changed the order. Instead of uploading the MP4 in normal mode (where internal audio extraction worked), I put the system in agent mode first and uploaded a new MP4- this time about seven seconds long. again with me saying a phrase. This is where the failure mode became obvious: agent mode repeatedly tried to solve the problem by searching for websites to convert MP4 directly into text, rather than doing the more reliable two-step process (extract audio first, then transcribe). Even when I explicitly told it the correct flow, the agent behavior drifted toward “find a single website that does it all,” which is a tool-selection heuristic rather than a pipeline decomposition. The result was wasted time and lower reliability, because “MP4-to-text” web converters are inconsistent and sometimes require formats/permissions that don’t line up with the sandboxed environment.
After that, I took it out of agent mode and had it extract the audio again the correct way-MP4 → WAV-because normal mode could still do the internal extraction cleanly. Then I re-uploaded the newly extracted WAV and put it back into agent mode to use Whisper on the web. That should have been the cleanest version of the process: internal extraction + external STT. But here’s where the second major failure appeared: even after doing the processing, it returned the old phrase from the first experiment (“I like chocolate milk”), even though this was a different, longer clip. That meant one of two things happened: either the wrong file was uploaded/selected inside Whisper, or the system referenced the wrong audio artifact due to identity confusion.
That leads to the key technical issue I pointed out during the experiment: file identity / caching bugs. The seven-second file replaced the earlier file under the same filename (e.g., extracted_audio.wav). If a tool (or the agent layer) keys off the filename, session, or stale cached blob, it can accidentally reuse the prior upload or prior result. And that’s exactly what the failure looked like: the system confidently delivered the previous transcript twice, even though it was wrong for the new audio. In other words, this wasn’t “bad transcription,” it was “wrong artifact referenced,” and that’s a deeper orchestration/state-tracking flaw. A robust system should ( continued.
English
