How to add approval rules to an OpenAI Agents SDK workflow

1. Why this guide matters

OpenAI Agents SDK gives you a clean runtime for agents, tools and handoffs. The spend question usually appears the moment a tool call becomes billable or triggers a vendor action.

This guide adds a NORNR approval threshold so the workflow can continue automatically for low-risk requests and pause when human review matters.

2. Install what you need

bash

pip install agentpay openai-agents

This guide uses the hosted NORNR path at https://nornr.com, so you can validate the decision flow without standing up the full local stack first.

3. Create the governed wallet

python

from agentpay import Wallet

wallet = Wallet.create(
    owner="ops-agent",
    daily_limit=75,
    require_approval_above=25,
    base_url="https://nornr.com",
)

This wallet is the mandate. It sets the budget and review threshold before the framework-specific workflow is allowed to continue.

4. Apply it in the workflow

python

from agents import Agent, Runner

agent = Agent(
    name="ops-agent",
    instructions="Help the operator decide whether a vendor action should run."
)

decision = wallet.pay(
    amount=34.00,
    to="vendor-api",
    purpose="paid tool execution",
)

if decision.get("status") == "approved":
    result = Runner.run_sync(agent, "Review the request and prepare the vendor action.")
    print(result.final_output)
elif decision.get("status") == "queued":
    print("Approval required before the agent may continue.", decision)
else:
    print("Policy rejected the spend.", decision)

The key pattern stays the same across frameworks: ask NORNR for a decision first, then let the expensive or externally billable step run only if policy says yes.

5. What to expect

approved means the workflow can continue immediately inside its mandate.
queued means the request crossed an approval threshold and should wait for review.
rejected means policy did not allow the action to proceed.

That three-way split is what makes the pattern useful: low-risk work stays fast, higher-risk work becomes reviewable, and clearly out-of-policy work never leaves the workflow.

6. When to use this pattern

tool execution can create real spend or vendor commitments
you want low-risk requests to stay autonomous
you need approval only when thresholds are crossed

7. What the output should look like

output

{'status': 'approved', 'requiresApproval': False}
{'status': 'queued', 'requiresApproval': True, 'approvalQueue': 'operator'}
{'status': 'rejected', 'reasons': ['policy_rule_blocked']}

You do not need the exact same payload shape everywhere. What matters is that the workflow can clearly distinguish approved, queued and rejected outcomes and persist the decision context.

8. Live proof and operator reality

NORNR already distinguishes queued from rejected so your agent can pause instead of just crash.
The live control room already shows approval-oriented workflow state.
You can keep the OpenAI Agents runtime and add approval logic without rewriting the whole flow.

NORNR operator surface used to review queued requests from an OpenAI Agents SDK workflow. — Approval rules only work if the queued request lands somewhere an operator can actually inspect, approve or reject without reconstructing the run manually.

The point of this pattern is not just better code structure. It is a workflow that operators can actually inspect, explain and intervene in when a request leaves its normal mandate.

9. Common mistakes

Treating approval as the same thing as rejection.
Triggering approval after the external tool already executed.
Forgetting to include amount, purpose and counterparty in the queued payload.

10. When not to use this pattern

every tool call must always be manually approved no matter what
you only need a hard stop and no operator queue
the workflow has no meaningful operator surface to resume from

11. What this replaces and what it does not

Tool-level allow/deny lists can block execution, but they usually cannot create a durable approval queue.
Human review outside the runtime works for demos, but it breaks when the workflow needs resumable state.
One giant threshold is easy to implement, but it ignores counterparty and category risk.

12. Implementation checklist

Gate the tool before it makes a billable or external commitment.
Make queued requests resumable instead of forcing the whole run to restart.
Persist the decision payload so operators know why the request was held.
Keep low-risk requests autonomous so approval remains the exception.

13. Featured follow-up paths

These are the adjacent pages most likely to help you turn this guide into a real rollout path instead of a one-off demo.