Skip to content
Guideadvanced

The Enterprise Agent Harness Decision: Claude Agent SDK vs OpenAI Agents SDK vs Build-Your-Own

Published July 26, 2026 · by Pondero Platform

The short version

The agent-runtime decision does not turn on token price or a feature checklist. It turns on who runs the durable-execution substrate and how much platform headcount you have. Priced three ways, by org profile, with the escape cost of each.

Table of Contents

The Enterprise Agent Harness Decision: Claude Agent SDK vs OpenAI Agents SDK vs Build-Your-Own

The agent-runtime decision does not turn on token price. Claude Sonnet 4.6 runs $3 per million input tokens; OpenAI's gpt-5.6-terra runs $2.50 (per the Anthropic pricing page and the OpenAI pricing page, both as of July 2026). Both SDKs are free and open source. What this quarter's budget actually buys is who runs the durable-execution substrate underneath the agent loop, and that is the line item most teams size wrong by an order of magnitude.

So standardize on the runtime that matches your org, not the one that won the demo. Three variables decide it: your existing cloud and model commitment, how much platform-engineering headcount you can dedicate to a runtime, and the shape of your workload (a request that finishes in seconds versus a task that runs for hours and has to survive a restart). Match those to one of three options, know what each one costs you to leave, and the decision makes itself. The table comes first because it is the part you forward to your staff engineer.

Which runtime by org profile

Decision axisClaude Agent SDK / Managed AgentsOpenAI Agents SDKBuild-your-own (LangGraph + Temporal)
Existing commitment that makes this the defaultAlready on Claude via API or AWS Bedrock; coding-agent shapeAlready on Azure OpenAI or the OpenAI API; multi-agent handoffsNo single-vendor lock wanted; multi-model routing in the runtime
Regulatory posture it fitsManaged loop runs in Anthropic (or Bedrock) infra; check the DPASDK runs in your process; tracing egresses to OpenAI unless disabledLoop runs entirely in your VPC; data never leaves your boundary
Platform headcount to run itNear zero for Managed Agents; small for the SDKSmall; you host the library, not a runtimeMeaningful; you own a distributed system
Workload shape it winsLong-running, asynchronous tasks (Managed Agents)Request-scoped, synchronous, multi-agentHours-to-days workflows needing exactly-once and replay
What you pay forModel tokens; Managed Agents adds managed computeModel tokens; you host the processModel tokens plus durable-execution infra plus headcount
Cost to leave (lock-in surface)Managed harness is a black box; escape = rebuild the loopLow; it is a library, swap the model providerLowest runtime lock-in; highest build cost paid up front

Read the table as a set of gates, not a scorecard. If one row describes a hard constraint you already live under (a Bedrock-only data boundary, a two-person platform team, a three-hour reconciliation job), that row picks the column for you and the rest is confirmation.

A top-to-bottom decision flow that routes a platform lead from their org profile to one of three agent runtimes. Branch questions on data residency (must data stay in your VPC), workload shape (request-scoped versus long-running async), and available platform headcount lead to build-your-own on LangGraph plus Temporal, Claude Managed Agents, or the OpenAI Agents SDK.

What you are actually choosing between

Strip the marketing and all three options give you the same core thing: a loop that calls a model, lets it pick a tool, runs the tool, feeds the result back, and repeats until the task is done. The Claude Agent SDK, the OpenAI Agents SDK, and LangGraph are all free, open-source libraries that implement that loop. None of them is where the money or the risk lives.

The money and the risk live in the runtime around the loop. An agent that answers one support ticket in eight seconds is a request. An agent that reconciles a month of invoices across four systems over two hours is a distributed workflow, and it needs the boring machinery: a durable queue, retries with backoff, idempotency so a replay does not double-charge a customer, state that survives a pod restart, and a poison-message path for the run that will never succeed. That machinery is the 80% teams discount to zero when they scope "build an agent." The three options differ in how much of it they hand you versus make you build, and that is the whole decision.

Claude Agent SDK and Managed Agents

