Skip to main content

Command Palette

Search for a command to run...

Verify the mechanism, never the setting

Updated
2 min readView as Markdown
M
Full stack engineer. 25+ years of production software engineering across e-commerce, workflow automation and agentic ai

I fixed the same bug wrong twice, and the reason generalises well past my system.

The symptom. Projects in my orchestration platform were occasionally created with names like {. A single brace. It had been happening for months and I had never traced it, because it was cosmetic and everything else worked.

The cause. The system captures agent output from a rendered view with a fixed window. Any response longer than that window lost its beginning, permanently, not into a buffer I could recover from.

The agent emits a title at the top of its response. The title scrolls out of the window. The parser finds nothing, falls through to a legacy path, and names the project after whatever fragment survived.

The same truncation was quietly handing worker agents plans with their instructions missing, which is considerably worse than a bad project name.

The first wrong fix. I identified a buffer setting, increased it, confirmed the setting had been applied, and declared victory.

The setting was inert. It could never have affected this class of view at all.

I had verified that the option was accepted, not that the mechanism changed. Those feel like the same act and they are not. The number that actually mattered was printed in the same line of output I was reading, and I read past it because I had already found what I was looking for.

The real fix was making the capture window twelve times larger. Response heads survive, titles parse, workers get whole plans.

Two things I took from it.

Confirming your config was accepted proves nothing. The question is never "did the system take my setting." It is "did the quantity I care about change." Those require different evidence, and only one of them is easy to check.

Your fixes interact, and the interaction is invisible from either side. Separately, I had spent weeks making agents terser. That work was correct. It is also what exposed this bug, because shorter responses stopped pushing stale markers out of the capture window, changing which failure mode was reachable.

Load-bearing assumptions do not announce themselves, and the ones that break are usually inherited from a version of the system that no longer exists.

https://openred.space/blog/agents-have-amnesia.html