2026 Comparative Analysis: Agent Harness and Runtime Infrastructure — Applied Technology Index

Executive Summary

An agent harness is the runtime scaffolding that turns a language model into a system that can repeatedly call tools, preserve state, apply policy, expose progress, and decide when work is complete. An agent SDK supplies programmable abstractions for that system. In current products, the boundary between harness, SDK, workflow engine, sandbox adapter, and hosted runtime is not consistent.

This analysis compares five open or publicly documented approaches that represent materially different designs:

DeepSeek Harness treats the entire application—including model adapters, tools, session logging, the agent loop, persistence, telemetry, sandboxing, approvals, and UI—as a replaceable Cordis plugin tree.
OpenAI Agents SDK uses a deliberately small set of Python and TypeScript primitives around agents, runners, tools, handoffs, guardrails, sessions, and tracing, with a separate beta Sandbox Agent layer for persistent workspaces and command execution.
Claude Agent SDK packages the agent loop and tool environment behind Claude Code as a Python or TypeScript library. Its self-hosted architecture supervises one claude subprocess per active session and makes process, filesystem, session-store, and tenant isolation explicit operating concerns.
Google Agent Development Kit 2.0 combines agents with a graph-based workflow runtime, event and service model, Task API, plugins, tools, evaluation, and multiple development or deployment surfaces across several programming languages.
Microsoft Agent Framework Harness composes a batteries-included long-task agent from Microsoft Agent Framework primitives: model clients, per-call history persistence, context providers, compaction, planning and todos, tool approvals, telemetry, skills, files, optional child agents, and optional looping.

The central finding is that agent-loop convenience and runtime completeness are different purchasing criteria. A few lines of SDK code may produce a working tool loop, but production readiness depends on the surrounding contracts: how state is committed, which hooks can block execution, where tools run, whether approvals bind to exact arguments, how sessions survive rescheduling, which telemetry leaves the process, and whether extensions can replace the loop itself.

No system is the universal winner. DeepSeek Harness provides the broadest documented replaceability but is explicitly in developer preview. OpenAI Agents SDK is the most concise general-purpose application SDK in this set and adds a modular sandbox layer, but its standard runner is not a durable workflow engine. Claude Agent SDK offers the richest preassembled computer-and-code tool environment, while its subprocess and local-state model creates concrete hosting obligations. Google ADK offers the broadest language and workflow-runtime surface. Microsoft Agent Framework provides the most opinionated batteries-included harness composition while retaining framework-level middleware, workflow, and provider abstractions.

A defensible production design separates at least five contracts even when one package implements all of them:

decision loop: model invocation, tool selection, stop conditions, retries, and delegation;
state: transcript, working memory, artifacts, checkpoints, and durable business process state;
capabilities: tool schemas, filesystem, shell, browser, MCP, skills, and model adapters;
enforcement: authentication, authorization, approval, sandboxing, network egress, redaction, and limits;
operations: tracing, replay, evaluation, cancellation, deployment, recovery, and version migration.

The harness should be replaceable or governable at each boundary. A plugin system alone does not make unsafe code safe, a session store does not guarantee durable execution, a tool allowlist does not provide process isolation, and tracing does not prevent a side effect.

Key Findings

