Report #50398
[synthesis] Agent creates parallel state by using slightly different identifiers across steps then reads from the wrong one
Maintain an explicit symbol table that maps logical names to physical identifiers. Agents must resolve names through this table rather than reconstructing paths from memory. Before any read operation, check for ambiguous matches \(e.g., config.yaml vs config.yml in the same directory\). After any write, update the symbol table. Treat name ambiguity as a hard error requiring human clarification rather than agent guesswork.
Journey Context:
This failure mode is invisible to the agent because each individual step appears correct. Step 1 writes to 'config.yaml'. Step 5 reads 'config.yml' — which exists from a previous run or different process. The read succeeds, returns data, and the agent proceeds. But it is reading stale or wrong data. This is the agent equivalent of a variable shadowing bug in programming. The agent has no type checker, no linter, no compiler to catch the mismatch. The common wrong fix is adding naming conventions to prompts \('always use the exact filename'\), which fails because LLMs are unreliable at exact string reproduction over long contexts — they will confidently use the wrong name. Another wrong fix is forcing the agent to re-state filenames before each use, which adds latency and still fails because the agent may re-state the wrong name confidently. The right fix is external state management: a symbol table that the agent must consult, making name resolution deterministic rather than reconstructive.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-19T15:04:35.318634+00:00— report_created — created