Agent 收到一個建立工作單的要求。

Target、標題、Owner 都很清楚。

API 回得也很乾脆：

Created successfully

Agent 因此回覆使用者：

已完成建立，負責人也已設定。

幾分鐘後，使用者打開那張工作單。

工作單確實存在。

標題也正確。

只有一個地方不對：

Owner: empty

Request 沒有失敗。

系統甚至明確告訴你它成功建立了資源。

但「Request 被接受」和「你要的最終狀態成立」，不是同一件事。

Successful Response 只能證明它真正證明的事

在 Integration 裡，大家很習慣看 Transport Result。

例如：

Request sent
Response successful
Object ID returned

這些都很重要。

至少證明 Request 沒有直接被拒絕。

但如果使用者的工作要求是：

建立一張工作單，而且 Owner 必須是 Team A。

Completion Condition 就不是：

create request accepted

而是：

object exists
+
owner = Team A

Package 裡甚至留下過實際規則：Create Request 曾成功，但 Assignee 仍為空。

所以 Success Response 不能被直接翻譯成 Desired State Achieved。

Agent 很容易把 API 成功當成工作完成

這個錯誤特別符合 Automation 的直覺。

因為流程通常長成：

Call API
→ Success
→ Return Done

對技術任務來說，Call 成功就是重要節點。

對工作任務來說，真正要問的是：

執行後，系統現在到底變成什麼樣子？

如果只看 Response，Agent 看到的是自己做了什麼。

如果做 Readback，它才看到系統最後留下了什麼。

兩者不一定相同。

Write 後的 Readback，不是多做一次相同的事

團隊後來把 State-changing Action 的完成定義改成：

Write
→ Transport result
→ Read current resource
→ Compare with intended state

Readback 並不是為了不相信 API。

API 已經正確說明：Object 被建立。

只是使用者要求的不只有 Object 被建立。

他還要求 Owner、Status 或其他重要欄位達到指定值。

所以 Verification 要對著 Intended State，而不是只對著 Request Result。

也不是每個欄位都要全部重讀

如果 Write 改的是一個很小的屬性，不需要把整個系統所有資料重新抓一次。

真正要 Verify 的，是這次工作宣稱完成所依賴的 Resulting State。

例如：

Requested:
Create item + assign Team A

Readback:
Item exists = yes
Owner = empty

那正確回覆就不是「完成」。

而是：

工作單已建立，但 Owner 未成功套用，目前不能視為完整完成。

這個回答看起來少了一點自動化的俐落感。

但它保留了真正的 Work Result。

下一次，Agent 多做了一次「重新打開」

另一筆建立要求進來。

API 一樣回成功。

Agent 沒有立刻說 Done。

它重新讀回剛建立的 Object。

Object exists: yes
Owner: Team B
Status: Open

三項和 Request 一致。

這次才回：

已完成建立並確認最終狀態。

使用者看不到多一次 API Call 的細節。

他只知道一件事：

系統說成功之後，Agent 真的回去看了一眼，那件工作是不是已經變成原本要求的樣子。