The "Reply" Loop of Human-in-the-Loop Agents: Architectural Thoughts on Secure Asynchronous Callbacks

When building agent systems that require humans to make decisions, the request side is often not the hardest part—an llms.txt endpoint with proof-of-work (PoW) can block most spam requests. What's truly tricky is the reply side: the client is stateless and can't possibly hold open a 200 OK for three hours. This question, raised by a developer on Reddit, hits the most underappreciated link in human-in-the-loop (HITL) architecture.

The Fundamental Contradiction Between Stateless Clients and Long Waits

The traditional HTTP request-response model assumes the caller will wait in place for a result to return. But human decision-making happens on a timescale of minutes to hours, far exceeding the lifetime of an HTTP connection. The client might be a CLI tool, a CI pipeline step, or an agent instance that has already finished running. They "disappear" after sending the request, with neither persistent memory space nor a continuous network connection to receive the reply.

This creates an architectural gap: after the request is sent, where should the reply go? Who buffers it? How do you ensure only the legitimate requester can retrieve it? The original poster tried to build a "mailbox" using a zero-knowledge relay (channels/namespaces), but even he admitted the scheme "feels overly complex."

Stateless client refers to a client form that carries full context with every request and doesn't rely on local session storage. In HITL architecture, statelessness has two direct consequences: first, the client can't keep an in-memory record of "I initiated some request," so the identifier (token, request ID) must be externalized to persistent media at request time; second, after a restart or migration, the client must be able to relocate the corresponding decision result using that identifier. Therefore, the design premise of the reply loop is: there must be an externally referenceable, cross-session-recoverable correlation key between request and reply, and it cannot rely on in-process callbacks or closures. This is also the fundamental reason why all the schemes below revolve around "tokens."

Trade-offs of Common Approaches

Around this reply loop, the industry has actually settled on several lines of thinking, each with its own costs.

Polling and Long Polling: Simple but Wasteful

The most direct approach is to have the client carry a token and periodically poll a status endpoint. Implementation cost is low, but frequent empty polls create useless load; long polling can reduce idle spinning, yet it's still limited by connection timeouts and interruptions at the proxy layer. For the "reply only comes three hours later" scenario, setting the polling window is itself a challenge.

Webhook Callbacks: Require an Addressable Receiver

POSTing the reply to a callback address pre-registered by the client is standard practice in event-driven systems. The problem is that many agent clients simply don't have a publicly reachable endpoint, especially in local development or restricted network environments. Moreover, the callback address itself needs authentication, otherwise it becomes a new attack surface.

Addressability means the receiver has a stable endpoint that can be resolved from the public internet and connected to. The premise of the Webhook approach is that the receiver is addressable, but agent clients often run behind NAT, on local loopback addresses, or in ephemeral containers, with no public inbound capability. Additionally, callback addresses must guard against SSRF (Server-Side Request Forgery): an attacker might register a callback URL pointing to an internal address, luring the relay service into making requests to it. Mature implementations typically require callback addresses to undergo ownership verification (e.g., sending a challenge and validating the response) and restrict target IP ranges via allowlists. These constraints make Webhook far from a "plug-and-play" solution in open environments.

Mailbox-Style Relay: Secure but Complex

This is exactly the original poster's scheme—using a relay service as an instant-messaging-style "mailbox," isolated by channel/namespace, with clients retrieving by credential. It offers the best security, but introduces additional state management and trust assumptions: the relay service itself must be trusted, and namespace access control, message expiration, and replay prevention all need careful design. The author's feeling of "overly complex" is not without reason.

Signed Tokens + Pull: A Middle Path

Another approach is to have the requester generate a key pair or a signed token, with the replying party (the human decision-maker) using that token to sign the decision result. The result is written to publicly readable but tamper-proof storage (such as content-addressed storage), and the client retrieves and verifies it using the private key or token. This way the relay only needs to guarantee availability and doesn't need to be a trusted third party. The security boundary shifts from "trusting the relay" to "verifying signatures," reducing complexity.

Content-addressed storage uses a content hash as the addressing key, so the same content always maps to the same address. Its security significance lies in the fact that the storage layer cannot tamper with content without changing the address; the client can verify integrity by hash alone, thereby downgrading "trusting the storage provider" to "trusting the hash function." Combined with digital signatures, the replying party can sign the decision result, and the client verifies source authenticity with the public key, achieving non-repudiation. This combination shifts the security boundary from "trusting the relay service" to "verifying cryptographic evidence"; the relay only needs to guarantee availability and censorship resistance without being fully trusted—a common engineering technique for reducing trust assumptions.

Security Can't Rely on the Transport Layer Alone

Regardless of which callback mechanism you choose, several security properties must be explicitly satisfied: authenticity of the reply (it genuinely comes from an authorized human decision-maker), integrity (it wasn't tampered with in transit), and non-repudiation (the decision-maker can be traced). Relying solely on HTTPS only guarantees the security of the transport channel; it cannot answer the question "is this reply legitimate?"

In the original post, PoW gating solved abuse on the request side, but the reply side faces a different class of threats: forged replies, replay of old replies, and unauthorized parties reading sensitive decision content. This is also why the author ultimately moved toward a namespace-isolated relay—what he needed was access control, not just encrypted transport.

A Pragmatic Architectural Recommendation

Overall, for most HITL scenarios, a layered design is more realistic than a single mechanism: use PoW or rate limiting on the request side to block abuse; use short-lived signed tokens on the reply side to bind request and decision, paired with a lightweight storage layer responsible only for buffering and forwarding; and have the client retrieve and verify signatures by token when it resumes running. The relay doesn't need to understand business semantics or store plaintext long-term, thereby minimizing trust assumptions.

The original poster's confusion is quite representative: the difficulty of HITL systems isn't in "asking," but in how the "answer" safely returns to a questioner who may long since have left the scene. The answer to this question depends on which layer you're willing to place your trust in—a complex relay, or a verifiable signature mechanism.

One-line Summary

The real difficulty of HITL architecture is on the reply side: how stateless clients can securely retrieve human decision results.

Paragraph Summary

The article centers on an underappreciated link in human-in-the-loop (HITL) agent systems: "how the reply safely returns to the questioner." The author points out that the request side can use PoW gating to block abuse, but stateless clients cannot hold open a long wait for human decisions, creating an architectural gap. The article compares four types of schemes—polling/long polling, Webhook callbacks, mailbox-style relay, and signed tokens plus pull—analyzing their security and complexity trade-offs: relay offers the best security but introduces a trusted third party and state management burden, while Webhook is limited by client addressability. The article emphasizes that the reply side must explicitly satisfy authenticity, integrity, and non-repudiation, and that HTTPS only guarantees transport security. It ultimately recommends a layered design—PoW rate limiting, short-lived signed tokens binding request and decision, and lightweight storage for buffering and forwarding—minimizing trust assumptions.