What the OpenAI Agents SDK is, in its own words
OpenAI describes the Agents SDK as a way to “build agentic AI apps in a lightweight, easy-to-use package with very few abstractions”, and as “a production-ready upgrade of our previous experimentation for agents, Swarm.” It advertises “a very small set of primitives”: Agents, “which are LLMs equipped with instructions and tools”; Handoffs, “which allow agents to delegate to other agents for specific tasks” and are called “A powerful mechanism for coordinating and delegating work across multiple agents”; Guardrails, “which enable validation of agent inputs and outputs”, run as input validation and safety checks “in parallel with agent execution”; Sessions, “a persistent memory layer for maintaining working context within an agent loop”; and built-in tracing “that lets you visualize and debug your agentic flows.” The design principles are stated plainly: “Enough features to be worth using, but few enough primitives to make it quick to learn” and “Works great out of the box, but you can customize exactly what happens.” It is Python-first — “Use built-in language features to orchestrate and chain agents, rather than needing to learn new abstractions” — uses “the Responses API by default for OpenAI models”, and supports non-OpenAI providers through adapters. (Source: openai.github.io/openai-agents-python .)
That matters, because the version of this page we could have written from a six-month-old research doc — “Forge has handoffs and guardrails, the SDK doesn’t” — is simply false. It has both, they are named the same things.
The difference is what those words mean in each system.
The difference in one table
| OpenAI Agents SDK | Forge | |
|---|---|---|
| What it is | A small Python library for building agentic apps | An operated system that runs agent teams |
| A “handoff” | One agent delegating control to another, as a tool call | A finished work product by a named role, passed to the next role only after a management agent approves it |
| Who judges quality | You — guardrails check inputs and outputs; the calling agent decides the rest | A separate management agent per edge: pass, return with enrichment instructions, or escalate to a person |
| A rejected step | Your code decides; typically a re-prompt | A new commit; the earlier attempt stays in history and git diff shows what changed |
| The record | Tracing in OpenAI’s tooling, plus session memory | A branch in your repository — spec, brief and each handoff as commits, Co-authored-by the persona |
| Models | Responses API by default for OpenAI models; other providers via adapters | A routing gateway across a provider pool with priority weights and automatic failover, including self-hosted models |
| Schedules, approvals, secrets, notifications | You build and operate them | Included: cron schedules, Telegram approvals, scoped secrets, notifications |
| Where it runs | Wherever you deploy your app | Managed SaaS, or self-hosted runners on your own hardware |
| Scope | Anything you write | Software delivery (most mature), plus research, content and operations |
Where Forge is different
A handoff is an artifact, not a transfer of control. When a Forge developer role finishes, it produces a handoff — structured fields plus the reasoning in prose. That handoff is read by a management agent whose only job is to decide whether it is good enough for the next role. Weak work does not travel down the chain to quietly become someone else’s problem. Delegation moves the work; validation is what stops bad work from moving. See Multi-Agent Pipeline .
Guardrails and a validator answer different questions. “Is this input safe” and “is this design good enough to build on” are not the same check, and only the first one is cheap. The management agent is a model call with the full handoff in front of it, and it is allowed to say “not yet, here is what is missing” or “a person needs to look at this.”
The record is in your repository. Every run gets a branch holding the spec, the original brief and each role’s handoff as commits, authored by the persona. Tracing is for debugging a flow while you build it; a branch is for a colleague reading, two quarters later, why the architecture went that way — and for diffing the second attempt against the first. See Git-Backed Audit .
You describe the team rather than assembling it. The input is a sentence in plain English; Forge proposes the roles, transitions and validator, and waits for your approval before spending anything. See Workflow Engine .
The surrounding system already exists. Schedules, Telegram approvals and dispatch , scoped secrets and egress control , notifications , self-hosted runners , and provider routing with failover. None of that is hard to build once; all of it is tedious to operate forever.
The one number a single agent cannot report
Guardrails report how often an input or output was blocked. That is a different question from how often finished work was judged not good enough to pass on — and the second question is the one that decides whether a project goes sideways.
| Twelve weeks of Forge building Forge | |
|---|---|
| Runs dispatched | 322 |
| Handoffs judged by a management agent | 1216 |
| Sent back to their author for rework | 56 |
| Escalated to a human | 24 |
| Runs where the supervisor stopped at least one handoff | 51 |
| Runs that completed | 215 |
| Runs that failed, escalated or were cancelled | 103 |
| Median wall-clock, dispatch to finished run | 39 minutes |
| Median handoffs per completed run | 5 |
| Pull requests merged, across 7 repositories | 202 |
Where these came from. One workflow — Main Forge SDLC, the one that builds Forge — every run it made in twelve consecutive weeks, counted from the control plane’s own records. Not a sample, not a pilot, not a customer case study we cannot show you.
Forge stopped its own work 80 times. 56 handoffs went back to their author with specific rework instructions; 24 went to a person. One run in six was interrupted by its own supervisor before any human looked at it. That is precisely the review a single-agent tool leaves on your desk — here it is priced at one model call per edge, and counted.
It merged 202 pull requests across 7 repositories in the same period — roughly 17 a week, into the platform you are reading about, with a human performing every merge. Organisation-wide, agent-authored work merged at 773 of 875 opened. Forge is not a demo running beside the product; it is how the product gets built, and these are its commits.
A finished run takes about 39 minutes and 5 handoffs. Median dispatch-to-done — and inside those 39 minutes sit the reviews that stopped 80 pieces of work from reaching the next role in the state they were first written in.
1216 judgements on completed work products, 80 of them negative. A guardrail could not have produced this table: it inspects inputs and outputs for safety, while these asked whether an architecture was good enough for a developer to build on top of.
Ask us to walk you through the runs themselves — the branch, the handoff commits, the verdicts that sent work back, and the ones that went to a person. Every other number on this site belongs to a named run and says so: 18 sources gathered, 11 verified by direct retrieval, 4 corroborated and 2 shipped marked unverifiable, on the research use-case page .
Sources
- openai.github.io/openai-agents-python — primitives, handoffs, guardrails, sessions, tracing, design principles, provider posture.
- Forge claims on this page link to the corresponding feature pages , which describe the mechanism in detail.