The category is converging on eventful loops, not one-shot prompts. All five systems represent intermediate messages, tool calls, state changes, or lifecycle hooks as first-class runtime events or callbacks.
Extension models differ more than tool decorators suggest. DeepSeek can replace its loop and product subsystems through plugins; Google plugins apply globally at a runner; Microsoft uses middleware, decorators, context providers, and framework composition; Claude exposes hooks, MCP, subagents, permissions, and packaged plugins around a prebuilt loop; OpenAI exposes lifecycle hooks, tools, guardrails, model adapters, sessions, tracing processors, and runner configuration around a small core.
State models are not equivalent. DeepSeek derives model history and replay from an append-only session event log. Google ADK has its Runner commit yielded events and deltas through session, artifact, and memory services. Claude stores JSONL session transcripts locally by default and can mirror them through a SessionStore. OpenAI sessions manage conversation history, while sandbox sessions and snapshots preserve a separate workspace. Microsoft Harness persists history after each model service call and composes session context providers.
A resumable transcript is not a durable workflow. None of the basic loop abstractions alone guarantees that a paid or external side effect executes exactly once after a crash. Long-running business processes still require idempotency, reconciliation, and, where needed, a durable orchestration layer.
Execution isolation varies from included to externalized. Claude Agent SDK is designed around a shell and working directory and recommends containers or stronger isolation for production. OpenAI Sandbox Agents add selectable local, Docker, or hosted sandbox clients. DeepSeek exposes sandbox and filesystem capability seams. Google ADK and Microsoft Agent Framework can call powerful tools but generally leave the final compute and network isolation architecture to deployment and tool implementations.
Approvals are control-flow primitives, not security boundaries by themselves. OpenAI human-in-the-loop controls, Claude permission evaluation, Google tool confirmation, Microsoft tool approval, and DeepSeek permission policies can pause or reject tool calls. They still need authenticated reviewers, immutable action envelopes, expiration, and current authorization at execution time.
Observability defaults carry privacy consequences. The compared systems expose tracing, telemetry, events, or hooks, but file contents, prompts, tool results, command output, and credentials can enter telemetry. Export policy and redaction must be reviewed independently of whether tracing is easy to enable.
MCP is a shared tool boundary, not a shared runtime. OpenAI, Claude, Google, and Microsoft document MCP integration, and DeepSeek ships an MCP client plugin. MCP can standardize discovery and invocation while each harness retains different state, permission, retry, tracing, and deployment semantics.
Maturity must be read feature by feature. DeepSeek labels the whole harness developer preview. OpenAI labels Sandbox Agents beta. Microsoft marks some Harness additions—such as background agents, file access, looping, and shell tooling—experimental or pre-release depending on language and package. A stable top-level SDK version does not make every extension production-stable.
The safest procurement question is not “which framework has the most features?” It is “which runtime contract can we test, constrain, migrate, and observe under our workload and threat model?”

Methodology

This analysis checked the live Applied Technology Index research index and the local public research collection before selecting the topic. Existing ATI research covered agent memory, sandboxing, durable execution, observability, context compaction, skills packaging, delegation, approvals, authorization, tool gateways, and runtime policy. It did not compare the higher-level harnesses that now assemble those capabilities into an executable agent product.

Current public discussion and release activity were used only to identify the research question. The comparison is grounded in primary materials available on 19 August 2026: the DeepSeek Harness repository and architecture documentation; OpenAI Agents SDK repository and documentation; Anthropic Claude Agent SDK documentation and Python repository; Google ADK 2.0 repository and technical documentation; and Microsoft Agent Framework repository and Learn documentation.

The source snapshot matters because the projects were moving quickly. At the time of review, DeepSeek Harness described itself as a developer preview without a tagged GitHub release; the latest public GitHub releases found for the other implementations were Google ADK Python v2.7.1, OpenAI Agents SDK Python v0.21.1, Claude Agent SDK Python v0.2.139, and Microsoft Agent Framework .NET 1.18.0. Release numbers are context, not evidence of relative quality or compatibility.

Each system was assessed on ten criteria:

Loop ownership: whether the framework supplies a tool loop, graph runtime, replaceable loop, or subprocess-owned loop.
Extension model: plugins, callbacks, hooks, middleware, decorators, services, context providers, or subclassing.
State contract: messages, events, session records, memory, artifacts, workspace state, checkpoints, and resume behavior.
Tool boundary: local functions, built-in tools, MCP, OpenAPI, hosted tools, shell, filesystem, browser, or subagents.
Policy interception: where a host can inspect, modify, approve, deny, or stop a model or tool action.
Isolation: whether filesystem and command execution are in process, subprocess-based, sandbox-adapted, containerized, or delegated to a hosted runtime.
Observability: events, traces, OpenTelemetry, processors, hooks, replay, and data-export controls.
Orchestration: handoffs, subagents, graph workflows, background agents, task APIs, loops, and human pauses.
Deployment model: library embedding, CLI, API server, local UI, self-hosted workers, containers, or managed agent runtime.
Maturity evidence: explicit preview labels, documented limitations, release state, migration constraints, and operational caveats.

