Where should the execution guard live in AI agent systems?

[azender1]

I've been building SafeAgent, a small library that prevents duplicate side effects when AI agents retry tool calls.

Core mechanism:

• orchestrator generates a deterministic request_id
• execution guard stores a receipt
• retries return the cached receipt instead of executing again

The architectural question I'm trying to understand better is where the guard should live.

Option 1 — Orchestrator-level guard

Agent → Orchestrator → SafeAgent → Tool

Pros:
central visibility

Cons:
risk of accidental bypass if something calls the tool directly

Option 2 — Adapter / tool-level guard

Agent → SafeAgent Tool Wrapper → Tool

Pros:
self-sealing — every execution path passes through the guard

Cons:
distributed guard logic across tools

Right now SafeAgent behaves more like a reference implementation of the pattern rather than a fully enforced adapter boundary.

Curious how teams running production agent systems handle this:

• Where does the execution guard live?
• How do you prevent accidental bypass?
• Is this typically enforced structurally or by convention/code review?

Would love to hear how others approach this.

[azender1]

A bit more context on how I’m thinking about this.

The pattern SafeAgent is trying to formalize is:

1. the orchestrator generates a deterministic request_id outside the LLM
2. the execution guard stores a durable receipt keyed by that request_id
3. retries return the stored receipt instead of re-running the side effect

The architectural question is where that guard should live.

Option A:
orchestrator-level guard

Agent → Orchestrator → SafeAgent → Tool

Pros:

• central visibility
• easier to audit in one place

Cons:

• accidental bypass risk if something calls the tool directly

Option B:
adapter / wrapper-level guard

Agent → SafeAgent Tool Wrapper → Tool

Pros:

• stronger execution boundary
• harder to bypass accidentally

Cons:

• guard logic becomes distributed across adapters/tools

My current view is:

• request_id generation belongs in the orchestrator
• check/store/return-receipt logic belongs at the adapter boundary
• side effects should ideally only be reachable through that guarded adapter

That makes SafeAgent closer to a structural execution primitive than just a utility function.

I do not think SafeAgent should own upstream business policy or workflow semantics (for example, whether a refund should happen at all in a broader sequence). That feels like orchestrator or domain logic upstream of the execution guard.

The narrower goal is:

same request_id
→ execute once
→ return cached receipt on retry
→ never duplicate the side effect

Curious how others have implemented this in production systems:

• Where does the guard live?
• How do you prevent bypass?
• Do you enforce it with wrappers/decorators/middleware, or mostly by convention and code review?

[azender1]

A narrower version of the question:

If the goal is to prevent duplicate irreversible side effects on retry, the pattern I keep converging on is:

• orchestrator generates a deterministic request_id outside the LLM
• tool/adapter boundary performs check → store → return-cached-receipt
• durable store makes replay safe across retries / workers

That seems stronger than an orchestrator-only utility because it reduces bypass risk.

So the design question becomes:

Should the execution guard be treated as:

1. a wrapper/decorator around side-effecting tools
2. framework middleware
3. a lower-level store/receipt primitive that application code composes manually

My current bias is:

• request_id generation belongs in the orchestrator
• duplicate-prevention logic belongs at the adapter/tool boundary
• business policy stays upstream

Curious what people have seen work best in production:
wrapper / decorator, middleware, or convention + DB constraints?