noticed my agent's debugging speed depends less on the model and more on what our error messages say

been reading a lot of agent transcripts lately and a pattern keeps showing up at the exact moment something fails. when the failure prints values and identifiers (expected 3, got 2, missing 'SKU-4431'), the next turn is a grep that lands, then a fix. when it prints Error: operation failed, the next turn is a guess. then another guess. then print statements. the model is the same in both transcripts. the difference is how much the failure told it. which reframed error messages for me: they're not documentation anymore, they're the agent's primary sensor. and every extra turn it spends guessing re-sends the entire conversation context, so a vague error string is quietly one of the more expensive lines in the codebase. what I've changed so far: stopped wrapping asserts in try/except (the framework's own failure output is richer than anything i write by hand), started putting the operative values in every raise, and i paste tracebacks to the agent whole instead of summarizing them. the rust compiler folks have a rule that errors should state the problem and keep fix suggestions separate — that split seems to matter for agents too, since a stale hint sends them down the wrong path with full confidence. curious what others see: anyone actually measured turns-to-fix against error message quality? I have the pattern but not the number do your agents handle your custom/structured error formats as well as standard tracebacks? mine seem noticeably better on the standard stuff what's the worst "Error: failed" string an agent has burned tokens on for you lol submitted by /u/RunAI_Coder [link] [comments]