This is a documented-capability and architecture comparison. No common agent workload, failure injection suite, security assessment, latency benchmark, cost model, or usability study was run across all five systems. The systems are also not strict substitutes: some are lightweight SDKs, some are opinionated harnesses, and some combine application libraries with workflow or hosted deployment products.

Comparative Analysis Table

System	Runtime and extension model	State and tool model	Policy, isolation, and operations	Best fit	Main limitation
DeepSeek Harness	Cordis plugin tree; model adapters, tool registry, session log, agent interface, default loop, telemetry, persistence, sandbox, approvals, and UI are replaceable from configuration	Append-only durable session-event log projects model history; scoped tool registry; plugins for models, filesystem, shell, terminals, jobs, subagents, MCP, goals, and commands	Tool execution waterfall and approval policy; swappable sandbox and filesystem providers; local Web UI and headless profiles; optional OTel session export with deployment-owned redaction	Teams researching a deeply composable, local-first harness where product subsystems and the loop itself must be replaceable	Explicit developer preview with compatibility-breaking changes; new ecosystem and limited public production evidence
OpenAI Agents SDK	Lightweight `Agent` and `Runner` loop with lifecycle hooks, model adapters, tools, handoffs, guardrails, sessions, tracing processors, and Python or TypeScript APIs	Function, hosted, MCP, agent-as-tool, and computer-related tools; conversation sessions; separate Sandbox Agent manifests, capabilities, sessions, snapshots, skills, memory, and workspaces	Human-in-the-loop approvals and guardrails; selectable local, Docker, or hosted sandbox clients; built-in tracing with third-party processors	Application teams wanting concise multi-agent primitives, broad model access, integrated tracing, and optional workspace agents without adopting a graph engine	Standard runner is not a durable business-workflow runtime; Sandbox Agents are beta and isolation strength depends on the selected client and deployment
Claude Agent SDK	Claude Code agent loop embedded through Python or TypeScript; the SDK supervises a bundled `claude` subprocess; extensions include hooks, subagents, MCP, permissions, skills, commands, memory, and local-path plugins	Built-in file, shell, edit, search, and web tools; JSONL transcript sessions; resume and fork; custom in-process MCP tools; local working-directory artifacts; optional transcript `SessionStore`	Permission evaluation and deterministic lifecycle hooks; recommended container or stronger sandbox isolation; one subprocess per active session; production hosting guidance covers egress, tenants, resources, and observability	Coding, research, and computer-like agents that benefit from a complete prebuilt tool environment and Claude Code’s loop	Claude-centric model path; subprocess and local-state architecture raises hosting cost and isolation duties; transcript mirroring does not persist every memory file or artifact
Google ADK 2.0	Agent plus graph-based Workflow runtime; Runner-driven event loop; Task API; global runner plugins and local callbacks; Python, Java, Go, TypeScript, and Kotlin implementations at different maturity levels	Session, artifact, and memory services commit event actions and deltas; function, OpenAPI, MCP, Google, and custom tools; multi-agent hierarchies and deterministic workflow nodes	Plugins can enforce policy around agent, model, and tool lifecycle; tool confirmation; logs, metrics, traces, eval UI; local CLI/UI/API server and Cloud Run, GKE, or Agent Runtime deployment	Polyglot teams needing explicit workflows, broad tool integration, evaluation, and a path from local development to Google-managed deployment	Capability and API parity vary by language; ADK 2.0 introduced breaking agent, event, and session-schema changes; managed deployment adds cloud coupling
Microsoft Agent Framework Harness	Batteries-included Harness assembled from Agent Framework chat clients, pipelines, agents, context providers, middleware, decorators, and workflows; Python and .NET, with partial Go support	Per-service-call history persistence; sessions; compaction; todo and mode providers; file memory; skills; web search; shell tools; background agents; MCP and broad model-provider integrations	Standing and automatic tool approvals; OpenTelemetry enabled by default in the Harness; middleware; optional bounded looping; Foundry hosting and durable extension paths	Enterprises wanting an opinionated long-task harness plus typed middleware, graph workflows, provider flexibility, and Microsoft hosting integrations	Some higher-end Harness capabilities remain experimental or pre-release; full production behavior spans several packages and hosted-service choices