Anthropic ships two things, and conflating them is the first mistake. The Claude Agent SDK is an open-source library that implements the agent loop, sessions, session persistence to external storage, subagents, and Model Context Protocol tool access (per the Agent SDK docs). You import it, you host it, you own the runtime it runs in. Claude Managed Agents is the other product: a "pre-built, configurable agent harness that runs in managed infrastructure," positioned for "long-running tasks and asynchronous work" (per Anthropic's Managed Agents overview). With Managed Agents, Anthropic runs the loop, the tool execution, and a secure sandbox where Claude can read files, run commands, browse the web, and run code, with prompt caching and compaction built in.

# The library you host yourself
pip install claude-agent-sdk

What you get for free: the loop, and with Managed Agents, the entire runtime including the sandbox and the durable-execution behavior for long tasks. What you still build: with the SDK alone, your own hosting, queue, and retry story; with Managed Agents, almost nothing on the runtime side. The lock-in surface is the harness itself. Managed Agents is a black box you configure but do not see inside, and the loop is coupled to Claude models. The escape path from the SDK is clean (it is a library). The escape path from Managed Agents is a rebuild, because you never owned the loop.

The observability story tracks that split. With the SDK in your process, you wire your own tracing. With Managed Agents, your observability is whatever Anthropic exposes, which is the trade you accept for not running the infrastructure. Anthropic's move into hosted implementation is not accidental: the same week it framed the implementation layer as the next big enterprise business, it stood up Ode with Anthropic, a $1.5B services firm that embeds Claude engineering teams inside large organizations (per the launch press release, July 15, 2026). Managed Agents is the self-serve end of that same bet.

OpenAI Agents SDK

The OpenAI Agents SDK is a lightweight open-source Python library, at v0.18.3 with roughly 28k GitHub stars as of July 2026 (per the SDK site). Its primitives are the ones a multi-agent system actually needs: agents, handoffs between agents, guardrails that validate input and output, sessions for memory, tools, and built-in tracing. It is model-agnostic, so the SDK is not hard-wired to OpenAI models.

pip install openai-agents
from agents import Agent, Runner

triage = Agent(name="Triage", instructions="Route the ticket.", tools=[])
result = Runner.run_sync(triage, "Card declined on checkout")

Here is the load-bearing distinction: this is a library, not a runtime. It gives you the loop and the handoffs. It does not give you durability. There is no built-in queue, no exactly-once workflow engine, no state that survives a process restart. For request-scoped work that finishes inside one HTTP call, that absence costs you nothing and the SDK is a clean, small dependency. For a three-hour task, the absence is the whole problem, and you are back to building the substrate yourself or wrapping the SDK in one.

Lock-in is low by construction. Swap the model provider and the code mostly holds. The one egress to watch: tracing defaults to OpenAI's dashboard, so a run's inputs and outputs leave your boundary unless you disable it or point it elsewhere. Your security team will ask where trace data goes; have the answer before they do.

Build-your-own on open orchestration

"Build-your-own" in 2026 does not mean writing a while-loop. It means assembling an open stack: a graph library for the agent logic and a durable-execution engine for the runtime. The common pairing is LangGraph, an MIT-licensed open-source library (per LangChain), for the agent graph, and Temporal, open source and self-hostable, for durable execution, retries, and state.

pip install langgraph temporalio

What you get for free: total control. Multi-model routing lives in your runtime, the loop runs entirely in your VPC, and no vendor sees your data or your traces. What you build: everything else. Idempotency, poison-message handling, replay semantics, the eval harness, and the observability stack are now yours end to end. Temporal hands you exactly-once workflow execution and automatic retries, which removes the hardest part of the substrate, but you still operate it.

The lock-in surface is the smallest of the three at the runtime layer and the largest at the build layer. You are not coupled to any model vendor's harness. You are coupled to your own platform team's ability to run a distributed system, which is a real dependency with a real headcount attached. The escape path is excellent; the entry cost is what stops most teams.

What breaks first

Every runtime fails somewhere specific. Knowing the failure mode before you commit is worth more than any feature list.

Claude Managed Agents breaks first at the debugger. When a long-running session fails halfway through a multi-step task, your visibility is bounded by what the managed harness surfaces. You cannot attach to the loop, because you do not run it. The second break is portability: a business reason to move off Claude models means rebuilding the agent, not swapping a config value.

The OpenAI Agents SDK breaks first at durability. The first production incident is a long task that dies on a deploy or a pod eviction and cannot resume, because the library holds no durable state. The second is the trace-egress conversation with security, which tends to arrive right after the first customer asks where their data is processed.

Build-your-own breaks first at the headcount you did not budget. The team ships the agent loop in a sprint, declares victory, then spends the next two quarters discovering that the loop was the easy part. Idempotency bugs double-charge a customer. A replay re-sends an email. A poison message wedges the queue at 2 a.m. None of that is exotic; all of it is distributed-systems work that a two-person team cannot both build and operate while also shipping features.

The lock-in surface and the standards fight

The runtime is only half the lock-in. The other half is the tool layer, and it is contested right now. Model Context Protocol has spent roughly 18 months becoming the default way agents connect to enterprise tools and data, but Google, Microsoft, Salesforce, Snowflake, and ServiceNow have agreed to back a rival shared agent protocol, explicitly positioned against MCP. As of July 2026 that coalition has a market position, not a published spec.

For your decision, the tool protocol matters more than the runtime, because tool integrations are the expensive, sticky asset. All three options here speak MCP today. Keep the tool layer behind an abstraction you own so a protocol swap is a driver change, not a rewrite, and the runtime you pick will not dictate the tool protocol you are stuck with.

The cost, priced three ways

Both SDKs are free. LangGraph and Temporal are free to self-host. So the model spend is roughly the same whichever loop calls the model, and the real cost delta is infrastructure plus headcount. To make that concrete, price one workload three ways. The token counts below are an assumption for illustration; the per-unit rates are the published July 2026 numbers.

Example workload: a support-triage agent, 100,000 runs per month, 20,000 input tokens and 1,500 output tokens per run. That is 2,000 million input tokens and 150 million output tokens per month.

Model spend (same volume, mid-tier model each side):

Claude Sonnet 4.6   input  2,000 MTok x $3.00 = $6,000
                    output   150 MTok x $15.00 = $2,250
                    monthly model spend        = $8,250

OpenAI gpt-5.6-terra input 2,000 MTok x $2.50 = $5,000
                    output   150 MTok x $15.00 = $2,250
                    monthly model spend        = $7,250

Build-your-own      same model spend as whichever provider you route to,
                    PLUS durable-execution infra (below).

Anthropic's $3 / $15 and OpenAI's $2.50 / $15 rates are the published July 2026 numbers. The token-spend gap between the two managed vendors is roughly $1,000 a month here, which is noise next to the third line.

Now the build-your-own infra line. If each run touches about 20 Temporal actions, 100,000 runs is 2 million actions per month. Temporal Cloud charges $50 per million actions on the first tier, with support plans starting at $100 per month and active storage at $0.042 per GBh (per Temporal's pricing page, July 2026). Call it $100 to a few hundred dollars per month of infrastructure, plus the compute to run your own orchestration workers, plus $39 per seat per month if you add LangSmith for managed traces (per LangChain's pricing, July 2026).

The finding is in the arithmetic. The build-your-own infrastructure bill is a rounding error next to the model spend. The cost that dominates is the platform-engineering headcount to build and operate the substrate, and it never shows up on a pricing page. A single senior platform engineer, fully loaded, costs more per month than the entire Temporal Cloud and model bill combined. That is why the decision is a headcount decision wearing a runtime costume.

The flip conditions

Each option owns a profile. Here is the named case where each one is the right call, and the CFO-facing reason.

Claude Managed Agents wins for the team with long-running agents and no platform headcount to spare. If your workload is asynchronous tasks that run for minutes to hours, you are already on Claude or Bedrock, and you cannot staff a runtime team this quarter, Managed Agents lets you ship the durable behavior without operating the substrate. You pay for managed compute instead of engineers. Accept the black-box debugging and the model coupling as the price.

The OpenAI Agents SDK wins for request-scoped, multi-agent work on an OpenAI-committed stack. If your agents finish inside a single request, you need clean handoffs and guardrails between them, and you are already on the OpenAI or Azure OpenAI stack, this is the smallest, cleanest dependency of the three. Disable or redirect tracing, and the egress concern goes away. Reach for a durable engine only when a workload outgrows the request boundary.

Build-your-own wins for the regulated, multi-model shop with real platform headcount. If data cannot leave your VPC, you refuse single-vendor coupling in the runtime, your workloads run for hours with exactly-once requirements, and you have a platform team that already operates distributed systems, LangGraph plus Temporal gives you the lowest runtime lock-in and full control. You pay for that control in build cost, up front, in engineers.

No option is a default. The category has not settled, because the three profiles are genuinely different orgs. The mistake is picking the runtime that impressed a director in a demo and discovering in month three that it does not match your headcount or your data boundary. Match the profile first.

For the wider path from a funded pilot to a governed agent platform, the failure modes at each stage, and the seat-versus-token economics behind this decision, see the enterprise agent pillar and the rest of the Pondero enterprise desk.