OpenAI Agents SDK integration
Put an OpenAI Agents SDK flow behind OSuite governance without rewriting the runtime itself.
Use this page when
Read this page when a team already has an OpenAI Agents SDK workflow and wants to route it through OSuite for approvals, receipts, and proof.
Integration goal
Keep the runtime as the decision origin, but make the governed decision, approval path, and proof export stable enough for reviewers to read.
Minimum integration path
- keep the runtime as the execution origin
- wrap tool execution in a stable decision envelope
- route the action through a declared destination type
- preserve approval state and receipt fields
- export proof from the same governed vocabulary
What should stay stable
| Runtime concept | OSuite expectation |
|---|---|
| Agent decision | one governed decision request |
| Tool invocation | one stable tool name and decision summary |
| Human check | one explicit approval or confirmation path |
| Final record | one receipt and proof path a reviewer can read |
What success looks like
The integration is working when a low-risk path, an approval-capable path, and a proof export path all remain readable after replay.
Common mistakes
- treating OSuite as a logging sink instead of a live governance boundary
- letting tool names drift between runtime and receipt layers
- testing only the auto-allow path
Next pages
Neutral runtime contract
Read this page to understand how OSuite describes runtime families, adapter modes, authority boundaries, and approval enforceability in one shared vocabulary.
Trust Boundary runtime
Use an external runtime governor without giving up workspace-native approvals, replay, and certificate closure.