Show HN: SafeAgent – exactly-once execution guard for AI agent side effects
3 pointsby Lions2026a day ago2 comments
  • Lions2026a day ago
    A bit more context on why I built this.

    While experimenting with LLM agents calling tools, I ran into a reliability problem: retries can easily trigger irreversible actions more than once.

    For example:

    agent → call tool network timeout → retry agent retries tool call side effect runs twice

    That can mean:

    duplicate payment

    duplicate email

    duplicate ticket

    duplicate trade

    Most systems solve this locally with idempotency keys, but in agent workflows the retries can come from multiple layers (agent loops, orchestration frameworks, API retries, etc.).

    SafeAgent is a small execution guard that sits between the agent and the side effect. Every tool call gets a request_id, and SafeAgent records a durable execution receipt. If the same request is replayed, it returns the original receipt instead of executing again.

  • guerython21 hours ago
    We hit the same failure mode while running agents through n8n. Every tool call writes (request_id, tool, input_hash, response) into Postgres with a unique constraint. The guard query grabs that row first; if it already exists with a success flag we return the stored receipt instead of re-running the side effect. That way retries from the agent loop, HTTP transport, or queue worker may replay the cached payload and skip the duplicate action. Storing the error state alongside the success payload was the hardest bit so we don’t swallow a real failure while pretending it succeeded.
    • Lions20269 hours ago
      That’s very similar to the pattern SafeAgent is trying to formalize.

      What you described — (request_id, tool, input_hash, response) with a unique constraint — is basically the same core idea: treat the tool execution as a durable receipt and return the stored result on retries.

      While experimenting with agents I kept seeing retries coming from multiple layers (agent loops, HTTP retries, queue workers), so the goal was to wrap that execution guard into a small library instead of re-implementing the pattern each time.

      The tricky part you mentioned about error states is exactly what I ran into as well. If the execution fails you don’t want to record it in a way that blocks legitimate retries but also don’t want to silently replay a failure as if it succeeded.

      Curious how you ended up modeling that in Postgres — did you separate failure states from successful receipts or just include a status flag in the same row?