Why 69% Pick OpenAI's Agents SDK as Primary vs 38% Claude

By Lazar Milicevic · Published September 21, 2026 · 9 min read

You've read the same VB Pulse numbers: 75 enterprises have OpenAI's Agents SDK or Responses API somewhere in their stack, and 52 of them (69%) call it their primary orchestrator. Anthropic's Claude Platform sits in 45 stacks, but only 17 (38%) make it primary. If you're an SMB or a solo founder about to commit to an agent architecture for the next two years, that gap matters — not because one vendor "won," but because it tells you something about where the integration surface is deepest, where the docs are thickest, and where you'll find engineers on the other end of a Slack DM at 11pm.

I've shipped agent stacks on both. Here's what the numbers actually mean when you're the one paying the AWS bill.

What the VB Pulse numbers actually say

Read the data literally. Among enterprises surveyed by VB Pulse in August, 69% who touch OpenAI's agent platform make it their primary orchestration layer. For Claude Platform and Agent Skills, the equivalent number is 38%. Both platforms have real adoption — this isn't a story about Claude being ignored. It's a story about role: OpenAI is being trusted as the spine; Claude is more often a specialist model plugged into someone else's spine.

A few things the numbers do not say:

• They do not say OpenAI models are better at agent tasks. Claude Sonnet and Opus continue to lead on several coding and long-horizon evaluations that engineers care about.
• They do not say Claude Platform is failing. 45 enterprises adopting it is a serious footprint.
• They do not say the split will hold in 12 months. Anthropic's Agent Skills and MCP momentum is still early.

What they do say: when enterprises need to pick one platform to route tools, memory, hand-offs, guardrails, and observability, more of them pick OpenAI's. That's a decision about the integration fabric, not the model.

Why enterprises pick OpenAI's Agents SDK as the spine

Three practical reasons keep coming up when I talk to engineering leads.

One: the Responses API collapsed too much boilerplate. Before Responses, running an agent meant orchestrating Chat Completions, function calls, tool loops, and state yourself. Responses gives you a stateful primitive with built-in tools (web search, file search, code interpreter, computer use) that used to require three or four glue services. When you go from "we maintain a tool router" to "the API maintains it," the primary-orchestrator seat gets filled quickly.

Two: the SDKs are boring, and boring is what enterprises buy. OpenAI's Agents SDK in Python and TypeScript follows conventions that senior engineers can read in one sitting. Hand-offs, guardrails, tracing — each has a named primitive. Contrast that with agent stacks where every team invents its own state machine.

Three: observability shipped with the platform. OpenAI Traces gives you a first-class view of every tool call, hand-off, and token cost tied to a run ID. When your CTO asks "what did the agent do at 3:14am when it charged that card?", you have an answer without instrumenting yourself.

Here's the shape of a minimal Agents SDK setup, so the abstraction is concrete:

from agents import Agent, Runner, function_tool

@function_tool
def lookup_invoice(invoice_id: str) -> dict:
    # your DB call
    return {"id": invoice_id, "status": "unpaid", "amount_usd": 420}

billing_agent = Agent(
    name="Billing",
    instructions="Answer billing questions. Use lookup_invoice for status.",
    tools=[lookup_invoice],
)

triage = Agent(
    name="Triage",
    instructions="Route billing to Billing, else answer directly.",
    handoffs=[billing_agent],
)

result = Runner.run_sync(triage, "What's the status of invoice INV-1029?")
print(result.final_output)

That's the whole loop. No custom router, no hand-rolled state, no tool registry service. Multiply that convenience across 40 tools and 6 agents and the pull toward "primary" is obvious.

Why Claude Platform lands in the stack but not always as primary

Claude's position in the data — often present, less often primary — matches what I see in real deployments. Teams put Claude in for specific reasons:

• Coding and long-context tasks. Sonnet and Opus handle 100k+ token contexts and complex refactors better than what teams get from swapping models one-for-one.
• Agent Skills. The .skill bundle model — instructions, scripts, and resources loaded on demand — is genuinely different from tool-calling. It scales better when you have hundreds of narrow procedures.
• MCP. Model Context Protocol is the cleanest standard I've seen for exposing tools and data to models. It's vendor-neutral in theory and Anthropic-led in practice.

But look at what makes something a primary orchestrator:

None of this makes Claude worse at what it does. It makes OpenAI's Agents SDK a lower-cost path to "we run agents in production." When you're choosing the spine, lowest cost of "how do I get tracing working" often wins.

The real question for SMBs: what should your primary layer be?

Enterprises answer this with committees. You don't have that luxury and honestly you're better off. Here's the decision I walk small teams through.

Start with the workload, not the vendor.

1. Is the agent doing long-running, multi-step work that touches 5+ tools? You need real orchestration. Pick Agents SDK or a workflow tool like n8n / Temporal with model calls inside.
2. Is it doing single-shot generation with occasional tool use? You do not need an "agent platform." Use the raw API of whichever model you prefer.
3. Is it code-heavy (refactors, migrations, PR reviews)? Claude with Skills, or Claude Code, wins on quality even if you orchestrate elsewhere.
4. Is it customer-facing with strict guardrails and audit needs? OpenAI's guardrails + Traces are the shortest path to a defensible setup today.

