OpenAI Agents SDK vs DIY agent stack: production tradeoffs

OpenAI's Agents SDK is an agent runtime. A production agent also needs a product API, authorization rules, durable state, audit records, evaluation data, and operations ownership. The SDK reduces the amount of runtime code a team writes. A DIY stack takes ownership of the runtime as well.

Use the SDK for workflows that fit its agent loop and benefit from its tools, sessions, approvals, guardrails, tracing, and MCP integration. Write custom orchestration when the workflow has durable business states, provider-routing requirements, strict recovery semantics, or control requirements that must be expressed outside the SDK. Many SaaS products use both: an SDK-managed planner inside a product-owned workflow and policy boundary.

The choice belongs at the workflow level. A copilot that reads account data has a smaller blast radius than a process that issues refunds, changes access, deploys infrastructure, or completes a regulated review.

What each team owns

The Agents SDK provides agents, a Runner, function tools, handoffs, guardrails, sessions, human-in-the-loop support, tracing, and MCP server tool calling. The runner handles the sequence of model turns and tool calls. OpenAI models use the Responses API by default. OpenAI Agents SDK documentation

An SDK does not supply a product's domain model. It does not decide whether a user may change a subscription, whether a requested refund violates a workflow rule, or how a failed write is reconciled. Those responsibilities belong in product services.

A DIY implementation owns the model loop as well: continuation rules, retries, cancellations, state persistence, tool dispatch, queue handling, tracing, and model-provider integration. That control has a price. A partial tool timeout, a redeployed worker, or a duplicate delivery turns into runtime behavior the team must define and test.

Concern	Agents SDK	DIY runtime	Decision rule
Turn execution	Runner continues model and tool turns	Application code controls state transitions and termination	Build custom execution where the agent must enter named, durable workflow states.
Tool calls	Python functions become Pydantic-validated tools; MCP tools are supported	Application owns schemas, validation, dispatch, and compatibility	Keep business tools narrow, idempotent, and permission-checked in either design.
Memory	Sessions hold working context for a run	Team selects stores, compaction, retention, and concurrency behavior	Fetch records that affect a decision from the product's system of record.
Telemetry	Traces cover runtime events and support custom processors	Team creates the event model and exporter	Require enough correlation data to link a run to its domain outcome.
Model choice	OpenAI defaults plus documented third-party adapters	Full provider and routing control	Introduce a provider boundary where availability, locality, or price routing requires it.

The ownership column drives the decision. Build a custom loop to enforce an existing product requirement. Avoid duplicating runtime behavior without a specific control requirement.

The SDK's useful boundary

The Runner handles the repeated cycle after a model selects a function: execute the function, attach its output to the conversation, and request the next model turn until the run ends. The SDK also includes streaming, structured outputs, sessions, handoffs, approval mechanisms, and guardrail hooks. OpenAI Agents SDK documentation

That lets a product team expose a small set of existing service operations to an agent without rebuilding the agent loop. The agent names the desired operation. Product code resolves the authenticated identity, constrains the query to the tenant, evaluates policy, performs the write through a domain service, and emits an audit record.

@function_tool
async def change_plan(ctx: RunContextWrapper[RequestContext], account_id: str, plan: str):
    request = ctx.context
    account = await accounts.get_for_tenant(account_id, request.tenant_id)
    policy.require(request.user, "billing.change_plan", account)
    return await billing.create_change_request(
        account=account,
        plan=plan,
        idempotency_key=request.action_id,
    )

Pydantic validation checks the arguments against a declared shape. The product service must still confirm that the account belongs to the tenant, the actor has the required role, and the new plan is valid in the account's current state. Put those checks in the same service boundary used by the rest of the application, where they apply to every caller.

Tracing is another practical SDK advantage. The runtime captures generations, function calls, handoffs, guardrails, and custom events. Generation and function spans may include sensitive inputs and outputs; capture of that data is enabled by default and needs deliberate configuration for customer data. Organizations using the OpenAI API under Zero Data Retention cannot use the SDK tracing service. OpenAI tracing documentation

These defaults are valuable during an initial rollout. They make failing tool paths visible without first building a tracing subsystem. They also establish a runtime contract that the application must accommodate. Treat that contract as part of the architecture review, especially when the agent uses asynchronous workers or handles regulated data.

When durable orchestration belongs in product code

Write custom orchestration when the workflow itself has a lifecycle independent of the model request. Common examples include:

• A review process moves through awaiting_documents, under_review, approved, and compensating, each with a distinct owner and retention rule.
• A job lasts hours or days, survives worker restarts, and resumes from a confirmed business checkpoint.
• A company routes calls across providers, regions, models, or cost classes under a stable internal policy.
• An action requires segregation of duties, a recorded approval, or policy evidence supplied to the user.
• Telemetry, encryption, data handling, or audit formats are fixed by an internal control.

In these systems, the model proposes the next allowed command. The workflow service persists the intent, assigns an idempotency key, evaluates authorization and approvals, executes the command, and reconciles the result with the system of record. The next agent turn receives the updated workflow state plus the permitted actions.

