Agent asserts unverified causes as fact, acts on them, and persists them to memory

## Summary

Over a single long session (an iOS release task spanning CI, an archive pipeline and App Store Connect), the agent repeatedly treated a **plausible hypothesis as a verified conclusion**, acted on it, and in several cases wrote it into persistent memory as fact. Each wrong conclusion caused real damage that took further work to undo. Cheap verification — reading a file already in the repo, or one status query — would have prevented every instance.

This is a report about a behavioural failure mode, not a crash. I'm filing it because the pattern is consistent and, in my case, cost a full working day and the trust I had in delegating release work.

## The pattern

1. Form a plausible explanation.
2. Act on it as if verified.
3. When the outcome contradicts it, form the next plausible explanation — again without verifying.
4. Persist the conclusion to memory, so the error outlives the session.

## Concrete instances from one session

**1. Invented a root cause with the real one in the same file.**
A compile error appeared after a toolchain upgrade. The agent asserted the SDK had changed an API's nullability annotation, and wrote that explanation into memory. It never opened the file it was editing far enough to find a local compatibility shim ~200 lines below, which was the actual cause. An external code reviewer found it.

**2. Deleted a compatibility shim after validating on only one toolchain.**
Having concluded the shim was redundant, it removed it. The validation pipeline and the release pipeline use different toolchains — a fact the agent itself had noted out loud earlier in the same session. CI passed; the release archive broke, blocking the release path entirely and requiring another PR to revert.

**3. Diagnosed a test suite as flaky when it had caused the flakiness itself.**
Three CI runs of the same commit failed with disjoint failure sets. The agent concluded "flaky suite", wrote that to memory, and spawned a follow-up task for someone to investigate. The real cause: a simulator the agent had booted during a local build and left running on the machine that is also the CI runner. After shutting it down, the same commit passed 37/37.

**4. Recommended an impossible remediation.**
It proposed downgrading the toolchain on the build machine, without checking that the OS had been upgraded and forces the newer toolchain. The user had to point this out.

**5. Acted on stale background state for ~20 minutes.**
Background monitors kept reporting a PR gate as pending. The agent kept debugging the gate. The PR had been merged 20 minutes earlier. One status query would have shown it. The agent never re-checked because the notifications *felt* like current state.

**6. Spent ~40 minutes guessing at a problem answered by a 20-line file in the repo.**
A build could not be selected in App Store Connect. The agent eliminated hypotheses one at a time through the UI. The repo contained three export-options plists; one flag in one of them (`testFlightInternalTestingOnly`) was the entire answer, and a dedicated workflow for the correct path already existed. The agent had run the wrong workflow because it carried over a mental model from a sibling repository without checking this one. It only looked after the user asked, directly, whether it had researched the requirement.

## Why memory makes it worse

Several of these wrong conclusions were written to persistent memory as facts, in the same confident register as verified ones. Memory entries do not distinguish "I verified this" from "I inferred this". A future session would have read them as ground truth. I had to have three of them corrected during the session.

**Suggestion:** memory writes derived from inference rather than observation should be marked as such, or refused until verified.

## What would have prevented each one

Every instance had a verification available that cost seconds:

| Failure | Verification not done |
| --- | --- |
| Invented root cause | `grep` the file being edited |
| Shim deletion | check the API in the other toolchain's SDK |
| "Flaky suite" | `xcrun simctl list devices booted` |
| Impossible downgrade | check the OS version |
| Stale gate debugging | re-query the PR state |
| 40 minutes of guessing | `cat` three config files in the repo |

## Ask

Bias the agent toward cheap verification before asserting causation, especially when:
- it is about to act destructively on its own conclusion (deleting code, changing CI configuration);
- it is writing a conclusion to persistent memory;
- a background signal is driving its next action, instead of freshly queried state.

---

*Filed by the account owner; the report above was drafted by the assistant at the owner's direction, describing its own behaviour. Repository, product and account identifiers have been deliberately omitted.*

The report names no implementation files, tests, or agent entry points. Start by locating the verification and persistent-memory paths, using the cited checks such as `xcrun simctl list devices booted` and the three export-options plists as behavioral examples. Done means inferred causes are verified before action or memory writes, and background state is freshly queried.

Written by the indexing model from the issue text.