---
title: "Discussion on \"Tool Calls Need Completion Ownership: Why Your Agent's 200 OK Lies\" | Hashnode"
description: "Discussion on \"Tool Calls Need Completion Ownership: Why Your Agent's 200 OK Lies\". When an agent reports an action it never actually completed, the lie almost never starts in the model."
url: "https://hashnode.com/posts/tool-calls-need-completion-ownership-why-your-agent-s-200-ok-lies/6ab6a42a90a348aa8758ec28"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [Tool Calls Need Completion Ownership: Why Your Agent's 200 OK Lies](https://harrisonsec.hashnode.dev/tool-calls-need-completion-ownership-why-your-agent-s-200-ok-lies?utm_source=hashnode&utm_medium=feed)

When an agent reports an action it never actually completed, the lie almost never starts in the model.

Sep 25 · 10 min read · harrisonsec.hashnode.dev  
Read the article

-   [#message-queue](https://hashnode.com/tag/message-queue)
-   [#ai](https://hashnode.com/tag/ai)
-   [#distributed-system](https://hashnode.com/tag/distributed-system)

## Written by

[Harrison Guo](https://hashnode.com/@harrisonguo)

@harrisonguo · WhiteRock, CA

  
[View profile](https://hashnode.com/@harrisonguo)

Security engineer and distributed systems practitioner. Writing about systems internals, performance, security research, and AI applications. Building harrisonsec.com.

## Responses 2

Markdown supported · ⌘↵ to post

[Adam Lewis](https://hashnode.com/@nark3d)

[Oct 5](https://hashnode.com/posts/tool-calls-need-completion-ownership-why-your-agent-s-200-ok-lies/6ab6a42a90a348aa8758ec28/comment/6ac36647875b7bbbdd2d8531)

Queued isn't the same as sent, and message\_id only tells you the handoff happened, so the agent has no way to tell a bounce from a delivery unless the tool hands back a state it can act on. Where does ownership sit after the call returns - does the tool keep the message\_id and re-check it, or does the agent poll a status endpoint you haven't described yet? If it's the agent, you've just moved the same problem one layer out, because now it has to know which tools need following up and which don't. A completion contract the tool can't satisfy until the mail server has actually accepted the message would stop the 200 from being a lie.

[Harrison Guo](https://hashnode.com/@harrisonguo)

[Oct 5](https://hashnode.com/posts/tool-calls-need-completion-ownership-why-your-agent-s-200-ok-lies/6ab6a42a90a348aa8758ec28/comment/6ac36647875b7bbbdd2d8531#reply-6ac3ecc7653b42bfcdda13a1)

You've put your finger on exactly the part the post left implicit. Ownership has to sit with the tool, and your reasoning for why is the clincher: the moment the agent polls, every agent needs per-tool knowledge of which calls need following up, which is the exact coupling the tool was supposed to hide. So the fix isn't where the polling lives, it's the return type. The tool's success value has to mean 'the mail server accepted this,' not 'queued,' and anything short of that should be a different, non-terminal type, a pending handle the tool itself resolves or an explicit error, never a bare 200. The agent shouldn't even be able to represent 'done' until the tool hands back a terminal state. Your last line is the whole thing: make 'queued' unrepresentable as success.