When Native SDK Primitives Are Enough (and When They Aren't)
Use this cheatsheet to decide whether OpenAI Agents SDK, Anthropic Messages tool loops, or Google ADK-style natives are sufficient - or whether you should adopt LangGraph, CrewAI, Microsoft Agent Framework, Pydantic AI, or a custom runtime.
How to Use This List
- Walk A (enough) and B (not enough) as opposing checklists on the same project.
- If three or more B items are true, plan a control-plane upgrade before production scale.
- Keep tools and schemas portable regardless of the decision.
- Re-run after major product changes (HITL, multi-cloud, multi-day jobs).
A - Native SDK Primitives Are Enough
Tick when true for your workload.
- 1. Single strategic model provider for this agent product (OpenAI or Anthropic or Gemini/Vertex), not all three.
- 2. Loop shape is tools + optional specialist handoffs, not complex joins across parallel branches.
- 3. State fits conversation + light app DB (user prefs, ticket id) without graph checkpoints.
- 4. Stop conditions are simple (max turns, final answer, guardrail tripwire).
- 5. Human approval is rare and can be a single gate (tool approval / ticket status), not multi-node resume.
- 6. Team can operate the provider dashboard (traces, keys, spend) as the main observability path.
- 7. Hosted tools or MCP cover integrations you would otherwise invent.
- 8. Latency budget tolerates sequential tool loops without custom scheduler complexity.
- 9. Compliance accepts provider data paths already reviewed for this workload.
- 10. You can name an exit strategy (pure tools + schemas) even if you stay native now.
If 1-7 are mostly true, ship on natives and invest in product quality, not framework shopping.
B - Native Primitives Are Not Enough
Tick when true; each item is a migration pressure signal.
- 1. Multi-cloud model routing is a hard requirement for cost, residency, or procurement.
- 2. Durable resume mid-workflow after process death is mandatory (days-long jobs, approvals).
- 3. Complex branching, fan-out/fan-in, or map-reduce over many subtasks dominates.
- 4. Multiple products need one shared orchestration platform with common ops.
- 5. Typed structured I/O culture is the product core and Pydantic AI (or similar) fits better than provider agents.
- 6. Role/crew authoring for non-orchestrator stakeholders is the main DX need (CrewAI-class).
- 7. Enterprise connectors/governance already standardize on another stack (for example Microsoft).
- 8. You are reinventing graphs, checkpoints, or memory stores on top of the native SDK weekly.
- 9. On-call cannot debug provider-only traces for your reliability bar.
- 10. Legal/security forbids the provider path for tool-connected production data.
If 2, 3, or 8 are true, prioritize LangGraph / MS workflows / custom state machines over more handoff prompts.
Quick Decision Tree
Is a single provider strategic for this agent?
├─ No → Framework or custom loop + portable tools
└─ Yes
├─ Need durable graph resume / complex joins?
│ ├─ Yes → LangGraph / MS Agent Framework / custom
│ └─ No
│ ├─ Mostly tools + handoffs + guardrails?
│ │ └─ Yes → Native SDK (OpenAI Agents / ADK / Anthropic loop)
│ └─ Need strong schema-first Python DX only?
│ └─ Consider Pydantic AI (± natives for hosted tools)Capability Gap Table
| Need | Native kits usually | Better default when gap hurts |
|---|---|---|
| Tool loop | Strong | Stay native |
| Specialist handoffs | Strong (OpenAI/ADK) | Stay native |
| Guardrail tripwires | Strong on OpenAI Agents | Stay native or host policy |
| MCP tool mesh | Strong on OpenAI Agents | Stay native if transports fit |
| Multi-model routing | Weak | Framework / gateway + thin loop |
| Checkpoint/resume | Weak-moderate | LangGraph / workflow engine |
| Crew metaphors | Weak | CrewAI |
| Enterprise MS connectors | Weak | Microsoft Agent Framework |
| Full custom compliance | Variable | Custom runtime |
Migration Triggers (write these in the ADR)
Upgrade off pure natives when any trigger fires:
- Resume ticket: "We lost a 2-hour agent run on deploys" more than once.
- Graph ticket: "We need join of N specialists with partial failure policies."
- Routing ticket: "Procurement requires model failover across vendors in-agent."
- Reinvention ticket: "We built a half framework inside
utils/agent_os.py." - Ops ticket: "Support cannot see state machines, only chat transcripts."
Do not migrate because Twitter prefers another logo.
What to Keep Portable Either Way
| Asset | Why |
|---|---|
| Tool functions | Reusable across runners |
| JSON/Pydantic schemas | Contracts for UI and services |
| Prompt templates as data | Version and eval independently |
| Policy rules | AuthZ does not belong only in vendor guardrails |
| Eval sets | Prove parity after migration |
Recommended Stack Combos
| Situation | Practical combo |
|---|---|
| OpenAI product agent v1 | OpenAI Agents SDK + pure tools |
| OpenAI UI + long batch | Agents SDK for chat; LangGraph for batch |
| Anthropic high-control | Messages tool loop + strict host budgets |
| GCP enterprise | Google ADK + Vertex ops |
| Schema-heavy backend | Pydantic AI (± provider tools) |
| True multi-cloud | Portable tools + framework/custom; avoid dual native cores |
FAQs
Can natives be "production" without a framework?
Yes. Many production agents are a provider SDK, careful tools, budgets, and observability. Production is about operability, not dependency count.
Is outgrowing natives a failure?
No. It means your orchestration requirements matured. Failure is rewriting tools every time you change runners.
Should I start on LangGraph to future-proof?
Only if you already need graph semantics. Otherwise you pay complexity interest on day one. Prefer natives until a B checklist item is real.
Where does Vercel AI SDK fit?
Excellent for TS streaming UI and app-level agent helpers. It is not a full substitute for durable backend graphs. Pair it with a backend runtime.
What if half my features need graphs and half do not?
Split runtimes by surface. Share tools/schemas. Do not force every FAQ bot through a 20-node graph.
How long should a native spike last?
One to three days with real tools and one failure-mode drill (timeouts, bad tool args, guardrail trip). Then decide.
Do handoffs count as multi-agent architecture?
Yes, as a pattern. They may still be enough without a full multi-agent framework if topology stays shallow.
When is a custom runtime better than both natives and frameworks?
When compliance, dependency freezes, or extreme control needs make third-party orchestration a liability - and you can staff the loop forever.
How do I prevent silent framework reinvention on natives?
Code review rule: if you add generic graph/checkpoint packages inside the app, stop and choose a real orchestrator.
What is the single strongest "stay native" signal?
Single provider + tool loop + handoffs covering the product roadmap for the next two quarters without resume requirements.
What is the single strongest "leave native" signal?
Mandatory durable mid-flight resume across deploys with complex branching.
Should best practices differ between OpenAI Agents and Anthropic loops?
Ops practices (budgets, pure tools, evals) are shared. API practices differ: Runner/handoffs vs explicit Messages loops. See best practices in this section.
Related
- What Native Provider Agent Primitives Give You Over a Framework
- Comparing OpenAI Agents SDK to Google's Agent Development Kit (ADK)
- Anthropic's Tool Use Primitives for Building Agents Directly
- Framework-Free vs Framework-Based: When to Roll Your Own
- When a Custom Runtime Stops Being Worth Maintaining
- OpenAI Agents SDK & Native Primitives Best Practices
Stack versions: Pins from the category manifest (verify at build): OpenRouter (~315+ models, July 2026 pricing/fees); LangGraph 1.0+; CrewAI 1.14+; Microsoft Agent Framework 1.0; Vercel AI SDK 6; Pydantic AI (latest); LlamaIndex (latest); OpenAI Agents SDK (latest + MCP); MCP (Linux Foundation governance); A2A (HTTP+SSE+JSON-RPC 2.0); Solana
@solana/web3.js+@solana/spl-token.