AI Agent Framework vs Platform vs Harness vs MCP

Search for AI agent framework, platform, harness, or MCP and you will find product pages that all promise agents, tools, memory, and multi-agent support. They look like competitors because the vocabulary overlaps. They often live at different layers.

The short answer is this: a framework mainly structures application code, a platform delivers an application, a runtime manages execution, a harness assembles the model, tools, permissions, and environment into a working system, and MCP is a protocol for connecting tools to clients. These layers can be combined; they do not automatically replace one another.

One boundary table

Layer	Main responsibility	The question to ask	What it should not promise by itself
Agent framework	Compose nodes, state, and call logic	How do I orchestrate and test this flow?	Automatic deployment, permissions, and every runtime failure
Agent platform	Provide building, data, publishing, and operating surfaces	How does a team deliver this agent to users?	One template that fits every engineering boundary
Runtime / orchestration	Manage loops, events, retries, recovery, and scheduling	Where does work resume after an interruption?	Continuity from a `memory` checkbox alone
Agent harness	Assemble model, tools, permissions, context, environment, and interaction	Who decides whether a tool runs and how its result returns?	Automatic isolation or correct answers
MCP	Standardize discovery and invocation of external tools	How can different clients connect to this tool?	Replacing the agent loop, approvals, deployment, or business state

The boundary is not absolute. One project can ship an SDK, a runtime, and a platform. The table classifies the dominant responsibility so that GitHub stars and homepage feature lists do not become a misleading comparison method.

Framework vs platform: write the flow or deliver the app?

A framework usually starts with developer-owned code. You define nodes, state, tool calls, and branches; you test whether the flow behaves as intended. It is a good fit when your team needs control over data structures, execution, and deployment.

A platform packages more of the delivery work: visual workflows, knowledge connections, user management, publishing, logs, or billing may live in one product. Its value is not that it is automatically “smarter” than a framework. Its value is that a team has fewer pieces of infrastructure to assemble.

The first decision can be simple. If you need to embed an agent in your own system, inspect the framework's state and tool boundaries. If non-engineers need to configure and use it, inspect the platform's publishing, permissions, and operations. Do not treat two products as equivalent merely because both say multi-agent.

Runtime vs harness: why are the terms mixed?

A runtime is closer to a process manager. It cares about how a call starts, how events are recorded, how failures recover, and how multiple agents cooperate. A harness is the broader carrying system: beyond the loop, it decides which files are readable, how commands execute, when a dangerous action needs approval, how tool results re-enter context, and where the task runs.

That is why the same model can behave differently inside two harnesses during a long task. The model affects how far one reasoning step can go; the harness often affects whether work survives a crash, timeout, permission denial, or growing context.

The recent DeepSeek Harness analysis is a useful boundary case. It places model adapters, tool registration, session events, and even the agent loop behind plugin boundaries. That is an interesting architecture choice, but the project is still a developer preview; replaceability is not proof of maturity or security.

Where does MCP fit?

MCP solves a connection problem. A client can discover tools, read resources, and invoke actions through a shared protocol instead of requiring every tool provider to write a completely different integration for every model client.

MCP does not decide:

whether the task should call a tool;
how repeated calls are deduplicated or recovered;
who approves a dangerous action;
whether a large result should be paged, shortened, or preserved exactly;
where business state and acceptance conditions live.

An MCP server can therefore be the tool layer inside a harness and can be reused by several runtimes. Calling an MCP server a complete agent framework usually mixes the protocol, tool implementation, and orchestration system together.

Five questions are enough for a first choice

Who controls the flow? For explicit branches, retries, and human approvals, inspect the framework or orchestration layer first.
How does work recover? Ask about events, state, and idempotency instead of only looking for a memory field.
Who performs the real action? Files, shells, browsers, databases, and external APIs usually belong to the harness or Host boundary.
How do tools connect? Choose MCP when cross-client reuse matters; an ordinary function or internal API may be simpler inside one application.
How does the result return to context? Search, logs, and database results can be large. Inspect sources, failure states, size budgets, and recovery paths.

If the fifth question is the pain point, see the Agent Search MCP product page. It sits at the “search tool service plus MCP interface” layer; it is not a framework that replaces every agent runtime. Verify its source, tests, and current boundaries in lennney/agent-search-mcp.

Finish with responsibilities, not product names

The selection order can be reduced to one sentence: draw the control flow, state, permissions, execution environment, and tool protocol first; then see which project actually owns those responsibilities. The AI Agent ecosystem landscape answers “what layers and projects exist.” The 2026 framework selection guide answers “which choice fits my flow.”

This is not a leaderboard, and it does not prove that one layer is better than another. Products will keep merging responsibilities, and protocols will keep changing. The reusable decision is knowing which boundary you are buying, adopting, or implementing.