Claude Agent SDK vs Vercel AI SDK 7: Use Both

Every comparison I've read frames this as a feature bake-off. It isn't. There's one question underneath, and once you answer it the rest falls out:

Do you want to write the agent loop, or inherit one?

Inheriting a loop means someone else already decided how context gets compacted, when a subagent gets spawned, what happens when a tool wants to write to disk, and how a session resumes tomorrow. That's the Claude Agent SDK — it's the harness behind Claude Code, packaged so you can run it in your own process.

Writing the loop means you keep those decisions. That's ToolLoopAgent: a model, a set of tools, an approval policy, a typed runtime context, and the loop runs until you say stop. Nothing about files, shells or sessions is assumed, because the AI SDK doesn't know whether your agent is editing a repo or answering billing questions.

Neither is better. They're answers to different questions, and the harness question is the one people skip.

The Claude Agent SDK ships the same capabilities Claude Code has: built-in tools for reading, writing and editing files, running commands and searching the web; hooks that run your code at points in the agent lifecycle; subagents for focused subtasks; MCP servers; a permission layer; and sessions you can resume or fork. It also loads skills, slash commands and memory straight out of your project's .claude/ directory and ~/.claude/ — the same files Claude Code reads. That last part matters more than it sounds: whatever conventions your team already encoded for Claude Code come along for free.

It's Python and TypeScript only. From any other language you run the CLI as a subprocess with -p and --output-format json. That works, but you lose in-process hooks and typed tools, so treat it as an integration boundary rather than a real SDK.

The AI SDK comes at it from the web side. AI SDK 7 ships three agent types rather than one, which is the detail most comparisons flatten:

The model is a parameter, not the product.That's the AI SDK's whole thesis, and it's the one thing the Agent SDK structurally cannot offer.

Here's the part that dates every "which should I pick" post written before summer. HarnessAgent doesn't compete with the Claude Agent SDK. It runs it:

import { HarnessAgent } from '@ai-sdk/harness/agent';
import { claudeCode } from '@ai-sdk/harness-claude-code';
import { createVercelSandbox } from '@ai-sdk/sandbox-vercel';

const agent = new HarnessAgent({
  harness: claudeCode,
  sandbox: createVercelSandbox({ runtime: 'node24', ports: [4000] }),
  tools: { /* your tools */ },
  skills: [ /* your skills */ ],
});

Swap claudeCode for codex or piand the rest of your code doesn't move. Vercel's framing is "write the agent once, use the best harness available," and the abstraction normalizes the things that actually differ between harnesses: skills, tools, sandboxes, sessions, permission flows, compaction, subagents. A fourth adapter — Grok Build — landed in August, which tells you the adapter list is meant to grow.

Both generate() and stream() return AI SDK-compatible results, so a Next.js app already streaming through useChatdoesn't need a rewrite to put a real coding harness behind it. That's the practical unlock, and it's why I stopped treating this as a versus.

The catch is that an abstraction over harnesses is only as good as its lowest common denominator.Anything genuinely Claude-Code-specific — a hook firing at an exact lifecycle point, a plugin, some particular permission behavior — is a thing the shared interface has to either model or drop. If you're leaning on that depth, going direct to the Agent SDK is still the honest answer. Portability is never free; it's just usually cheap.

Reach for it when the agent's job looks like engineering work on a filesystem— reading a repo, editing files, running commands, checking the result, iterating. That's the shape Claude Code was built around, and the harness carries a lot of hard-won behavior you'd otherwise rediscover: what to compact and when, when a subagent is worth the round trip, how a permission prompt interrupts a run without corrupting it.

The .claude/ loading is the underrated part. Skills, commands and memory come from the same directory Claude Code uses, so the conventions your team already wrote get picked up by the SDK with no porting step. If you've invested in skills rather than MCP servers for procedural knowledge, that investment transfers directly.

The cost is commitment. There is no provider swap — this is Claude Code, and Claude Code runs Claude. If that's fine, you're trading optionality for depth, which is usually the right trade for a coding agent. It's the same calculus as choosing between the harness and raw API calls, which I went through in Agent SDK vs the Claude API, and against a graph framework in Agent SDK vs LangGraph.

Most agents aren't coding agents. A support agent that looks up an order, checks a refund policy and drafts a reply has no business inheriting a filesystem harness — it needs four tools, an approval gate on the one that moves money, and a stream to a React component. That's ToolLoopAgent, and using a coding harness for it is bringing a forklift to carry a laptop.

Two AI SDK 7 details earn their keep here. The typed runtimeContext is available during step preparation and tool approvals, so tenant ID, user role and feature flags flow through the loop as typed values instead of being closed over — which means you can define an agent once and share it, with the per-request variation passed in rather than baked in. And tool approvals can be HMAC-signed, with inputs revalidated before execution. If your approval step round-trips through a browser, that's the difference between a real authorization boundary and a client-side suggestion. I'd call that mandatory for anything user-facing that spends money.

Reach for WorkflowAgent when the run outlives the request. An in-memory loop loses everything if the process dies, and on a platform where a deploy can land at any moment, "long-running" and "in-memory" is a bad pairing. It's the same durability problem I dug into in Vercel's Workflow DevKit — now available as an agent type rather than something you bolt on.

Four questions, in order. The first one that gets a yes is your answer:

• Does the agent do engineering work on a filesystem, and are you fine being Claude-only? → Claude Agent SDK, directly.
• Do you want that harness but also AI SDK streaming, UI integration, or the option to switch harnesses later? → HarnessAgent with the claudeCode adapter.
• Must the run survive a restart or a deploy? → WorkflowAgent.
• Everything else — a handful of tools, one request, a provider you might change? → ToolLoopAgent.

The trap I'd warn against is picking the heavier option to keep your options open. A harness you don't need is a large surface you now have to reason about — sandboxes, permissions, sessions, subagents — for an agent that calls three tools. Start at the bottom of that list and move up only when something forces you to. Going up later is a contained change; unwinding a harness you never needed is not.

And whichever you choose, instrument it before you scale it. Agent loops fail in ways request/response code doesn't — silent tool-call drift, retries that look like progress, context quietly compacting away the thing that mattered. Most of what I wrote about agent observability applies here unchanged, and the subagent-versus-team distinction is worth settling early, because both SDKs will happily let you fan out before you can see what the fan-out is doing.