approval architecture
Framework HITL or an external approval gateway?
Framework-native human-in-the-loop features are often the shortest path to pausing a run and collecting a decision. An external approval gateway addresses a different question: whether a normalized action may cross an execution boundary under current policy, identity, and approval state. Choose based on where authority lives, not on which option has the longer feature list.
- For
- Agent developers, platform engineers, and security teams deciding where tool-call approval should live.
- Reviewed
- Jul 14, 2026
- Length
- 1,265 words

They solve related problems at different layers
Framework HITL lives inside the agent's run loop. It can stop before a selected tool executes, surface the proposed call to an application, accept a decision, and resume the run with the right conversation or graph state. That proximity is valuable: the framework already understands the active agent, pending tool call, model context, and continuation mechanics.
An external approval gateway sits at or immediately before the execution boundary. It normalizes the proposed action, evaluates policy, persists the review separately from the run, and controls whether an executor receives authority for that exact action. In ActionProxy, review durability depends on the selected store: SQLite and Postgres persist records, while memory mode is ephemeral. The same boundary can serve more than one agent runtime only when every supported path actually passes through it.
Neither placement is automatically stronger. A polished pause-and-resume flow can still leave a second unguarded route to the provider. A gateway can also be bypassed if credentials or direct provider clients remain available elsewhere. The architecture has to make the chosen boundary real.
What current framework HITL features provide
- OpenAI Agents SDK tools can declare approval requirements. A run surfaces pending tool calls as interruptions, and serialized
RunStatecan be approved or rejected and resumed later. - Microsoft Agent Framework tools can require approval. The agent returns a function approval request with the call details, and the application passes the user's response into a subsequent run.
- LangChain's HITL middleware checks configured tool calls after model output and before execution. With a checkpointer, it can pause and later apply approve, edit, reject, or respond decisions allowed by the tool's review policy.
respondskips tool execution and is intended for ask-user interactions; it should not be used to deny a side-effecting tool. - These are runtime features, not evidence that every credential path, background job, alternate adapter, or direct API client in an application is governed.
Framework-native HITL is often enough when
- One agent runtime owns both the tool loop and execution, and there is no alternate path to the side effect.
- The person using the agent is also the appropriate reviewer, so an in-session confirmation is the intended control.
- Pausing, resuming, and giving rejection feedback to the model matter more than a shared cross-runtime approval queue.
- The application can persist pending run state for as long as approvals may wait and can safely handle code or tool-definition changes during that pause.
- Audit and policy requirements can be satisfied inside the application without creating a second source of truth.
An external gateway earns its place when
- Several runtimes, services, SDK clients, or MCP adapters should follow the same action policy and approval semantics.
- The reviewer is not the agent user—for example, a finance owner approving a refund or an operations lead approving a customer email.
- Approval must be bound to normalized identity, payload, policy version, expiry, and reviewer eligibility immediately before execution.
- Provider credentials live in a separate runner, and the agent should receive only narrow authority to dispatch an approved call.
- Operators need one correlatable record from proposal through policy, review, dispatch attempt, and reported outcome.
The combined pattern is usually an adapter, not two approvals
An adapter you build can leave interruption and continuation with the framework while the gateway remains authoritative for policy and execution. It submits the concrete tool call to the gateway, persists the framework's run state when review is pending, and waits. After a reviewer decides through the gateway, the adapter reloads the existing action status and resumes that same run with the outcome. ActionProxy Community does not ship dedicated adapters for the three frameworks compared here.
Avoid asking the same person to approve twice unless the controls have clearly different purposes. A client confirmation might communicate immediate user consent, while a separate business owner supplies organizational authorization. Label those decisions honestly. Do not collapse one into the other or imply that a framework's continuation token is an execution grant.
The critical link is stable correlation: the resumed framework run must refer to the same normalized action and decision. If the model changes the recipient, amount, resource, or tool arguments, submit a new action or use an explicit edit-and-revalidation path. Never carry approval forward merely because the natural-language task still sounds similar.
Reference sequence for an adapter you build
- Let the framework produce a typed tool call, but derive trusted tenant, actor, adapter, and environment at the gateway boundary.
- For HTTP, submit the exact tool name and arguments with a stable caller idempotency key; ActionProxy scopes it by workspace and route. Authenticated MCP adapters derive idempotency from transport or session context.
- Treat allow, deny, and require-approval as authoritative gateway outcomes; do not let model output override them.
- On require-approval, store the framework continuation state and the gateway action identifier together.
- Resume only after reading the authoritative decision. If an authorized reviewer edited input, resume with the approved payload and preserve the original proposal.
- Dispatch through the controlled runner or downstream MCP path using one-use authority, then report the execution outcome.
- Feed a concise success, rejection, or failure result back into the framework so it can continue without inventing a provider outcome.
Common questions
Questions developers ask
Is framework human-in-the-loop the same as authorization?
No. HITL pauses a run and collects a decision. Authorization also checks identity, policy, the bound action, reviewer eligibility, expiry, and control of the executor. A framework supplies some of that flow; the surrounding application determines whether the full boundary exists.
Should I use both framework HITL and an approval gateway?
Use both when the framework needs to pause and resume while a shared boundary owns policy, reviewers, and dispatch. Pass one authoritative organizational decision back to the framework instead of asking the same person for the same approval twice.
What happens if a reviewer edits a tool call?
The edit becomes the candidate execution payload, so policy runs again. ActionProxy retains both payload identities for a single authorized reviewer. It rejects edits on multi-reviewer approvals because votes cannot safely carry across payload versions today.
Can an external gateway make every agent runtime conform automatically?
No. Every adapter must normalize context correctly, and every route to the side effect must cross the governed executor or grant boundary. A direct provider client, stray credential, or legacy path can still bypass an otherwise sound gateway.
Primary sources
External references
- Human-in-the-loop — OpenAI Agents SDK — OpenAI, reviewed Jul 14, 2026
- Tool approval — Microsoft Agent Framework — Microsoft, reviewed Jul 14, 2026
- Human-in-the-loop middleware — LangChain — LangChain, reviewed Jul 14, 2026