Observed Profiles

DeepSeek Harness: replace the product by recomposing plugins

DeepSeek Harness is the strongest expression of “everything is a plugin” in this comparison. Its architecture documentation states that model adapters, the tool registry, session log, agent loop, persistence, sandboxing, approvals, telemetry, credentials, settings, and interfaces are mounted into a Cordis context. Plugin registrations are reversible effects that unwind when a plugin unloads, and configuration layers can replace rows without patching a privileged core.

That structure is more extensive than a conventional tool-plugin system. A profile composes ordered bundles and patches. The base bundle provides the foundational agent capabilities; Web and headless bundles add different interfaces. An operator can dump the effective plugin tree, replace a model provider, add or remove a capability, substitute the loop, or scope registrations to one agent preset.

The runtime uses an event-oriented distinction between durable session events and live interception events. A turn can contain multiple steps; each step includes one model request and the tools it calls. Durable events record turn, step, user, assistant, and tool activity. Waterfall events around pre-step processing, model requests, streams, and tool execution let plugins transform, reject, or delegate behavior in flight.

The append-only session log is architecturally important. DeepSeek documents the invariant that model-visible input must be reconstructable from the log. Model history, resume, forks, transcripts, persistence, UI, and telemetry derive from the same event stream. That creates a strong audit and replay substrate, but it is not automatically equivalent to a durable external transaction log: a remote tool may still complete when the local process fails before recording the result.

Capability seams separate service definitions, providers, and consumers. A filesystem or subprocess provider can move command execution into a remote sandbox without requiring model-specific forks. Similar seams exist for subagents, terminals, jobs, tools, and telemetry. This is useful for operators who need to replace infrastructure under a stable model-facing capability.

The principal caution is maturity. The repository labels DeepSeek Harness a developer preview, explicitly warns of compatibility-breaking changes, and had no tagged GitHub release at the review snapshot. The architecture is publication-worthy because it makes replaceability unusually explicit, not because public evidence establishes production reliability.

OpenAI Agents SDK: a small runner core with optional workspace infrastructure

OpenAI Agents SDK centers on a small set of concepts: an agent with instructions and tools, a runner that executes the loop, tools and handoffs for delegation, guardrails, sessions, and tracing. The Python repository describes the SDK as provider-agnostic across OpenAI APIs and third-party models, while the documentation also exposes extension points for lifecycle hooks, custom tracing processors, model adapters, session backends, and tool execution.

This small-core design has practical value. An application can begin with one Agent and Runner, then add typed function tools, MCP servers, agent-as-tool delegation, handoffs, human approvals, or guardrails without first committing to a graph representation. Tracing is integrated into the runner lifecycle and can be exported through processors.

The separate Sandbox Agent layer changes the operational profile. Sandbox Agents attach a manifest, capabilities, and a sandbox run configuration to the ordinary runner. They can stage repositories and files, expose filesystem editing and shell tools, load skills, preserve memory, and reconnect to a prior sandbox session or snapshot. The sandbox client is an interface rather than one fixed provider: current documentation includes Unix-local development, Docker, and hosted backends.

That separation is sound because not every chat or API agent needs a mutable workspace. It also means “uses OpenAI Agents SDK” does not state the isolation guarantee. A Unix-local sandbox on a developer machine, a Docker client, and a hardened hosted sandbox have different kernel, filesystem, network, identity, and tenant boundaries. The selected client and manifest policy are part of the security architecture.

The standard runner preserves and manages agent conversation state but should not be mistaken for durable orchestration of an external business process. If a tool sends an email, charges a customer, or deploys code, the application still needs an operation ID, remote-result reconciliation, bounded retries, and recovery logic. A session can remember that an action was attempted without proving whether the remote system committed it.

