By Greg Nowak. Last updated 2026-10-18.
An internal AI agent becomes an operations project as soon as it can change a customer record, send a quote or trigger a script. Before giving it that authority, your team needs clear answers: which actions can run automatically, who approves the exceptions, and how will you establish what happened?
OpenAI’s guardrails, resumable run state and tracing provide useful building blocks. The business still has to define the rules and connect them to its systems. For owners, operations leads and agency teams, that is where rollout work earns its keep: making a useful automation manageable after the demo.
Start with the actions the agent can take
Choose one bounded workflow, such as preparing a quote from an approved price list. List every tool it needs, the data each tool can access, and whether it reads, changes or sends anything. Split searching the CRM, preparing a draft and sending the quote into separate capabilities, each with its own permissions.
I would use the following as a starting point for an approval policy. Adapt it to the sensitivity of your data and the consequences of a mistake.
| Action | Pilot control | Evidence to retain |
|---|---|---|
| Read approved internal records | Enforce user and client access limits | Record references and requesting identity |
| Prepare a quote or ticket draft | Validate required fields; keep it unpublished | Draft version and validation result |
| Update a CRM record | Review the proposed field changes | Before/after values and approval decision |
| Send externally or export sensitive data | Review recipient, content and scope | Approved payload and delivery outcome |
| Delete records or run privileged commands | Keep outside the initial pilot | Manual handling or escalation record |
Read access deserves attention too. An agent that cannot edit anything may still retrieve another client’s information. For agencies, client separation belongs in the integration’s access checks.
Put guardrails where they can stop the action
OpenAI distinguishes automatic validation from approval decisions. Input guardrails check incoming requests, output guardrails check final responses, and tool guardrails validate arguments or results around attached function tools. Human review can pause sensitive tool calls before execution. The guardrails and human review guide explains these boundaries.
There are limits: input guardrails run for the first agent in a chain; output guardrails run for the agent producing the final response. They do not inspect every intermediate action. Use blocking input validation when processing must not begin before the check finishes.
For a quote workflow, enforce permitted products, discount limits and customer access in application code beside the relevant tool. Treat CRM notes and uploaded documents as business data, even when they contain text that looks like instructions. Keep credentials narrowly scoped.
Make approval a specific, resumable decision
A useful review screen shows the exact customer, recipient, amount and proposed change. Give reviewers enough context to decide without reconstructing the conversation. Assign an owner and an expiry rule; an unanswered request should remain pending or move to a manual queue.
In the TypeScript SDK, a function tool can declare needsApproval: true. When paused, inspect result.interruptions. The results and state documentation identifies result.state in TypeScript and result.to_state() in Python as the resumable snapshots. Save serialized state for delayed review, then resume the paused run after the decision. An empty final output can mean the run is waiting for approval.
My implementation checklist also includes checking reviewer permissions, binding approval to the exact proposed action, and checking whether the underlying record changed during the wait. Material changes should trigger fresh review.
Resuming state does not guarantee that an external action happens exactly once. Use an idempotency key where supported, or another duplicate-prevention mechanism. After an ambiguous timeout, check the destination system before retrying a send or update.
Use traces for diagnosis and records for accountability
The SDK’s normal server-side path enables tracing by default. Traces can capture model calls, tool activity, handoffs and guardrail events; multiple runs can also share a trace. OpenAI’s integrations and observability guide covers these capabilities and the choice between hosted and runtime-managed MCP connections.
For a business audit trail, I would additionally store the workflow ID, requesting user, proposed action, reviewer, decision time, policy version and execution outcome. Link these records to the trace ID and the destination system’s record or transaction ID. A reviewer clicking approve and the CRM accepting an update are separate events.
Decide which sensitive fields belong in traces and saved state, who can inspect them, and how long they should remain available. Test those settings using representative data before connecting live customer records.
Roll out one workflow with a clear handover
The Agents SDK overview makes the ownership clear: with the SDK, your server owns deployment, tool implementations, state storage and approval decisions. Budget for those pieces when scoping the project.
- Run in draft mode. Compare proposed actions against staff decisions on representative work.
- Enable reviewed writes. Test rejection, expired approval, service restart and a timeout after a possible successful update.
- Allow narrow automatic actions. Expand only where validation and observed results support it. Track corrections, review time and failed actions alongside time saved.
Before handover, name the person who handles exceptions and document how to disable write access. The delivery should include a tool inventory, approval matrix, state-storage design, audit fields and recovery instructions. Those are concrete items an operations lead can review and an agency can maintain.
Plan a rollout your team can operate
If you have a promising internal agent and need help connecting it to daily operations, talk to Greg about your workflow. Bring one process, the systems it touches and the actions you want it to take. That gives us a practical starting point for scope, approvals and a staged rollout.
Related on GrN.dk
- AI automations need a spend dashboard before the first runaway bill
- Before your AI agent starts clicking, write a browser policy
- Cache, Background, or Batch? How to Route AI Workloads
Need help with this kind of work?
Talk to Greg about your agent rollout Get in touch with Greg.
