Harness vs. Framework vs. SDK

One-Line Summary: A harness is a deployed product that runs models for you (Claude Code, Cursor); a framework is a library you compose into your own application (LangGraph, AutoGen); an SDK is the toolkit for building either (Claude Agent SDK, OpenAI Agents SDK) — conflating them is the single most common error in 2026 agent infrastructure conversations.

Prerequisites: What is an AI harness

What Are Harnesses, Frameworks, and SDKs?

The three terms get used interchangeably in articles, demos, and even vendor marketing, but they describe distinct kinds of artifacts and the distinction is load-bearing for any architectural conversation.

A harness is a complete, runnable application that already contains an agent loop, a tool registry, a permission system, memory, and a UI. You install it (npm install -g claude-code, cargo install, app store, browser tab) and use it. Claude Code, Codex CLI, Cursor, ruflo, OpenHands, Aider, Continue, Replit Agent are harnesses.

A framework is a library you import into code you write yourself. The framework gives you primitives — graphs, agents, tools — but the application is your code. LangGraph, AutoGen, CrewAI, LlamaIndex Agents, Mastra, Pydantic AI, Smolagents are frameworks.

An SDK sits between the two. It is a toolkit for building harnesses or substantial agentic applications, with conventions strong enough to be opinionated but not packaged as a finished product. The Claude Agent SDK and OpenAI Agents SDK are SDKs; Vercel AI SDK is an SDK with a strong harness-building tilt.

How They Differ

The cleanest way to disambiguate is to ask: what does the user run?

For a harness: the user runs the harness. They never see your code; they see Claude Code's UI, Cursor's editor, ruflo's dashboard.
For a framework: the user runs your application, which is built on the framework. The user sees your UI, your CLI, your Slack bot.
For an SDK: the user runs the application or harness you built with the SDK. The SDK is invisible.

A second test: what is the unit of distribution?

Harness → an installable binary or hosted product.
Framework → a versioned library (PyPI, npm).
SDK → a versioned library that includes opinionated patterns and often a CLI for scaffolding.

Why It Matters

Every architectural decision has a different shape depending on which of the three you are working with. With a harness, you extend it (plugins, hooks, sub-agents, MCP servers); you do not modify its loop. With a framework, you own the loop and can do anything code can do, but you also have to rebuild what the harness gives you for free. With an SDK, you are choosing how harness-shaped your application will be — too much SDK and you have rebuilt a harness; too little and you might as well have used a framework.

Picking the wrong category for the problem is a major source of wasted effort. Building a framework when you actually wanted a harness leads to teams reinventing permission systems and configuration formats. Using a harness when you needed a framework leads to forks, brittle plugins, and "we ran into the harness's opinions."

Key Technical Details

Closed-loop vs open-loop: A harness's loop is closed — it runs in the harness's process. A framework's loop runs in your process, which means you can intercept anything. An SDK is typically closed-loop with extensive callback surface.
Configuration files: Harnesses define them (settings.json, .cursorrules); frameworks have you write code; SDKs often offer both.
Deployment: Harnesses ship to the user's machine or a hosted endpoint. Frameworks ship as your application. SDK output ships as either.
Observability: Harnesses have built-in observability you cannot opt out of. Framework observability is your responsibility. SDKs vary.
Composability across vendors: Two harnesses cannot directly compose (they are separate processes); MCP is the workaround. Two frameworks compose if they share types or formats. SDKs compose with each other only if you write the glue.
Failure recovery: Harness failures are visible to the user (you cannot hide them); framework failures can be wrapped, masked, or retried in your code; SDK failures fall in between.

How Harnesses & Frameworks Implement This

Category	Examples (2026)	What you ship	What the user sees
Harness — coding	Claude Code, Cursor, Codex CLI, Aider, Continue, OpenHands	Plugin / extension / config	The harness UI
Harness — orchestration	ruflo, AutoGPT-derivative platforms	Plugin / agent definition	The harness UI
Framework — graph	LangGraph, Pocket Flow	Application code	Your UI
Framework — conversational	AutoGen, AG2	Application code	Your UI
Framework — role	CrewAI, Smolagents	Application code	Your UI
SDK	Claude Agent SDK, OpenAI Agents SDK, Vercel AI SDK, Mastra	Application or harness code	Your UI

Common Misconceptions

"LangGraph is a harness." It is a framework. You import it, write code with it, and ship the application you built.
"Claude Code is an SDK." It is a harness. The SDK for building Claude-powered harnesses is the Claude Agent SDK.
"Frameworks and SDKs are the same." Frameworks are unopinionated libraries; SDKs are opinionated toolkits with strong conventions about what you should build.
"I should build a harness for my team." Almost certainly not. Extending an existing harness via plugins is usually 10× cheaper than building one. Build a harness only when you have a UX or workflow requirement no existing harness can satisfy.

Connections to Other Concepts

what-is-an-ai-harness.md — The harness category in detail.
claude-agent-sdk-overview.md — A worked example of an SDK.
harness-vs-orchestration-framework.md — Drilling into the framework side.
the-2026-harness-landscape.md — The roster.
choosing-your-harness-stack.md — The capstone decision.