OpenAI labels Sandbox Agents beta. Buyers should version the SDK, test runner and sandbox upgrades separately, and require explicit fallback behavior when a sandbox or hosted tool becomes unavailable.

Claude Agent SDK: a complete agent environment with an explicit process model

Claude Agent SDK exposes the same agent loop, context management, and tool environment that power Claude Code. The documented capability set includes file reads and writes, editing, shell commands, web search, hooks, subagents, MCP, permissions, resumable and forkable sessions, skills, commands, memory, and plugins that package several extension types together.

The hosting model is unusually explicit. A self-hosted SDK call spawns and supervises a separate claude process and communicates over standard I/O. One active session maps to one subprocess. The process owns a shell, working directory, and JSONL transcript files. This is more than an HTTP client and materially affects concurrency, memory, disk, scheduling, shutdown, and tenant isolation.

Anthropic’s hosting guidance distinguishes ephemeral, long-running, hybrid, and multi-agent container patterns. By default, transcript files, memory files, and workspace artifacts live on local disk. A SessionStore can mirror transcripts to durable storage and restore them on another worker, but it does not automatically persist CLAUDE.md memory or arbitrary workspace artifacts. Documentation also describes mirror failures as observable but non-fatal, so teams with strict durability requirements must test loss and retry behavior rather than assume the store is a transactional ledger.

Permissions and hooks are useful enforcement points. An allowed_tools entry pre-approves a tool; it does not remove unlisted tools from the available toolset. Blocking and approval behavior depends on the full evaluation order, including disallowed tools, permission mode, and host callbacks. Pre-tool hooks can deterministically deny or modify execution, but the hook itself must run in a trusted host boundary.

The tool-rich default makes isolation a first-order requirement. Anthropic recommends sandboxed containers or stronger mechanisms for process isolation, resource limits, network controls, and ephemeral filesystems. Production guidance also recommends egress proxies, destination allowlists, credential injection, and per-session working directories.

The SDK repositories expose open-source components, while the official overview states that use of the Agent SDK is governed by Anthropic’s Commercial Terms except where a component has separate license terms. Procurement should therefore review both repository licenses and service terms instead of treating a package license as the entire commercial contract.

Google ADK 2.0: agents plus an event-committing workflow runtime

Google ADK 2.0 combines an agent abstraction with a graph-based Workflow runtime. The repository documents routing, fan-out and fan-in, loops, retry, state management, dynamic nodes, nested workflows, human-in-the-loop behavior, and a Task API for structured delegation. ADK supports several languages, although version labels and capabilities differ across Python, Java, Go, TypeScript, and Kotlin.

The event loop gives ADK a clear state-commit boundary. Agent logic yields an event; the Runner processes it, commits state or artifact deltas through services, forwards it upstream, and only then resumes the agent logic. That ordering lets subsequent logic observe committed session state rather than an unpersisted local mutation. It also gives interfaces and plugins a stream of structured runtime facts.

ADK distinguishes callbacks scoped to a particular agent or tool from plugins registered once on the Runner. Global plugins can observe or intercept agent, model, and tool stages for tracing, metrics, policy, caching, and request or response modification. That is a useful enterprise seam because enforcement should not depend on every agent author remembering to attach the same callback.

The tool surface includes custom functions, OpenAPI, MCP, and Google ecosystem integrations. Tool confirmation provides a human-interaction flow, but the confirmation record still needs to bind to the reviewed tool, canonical arguments, user, policy, and expiration. A modified call after approval should require a new decision.

Deployment options range from local CLI, Web UI, and API server to Cloud Run, GKE, and Google Cloud Agent Runtime. The managed Agent Runtime can reduce infrastructure work and connect ADK to Google governance and scaling services, but the application code and dependencies are uploaded to that environment and pricing or platform coupling becomes part of the selection.

ADK’s breadth creates migration risk. The 2.0 repository warns of breaking changes to the agent API, event model, and session schema, including compatibility boundaries with earlier 1.x sessions. Operators should retain representative session fixtures, event consumers, plugin tests, and deployment smoke tests across upgrades.

