Where Each One Breaks

Anthropic's Weak Points

The Anthropic agent SDK ecosystem requires more assembly. MCP is a protocol, not a platform. You're building or running MCP servers, managing their lifecycle, handling auth, dealing with connection state. That's real infrastructure work. If you want the conceptual cleanliness of MCP, you're paying for it in ops overhead.

Tool call reliability also deserves honesty. Claude is strong at reasoning about when to call a tool. It's less consistent about returning structured output in exactly the format you specified when the tool schema is complex. You learn to write tighter schemas and validate on the way out.

Context window management is on you. Anthropic gives you 200K tokens with Claude 3.5 and up, which is enormous — but that doesn't mean you should stuff the window. Long-running agent loops accumulate context fast. You need a compaction strategy or your costs spiral and coherence degrades. This isn't a framework problem; it's a design problem. But frameworks like OpenAI's handle some of this for you automatically.

OpenAI's Weak Points

Vendor surface area. The Agents SDK is opinionated, which means it's also fragile at the edges. When you hit a case the SDK didn't anticipate — unusual tool call patterns, complex state requirements, multi-modal flows mid-conversation — you end up either monkeypatching the framework or working around it. I've done both. Neither is fun.

The handoff model, while elegant for simple delegation, gets complicated when you need conditional handoffs, loops back to a previous agent, or shared state across a handoff boundary. The SDK handles the happy path well. Production is rarely just the happy path.

And the underlying model matters. GPT-4o is good. Claude Sonnet 3.5 and 3.7 are meaningfully better on multi-step reasoning, instruction following on complex schemas, and staying in character across a long agent loop. If you're building agents that need to reason carefully, the model quality difference is real and it shows up in production output, not just evals.

---

How I Actually Pick

The framework choice follows the architecture, not the other way around.

Use the Anthropic approach — direct API plus MCP — when:

• You need composable, swappable context sources across multiple agents or products

• Your orchestration logic is complex enough that you want to own the loop

• Reasoning quality on complex tasks is the bottleneck, not scaffolding speed

• You're building something that needs to evolve — MCP's composability holds up better over time

Use OpenAI's Agents SDK when:

• You need to ship a working multi-agent flow fast and the use case is relatively standard

• Built-in tracing and debugging tooling will save you significant time

• You're prototyping or the use case is well-contained

• Your team knows the OpenAI ecosystem and switching costs are real

For VERA and the studio, the answer was Anthropic's approach — direct API, MCP servers for context, a custom orchestration loop I control. That choice paid off when I needed to wire a new product into the system. I added an MCP server, pointed the relevant agent at it, and the integration took an afternoon. No framework surgery.

---

Production Patterns Worth Stealing

Schema Discipline

Whichever SDK you use, your tool schemas are load-bearing. Vague schemas produce vague tool calls. Be specific about types, required fields, and what the model should do when it doesn't have enough information to call the tool confidently. Write the schema like you'd write a type definition in TypeScript — precise, no implicit any.

Fail Loudly at the Boundary

Agent failures tend to be silent and downstream. The model calls a tool with malformed args, the tool returns an error, the agent improvises, and by the time you notice something is wrong you're three steps removed from the actual failure. Build explicit validation at every tool boundary. Log the raw tool call and the response. Trace the loop, not just the final output.

Compaction Is Not Optional

For any agent running more than a few turns, you need a strategy for managing context growth. Summarize completed subtask context before passing to the next step. Use separate conversation threads for distinct logical phases. Don't rely on the model to manage its own context coherently at 150K tokens — it won't.

Separate Orchestration from Execution

The agent that decides what to do next should not be the same agent doing the work. Orchestrators stay lean — they hold the plan, manage handoffs, and track state. Execution agents get the minimal context they need for the specific task. This isn't just an architectural preference; it's how you keep costs from compounding and coherence from degrading across long runs.

---

The Actual Answer

There's no universal winner between the Anthropic agent SDK approach and OpenAI's. The question is what your system needs and how much of the orchestration you're willing to own.

If you want the framework to do more work for you, OpenAI's SDK is real and it ships fast. If you want composability, model quality, and the ability to architect something that scales across multiple products without rewriting your orchestration every time you add one — the Anthropic path is the more durable bet.

I learned the hard way that picking the framework before you've designed the architecture is how you end up fighting your own tooling six months in. Design the system first. Pick the SDK that fits it.

If you want to see how I've structured the full agentic operating layer for the studio — which models handle which tasks, how VERA coordinates across products, and the MCP server patterns I use in production — it's all in The Builder's Playbook.