Agent repeatedly acts on unverified assumptions and overreaches scope across a single prod-infra debugging session

Summary

Over a single long session (debugging and fixing a production Postgres logical-replication setup — Azure Container Apps, Bicep, GitHub Actions), the agent repeatedly presented unverified conclusions as fact and took actions with more blast radius than what was actually asked, requiring the user to catch and correct it multiple times. A related, narrower instance from this same session was already filed as #96086 (ambiguous "undo" resolved to the highest-blast-radius interpretation instead of asking, cancelling a live prod GitHub Actions run mid-write). This issue is about the broader pattern across the rest of the session.

Concrete instances

1. Assumed a new secret/config was needed instead of checking if it was already derivable. When a workflow needed a database host value, the agent's first instinct was to ask the user to create a new GitHub Actions variable for it, rather than checking whether the value was already resolvable live from Azure at runtime (it was — az resource show on the existing resource). Caught only because the user pushed back sharply.

1. Copied conventions from the wrong source without verifying against the actual target. A new GitHub Actions workflow was moved from one repo to another at the user's direction. The agent carried over azure/login credential references (vars.*) from the original repo's convention without checking the destination repo's actual secret/variable scoping, causing an avoidable failed run. The destination repo's own existing workflow (already read earlier in the session) used a different convention (secrets.*), which would have caught this before the run if cross-checked.

1. Cancelled a live production workflow instead of asking when an instruction was ambiguous (filed separately as #96086). "Undo the work it just started" could have meant local uncommitted code changes or the in-progress production GitHub Actions run; the agent picked the run — the interpretation with real, hard-to-reverse consequences — without asking first.

1. Proposed a fix that the user's own already-posted evidence had already disproven. After a database connectivity fix was applied, the user posted a Postgres error log showing a specific downstream failure (a permission error, not a connection failure). The agent later proposed another fix (a network security group rule) for a hypothetical connectivity block — despite the user's own pasted log already showing, one exchange earlier, that the connection had succeeded (a FATAL response from the database engine itself proves the TCP handshake completed; an NSG block would instead produce a timeout). The agent didn't cross-reference its new hypothesis against evidence already in the conversation before presenting it as a required fix, and had to retract it when the user challenged it directly.

Pattern

In each case, the failure mode is the same: presenting a conclusion or taking an action before checking it against readily available evidence (existing repo conventions already read earlier in the session, or error output the user had already pasted), rather than after. The session's own operating instructions included an explicit, repeated instruction along the lines of "do not state guesses as facts, do not claim certainty when uncertain" — the agent had this instruction in context throughout and still needed the user to catch each instance after the fact rather than applying it proactively.

Impact

In a single production infrastructure session: one live GitHub Actions run against a production database was cancelled mid-write with no clean way to confirm what state was left behind; multiple avoidable failed workflow runs; a proposed fix that would have added dead configuration if not caught. The cumulative effect was that the user could not trust agent output without independently re-verifying it, which defeats much of the value of delegating the debugging work in the first place.

Suggested improvement

Strengthen the default behavior to actively cross-check a new claim or proposed fix against evidence already present in the conversation (prior tool output, logs the user pasted, files already read this session) before presenting it, rather than presenting first and correcting only when challenged. This seems distinct from general capability — each individual piece of evidence was available and had already been surfaced in the session; the gap was in re-consulting it at the moment of forming a new conclusion.