Microsoft Agent Framework Harness: a batteries-included composition over framework primitives

Microsoft defines an agent harness directly as runtime scaffolding that drives model and tool calls, manages conversation state and context, applies approvals, and progresses through a multi-step task. Its Harness is not a separate runtime so much as an opinionated composition of Agent Framework components.

The composition includes a chat client, function-invoking pipeline, per-service-call history persistence, optional compaction, agent and context providers, middleware and decorators, and an application interface. Defaults include todos, plan and execute modes, session file memory, tool approval, OpenTelemetry, and web search where the model client supports it. Skills, shared file access, shell execution, child agents, and evaluator-driven loops can be added according to language and package maturity.

This design offers a useful middle ground. Teams can start with a complete long-task agent instead of assembling every context provider and middleware component, while the returned object remains an ordinary Agent Framework agent. The same session, provider, middleware, workflow, and hosting abstractions can be used outside the Harness.

Microsoft also draws important boundaries. Background agents are different from provider-managed background responses: one delegates work to child agents, while the other polls or resumes a provider request. The Harness terminal interfaces in the repository are samples, not a prescribed shipped product UI. Go does not yet have the same packaged Harness, and several Python additions remain experimental or pre-release.

OpenTelemetry being enabled by default improves operational visibility but should trigger a data-flow review. Teams must identify which prompts, messages, tool arguments, file content, errors, and identifiers enter spans, where exporters send them, how sampling works, and which tenant or support roles can query the backend.

Microsoft Agent Framework is strongest when buyers want both an opinionated harness and explicit workflows, typed middleware, provider adapters, Foundry hosting, or durable extensions. The cost is a larger package and service surface whose maturity must be assessed component by component.

Runtime Boundary Analysis

Loop versus workflow

A model-driven loop asks the model what to do next until a stop condition is reached. A workflow declares at least some control flow outside the model. OpenAI and Claude emphasize prebuilt loops; DeepSeek makes the loop replaceable; Google and Microsoft make graph or functional workflows adjacent first-class concepts.

Use a loop for open-ended investigation, coding, research, and interaction. Use an explicit workflow for regulated sequencing, deterministic fan-out, service coordination, deadlines, and compensation. Many production systems need both: a bounded agent loop inside one durable workflow step.

Transcript versus state machine

A transcript records what the user, model, and tools said. A state machine records which business step is committed, pending, failed, or compensated. DeepSeek’s event log and Google’s event-service model are richer than a plain message list, while Claude and OpenAI expose additional session and workspace state. None removes the need to model remote side effects explicitly.

For every consequential tool call, store a stable operation ID before execution, record the canonical arguments and authority, reconcile uncertain outcomes with the remote system, and make retries idempotent. Do not infer transaction state solely from the last assistant message.

Extension versus enforcement

A callback that can observe a tool call is not necessarily an enforcement boundary. Enforcement code must run outside the model’s authority, fail closed, receive canonical arguments, and be difficult for untrusted plugins or tools to bypass. Extension packages should have declared permissions and provenance; a plugin that can replace the loop, filesystem, or telemetry exporter is privileged code.

DeepSeek’s broad replaceability is operationally powerful precisely because plugins can affect high-trust seams. Google Runner plugins, Microsoft middleware, Claude hooks, and OpenAI lifecycle or tracing processors can also access sensitive data or alter decisions. Treat runtime extensions like application dependencies, not prompt snippets.

Tool access versus execution isolation

Tool schemas determine what the model can request. Isolation determines what code can actually reach. A shell tool inside a host process, a local subprocess, a Docker container, a microVM, and a remote managed sandbox have different failure domains.

Require default-deny filesystem and network policy for untrusted tasks, short-lived credentials, explicit mounts, resource ceilings, destination controls, and audit logs. Keep cloud metadata, host sockets, orchestration credentials, and other tenants outside the agent execution boundary. Test whether allowed tools can reach equivalent capabilities indirectly through package managers, browsers, interpreters, or MCP servers.

Observability versus data governance

Agent traces are unusually sensitive because they can contain source code, customer documents, commands, tool outputs, API responses, prompts, and failed attempts. Trace completeness and privacy are competing requirements.

