The failure modes from those incidents aren't really observability gaps. They're about permission scope and action reversibility. An agent deleting a database doesn't need better logging after the fact - it needs a clear model of what's reversible and what isn't, built into the execution loop.
What works: classify every action as either local/reversible (reads, file edits, drafts) or external/irreversible (sends, deletes, pushes, payments). The former runs autonomously. The latter gets a confirmation checkpoint with no exceptions. That one split eliminates most incident surface area without needing a dedicated SDK.
Langfuse/LangSmith are useful for cost tracking and debugging post-hoc. But they're tools for the team, not the agent. The reversibility model needs to be at the framework level.
llm does not act on production. he build scripts, and you take the greatest care of theses scripts.
Clone you customer data and run evertything blank.
Just uses the llm tool as dangerous tool: considere that it will fail each time it's able to.
even will all theses llm specific habitus, you still get a x100 productivity.
because each of theses advise can ben implemented by llms, for llms, by many way. it's almost free. just plan it.
The gap isn't monitoring. It's what happens automatically when degradation gets detected. Right now the answer for every team I've talked to is "page a human." That human reads logs, guesses, deploys a fix. The system already shifted while they were debugging.
Some of the things you mention are more often addressed by guardrails. Some of the others (quality) require some evaluation for that measure, but results can go into the same monitory stack.