Then decide whether to be vendor-committed or vendor-neutral.

The 69% number is a tell: enterprises are increasingly OK being committed to a vendor for the orchestration layer as long as the models underneath can be swapped. That's a reasonable posture. The alternative — building your own orchestrator on MCP — is technically cleaner but costs you 3-6 engineer-months you probably don't have.

A hybrid that works well for small teams:

# High-level architecture
orchestrator: OpenAI Agents SDK      # spine, tracing, guardrails
default_model: gpt-*                 # for routing, tool use, short tasks
specialist_models:
  coding_tasks: claude-sonnet        # invoked via API from a tool
  long_context_summarization: claude-opus
tool_protocol: MCP                   # so tools aren't locked to one vendor
observability: OpenAI Traces + Langfuse

This gets you OpenAI's orchestration ergonomics, Claude's model strengths where they matter, and MCP as insurance against being trapped.

Migration cost is the number nobody quotes

The reason "primary orchestrator" is sticky is that switching it is expensive. Not the code — the code is a weekend. The expensive part:

• Prompt regressions. Every prompt tuned against one model's quirks fails silently against another's. Budget 2-4 weeks of eval work per major agent.
• Tool schema drift. OpenAI function schemas and Anthropic tool schemas overlap 90% and diverge in the 10% that breaks in production.
• Trace format lock-in. If your on-call runbook says "open the OpenAI Traces UI and filter by run_id," moving to Claude means rewriting the runbook and retraining the humans.
• Auth and rate-limit topology. Enterprise tiers, per-model quotas, and org-level keys look nothing alike across vendors.

Practical mitigation, in order of cost:

# 1. Wrap the model call so you can swap providers behind one interface.
class ModelClient:
    def __init__(self, provider: str):
        self.provider = provider
    def complete(self, messages, tools=None): ...

# 2. Normalize tool schemas at the edge.
def to_openai_tool(mcp_tool): ...
def to_anthropic_tool(mcp_tool): ...

# 3. Store traces in a vendor-neutral store (Langfuse, Phoenix, or your own).
# 4. Keep prompts in files, not code, with per-model variants.

If you do these four things on day one, switching primary orchestrators later costs weeks, not quarters. Skip them and you're the enterprise that "somehow" ended up with OpenAI as primary because migrating away would eat two engineers for six months.

A concrete decision framework for the next 90 days

Here's what I'd do if I were setting up an SMB agent stack this quarter, given the current data:

Week 1-2: Pick primary based on your actual workload.

• Multi-agent, tool-heavy, need observability yesterday → OpenAI Agents SDK as primary.
• Code-heavy, long-context, quality-over-orchestration → Claude Platform as primary; accept you'll build more glue.
• Genuinely uncertain → OpenAI Agents SDK, because the exit cost is lower if you wrap it properly.

Week 3-4: Build the abstraction layer.

• Model client wrapper.
• Tool schema normalizer (MCP-shaped in the middle).
• Prompt files versioned per model.
• Trace export to a store you own.

Week 5-8: Ship one production agent end-to-end.

• Real users, real tools, real failure modes.
• Guardrails: input validation, output validation, tool-call rate limits, budget caps per run.
• On-call runbook with three specific failure scenarios and their fixes.

Week 9-12: Add the specialist.

• If you started on OpenAI, add Claude for the workload where it measurably wins in your evals.
• If you started on Claude, add GPT for the workload where it wins.
• Measure before and after with the same eval set. If the specialist doesn't beat the default by >15% on your metric, rip it out.

The 69/38 split doesn't mean you should pick OpenAI. It means most enterprises who deployed both ended up picking OpenAI as the spine. Your workload might genuinely tilt the other way. Run the numbers on your own tasks.

Where this goes in the next 12 months

Two forces will move the split.

MCP maturity. As MCP servers proliferate and Anthropic keeps investing, the "orchestration" moat OpenAI enjoys shrinks. If your tools speak MCP and your prompts are portable, the primary-orchestrator choice starts looking like a UI/observability choice, not a lock-in choice.

OpenAI's Responses API depth. Every new built-in tool (they've been shipping computer use, file search, code interpreter improvements) raises the floor of what "primary" means. Anthropic will match some of these but is unlikely to match all of them at the same cadence, given the smaller platform team.

Net: I'd expect the primary-orchestrator gap to narrow, not close, over the next year. Which is why the practical answer for SMBs is not "pick the winner" — it's "pick with a clean exit."

How BizFlowAI approaches this

We build agent stacks for SMBs and small teams that need to ship in weeks, not quarters. Our default architecture is exactly the hybrid described above: OpenAI Agents SDK as the orchestration spine for teams that want observability and guardrails out of the box, Claude models slotted in as specialists for coding and long-context work, and MCP-shaped tool schemas so nothing is welded to one vendor. Every deployment we run ships with a model client wrapper, vendor-neutral trace storage, and prompt files versioned per model — the four cheap habits that turn a six-month migration into a two-week one.

If you're staring at the 69/38 split and trying to decide what to commit to, we do discovery calls where we look at your actual workloads, your existing tools, and your team's on-call reality, then recommend a primary orchestrator with the trade-offs written down. No commitment, no PDF deck — just a working recommendation from someone who's run both platforms in production.

Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Book a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.