Sorry to be crude, but this sounds either dead on arrival, or at least needing a pivot, or a rephrasing of the pitch:

The moment something changes the system, it no longer observes it, in fact observing something might cause it to change ( https://en.wikipedia.org/wiki/Observer_effect_(physics) )

Either it's a tool for observing or it's a tool for fixing issues, it cannot be both, by physical principle.

Best case scenario here is that the product succeeds, and then you need to instrument the product itself in order to observe it, like debugging the debugger. But it wouldn't be an observability tool, it would shift the product that needs to be observed from the previous source code that is now a target language into the new source code that is now your product.

Love the analogy! We honestly just wanted to have this product ourselves, and that was our primary motivation behind building it.

I agree with the philosophical principle! If you give a rigid observer an incentive to 'remove bugs', it will happily silence all alerts and report success.

Our goal is to make sure that doesn't happen. The investigation agent is actually a separate agent with a separate goal.

In practice, we rarely see the agent just silencing stuff. When this happens, I get on it and make it an eval case :)

How does a grep or read affect the observing system?

I guess the change in voltages, arrangement of registers, filling of buffers in the network stack are changing but... what?