At minimum, define capture level, redaction point, exporter destinations, tenant partitioning, retention, sampling, deletion, support access, and incident backfill behavior. DeepSeek’s telemetry design documentation makes deployment-owned redaction explicit; Claude’s hosting model exposes transcript and process telemetry concerns; OpenAI, Google, and Microsoft make tracing easy to attach. In every case, operators—not the model—own the final export policy.

Selection Framework

Choose DeepSeek Harness when deep subsystem replaceability, local-first operation, event-sourced sessions, and plugin-based experimentation are primary goals, and the organization can tolerate developer-preview compatibility risk. Pin a commit, review every mounted plugin, and create migration tests before treating its log or configuration as a stable contract.

Choose OpenAI Agents SDK when the team wants a concise general-purpose agent API with tools, handoffs, guardrails, sessions, tracing, broad model support, and an optional sandbox workspace layer. Add a durable orchestrator when the agent participates in long-lived business processes, and evaluate the actual sandbox client rather than the interface name.

Choose Claude Agent SDK when the application benefits from a mature preassembled coding or computer-like loop with files, shell, web, subagents, MCP, hooks, skills, and resumable sessions. Budget explicitly for one-process-per-active-session hosting, durable transcript and workspace storage, sandboxing, egress control, and Anthropic service terms.

Choose Google ADK 2.0 when polyglot support, graph workflows, structured tasks, global plugins, Google integrations, local development surfaces, and a path to managed Agent Runtime are important. Pin language-specific versions and test event and session migrations because cross-language capability parity and 2.x evolution are not uniform.

Choose Microsoft Agent Framework Harness when a batteries-included research, coding, or data-analysis harness is desirable alongside framework-level middleware, sessions, workflows, OpenTelemetry, model-provider flexibility, and Microsoft deployment paths. Inventory which features are stable, experimental, pre-release, or hosted before using the default capability list as a production commitment.

For high-consequence systems, prototype at least two candidates against the same failure-oriented acceptance suite:

crash before and after a model call;
crash after a remote side effect but before local persistence;
resume on a different worker;
revoke a tool or credential during a session;
modify tool arguments after approval;
attempt cross-tenant session and workspace access;
attempt filesystem, network, metadata, and secret exfiltration;
overflow context, transcript, artifact, and trace limits;
upgrade the runtime while old sessions remain active;
export and reconstruct one run using only the approved audit data.

The winning harness is the one that meets the organization’s recovery, policy, isolation, and migration requirements with the least unowned behavior—not the one that completes the shortest demo.

Limitations

This analysis relies on public documentation and repository state available on 19 August 2026. These projects were changing rapidly, and feature labels, package versions, APIs, hosted services, model support, and compatibility guarantees may change after publication.

No equivalent workload was executed across all systems. The article does not measure task success, latency, token use, tool-call accuracy, recovery time, plugin overhead, trace completeness, cold starts, sandbox escape resistance, concurrency cost, or developer productivity.

The systems differ in scope. DeepSeek Harness is a complete plugin-composed application and SDK surface. OpenAI Agents SDK is a lightweight framework with an optional sandbox-agent subsystem. Claude Agent SDK embeds a prebuilt Claude Code-derived loop and tool environment. Google ADK combines agent libraries with workflows and deployment products. Microsoft Agent Framework offers both lower-level primitives and a composed Harness. A common table does not imply interchangeable semantics.

Public source code and documentation do not prove secure tenant isolation, correct authorization, reliable telemetry delivery, side-effect idempotency, data residency, or operational maturity. Those properties depend on deployment configuration, infrastructure, extensions, tool implementations, model providers, and organizational controls.

The comparison does not provide a legal review of open-source licenses, commercial terms, model-provider restrictions, third-party dependencies, trademarks, or hosted-service contracts. It also does not audit dependency vulnerabilities or software provenance.

Release recency and repository activity are not quality scores. DeepSeek’s lack of a tagged release and explicit preview warning are maturity signals, while a higher version number elsewhere does not guarantee stronger correctness or security.