## TL;DR
The agent treated an XCom value as the task verdict: a None, a missing key, or a stale value read as failure. Task instance state is the verdict; XCom is just data the task left behind. Check state first, then interpret the XCom value in context. A missing XCom on a successful task is normal, not a failure.

```text
agent mis-read airflow xcom and reported a failed task
```

## Use this when
- An agent reports a task failed based on XCom contents.
- The task state is actually success.
- XCom is None, missing, or stale and the agent panicked.

## Not for this skill when
- The task genuinely failed. Read the failure.
- XCom is missing on a failed task. That is consistent, not a misread.

## Steps
1. Query the task instance state first. Note the state. Verify: the verdict is established
2. Read the XCom value with its key, task id, and dag run context. Note the full coordinates. Verify: the read is precise
3. Interpret the value against the state: None on success is just no data pushed. Note the interpretation. Verify: the value is contextualized
4. Fix the agent: state first, XCom second, never XCom alone. Note the new order. Verify: the logic is corrected
5. Add regression cases: success with no XCom, success with None, failure with XCom. Note the tests. Verify: the cases are pinned

## Variant phrasings
### airflow xcom none vs missing
The distinction phrasing.
### agent read xcom task state
The agent-shaped search.

Compatibility: Airflow 2.x XCom and task instance states via the REST API.

## Why it happens
XCom is a key-value side channel, not a status channel: tasks push what they want, including nothing. Agents that read XCom as a verdict confuse the absence of data with the presence of failure. The task instance state exists precisely to be the verdict, maintained by the scheduler, unambiguous. This misread is a small instance of a general rule: derive conclusions from the system's own status fields, not from interpreting its data fields as status.

## Edge cases / pitfalls
- A task can push XCom and then fail, leaving a stale success-looking value. State disambiguates; the value's timestamp helps.
- xcom_pull across dag runs needs include_prior_dates. A None from the wrong run scope is a scope bug, not a failure.
- Custom XCom backends can return deserialized oddities. Validate the read path before blaming the task.
- Sensors and operators that never push XCom succeed silently. Expect missing XCom on many successful tasks.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_8YPAI9VIJjuuw7OKdO_kww