Consider a credit adjustment. The workflow record stores the requested amount, account, actor, policy result, approval request, idempotency key, external payment reference, and ledger outcome. A response timeout after the payment request leaves an indeterminate external result. A retry reads the idempotency key and payment reference before taking another action. Chat history cannot supply that recovery guarantee.

A custom runtime needs equally concrete plans for backpressure, queue recovery, tool deadlines, cancellation, dead-letter handling, schema migrations, trace retention, replay environments, and version compatibility. The basic loop is small. Production work accumulates in failure recovery and upgrades.

Authorization at the tool boundary

The SDK supports input, output, and function-tool guardrails. Function-tool guardrails run around custom function-tool calls. Agent input guardrails run for the first agent in a chain, and agent output guardrails run for the agent producing the final output. Handoffs, hosted tools, and several built-in tools fall outside the function-tool guardrail pipeline. OpenAI guardrails documentation

Use guardrails for classification, validation, content checks, and controlled interruption. Put authorization in the resource-owning service. A mutating command should pass through these steps:

1. The agent submits a typed, scoped command.
2. The application policy service evaluates the actor, tenant, resource, role, workflow state, and risk tier.
3. The domain service evaluates the write under the same authorization and state-transition rules.
4. High-impact work enters a durable approval record with the proposed change, actor, policy result, expiry, and approver.
5. The executor records the tool version, policy result, idempotency key, and final domain event.

The duplicate enforcement in steps two and three is intentional. The policy service gives the agent a decision before execution. The domain service protects the write path from defects in prompts, tools, gateways, and callers.

MCP exposes a tools interface: servers publish tools with names, descriptions, and JSON Schema inputs; clients discover and invoke them. Model Context Protocol tools specification The MCP server still binds the client identity to a tenant and authorizes every requested operation. Managed MCP infrastructure reduces server operations. Product teams retain the exposed capability set, permission model, and audit record.

Keep working context separate from product truth

State	Contents	System of record	Operational rule
Agent context	Conversation items, tool observations, short-lived plans	Session or runtime store	Expire and compact it under a defined retention policy.
Product state	Accounts, invoices, approvals, tickets, configuration	Product database and domain services	Read current values during authorized tool execution.
Execution evidence	Trace IDs, versions, tool inputs, approvals, outcomes	Observability and audit stores	Apply redaction, access control, retention, and deletion procedures.

SDK sessions hold working context. They are not a source of authority for account state. A persisted thread can contain stale instructions, old record values, or a tenant-scoping error. A tool that changes a record should load the current authorized record from the product service.

The same separation applies to trace data. Carry a correlation ID through the request, agent run, policy decision, workflow instance, tool invocation, and domain event. Operators then have a direct route from a ledger event or configuration change to the exact request, model version, and authorization decision that produced it.

Evaluate at the outcome boundary

The SDK instruments runner, task, turn, agent, generation, function, guardrail, and handoff spans by default, and it accepts additional or replacement trace processors. OpenAI tracing documentation

Extend those events with application fields: authenticated principal, tenant, request class, workflow version, model and prompt versions, retrieved source IDs, tool schema version, approval decision, tool latency, retry count, idempotency key, and domain outcome. Use opaque identifiers or approved redaction for customer data.

Define success in terms the product can verify. A support agent needs a correct, current answer for the authorized account. A configuration agent needs a valid configuration stored with the intended effect. A finance agent needs authorization, approval where required, an executed command, a matched ledger event, and a visible confirmation. A fluent response records none of those outcomes.

Build evaluations from real incidents and representative successful work. Include policy denials, changed schemas, ambiguous requests, duplicate deliveries, stale context, and partial tool failures. Replay candidates against a versioned baseline; then release through limited traffic with explicit rollback conditions. SDK users enrich the supplied runtime trace. DIY users build the trace event model and joins first. Both need the same evidence before changing prompts, models, tools, or routing.

A decision rule for SaaS teams

Choose the Agents SDK when the runtime's loop matches the workflow, the product services own permissions and writes, and the team can verify outcomes from system state. Start with a read-only or low-risk workflow, a narrow toolset, trace capture, and a confirmed success metric. Add explicit approval before high-impact writes.

Extract custom components when a demonstrated requirement calls for durable state transitions, provider routing, a dedicated trace-export path, or a policy control that needs product-specific execution. Keep that customization at the boundary that requires it. A planning agent can remain inside the SDK while a durable workflow service owns commands and side effects.

Where Ginger Labs fits

Ginger Labs embeds an agent or copilot in a SaaS or web product through a side panel, inline surface, or modal. The agent can answer questions and progress product work using the customer's schemas, stages, records, and data. Its SDK includes retrieval, evaluations, self-learning loops, and observability.

Ginger Labs runs the embedded-agent layer and its operating tooling. Customers own the product API, data model, domain workflow definitions, tenant and user permissions, action boundaries, product experience, and definition of a correct result. Product authority stays with the team that owns the underlying system.

Sources

• OpenAI Agents SDK documentation, accessed August 2026
• OpenAI Agents SDK guardrails, accessed August 2026
• OpenAI Agents SDK tracing, accessed August 2026
• Model Context Protocol: tools specification, accessed August 2026