Producing a code change is only one part of a coding task. An agent also needs to inspect the repository, run checks, interpret failures, and choose its next step. The system that manages those steps is the agent harness.

More than 30% of deployments on Vercel are initiated by coding agents. At that scale, the harness is part of the production environment. It governs where the agent executes, what it is allowed to do, and how it checks its work before review.

## [Copy link to heading](#model-and-harness)Model and harness

An agent harness is the software layer that turns a language model into a working coding agent. The model provides guidance on what to write. The harness supplies everything else, from file system access and command execution to the loop that keeps going until the work is done or the agent gives up.

That distinction changes how teams should evaluate a coding agent. Model quality alone does not tell you whether the agent can find the right code, use the right tools, or verify a fix. A team that compares agents by model name alone can mistake a harness problem for a model problem and choose the wrong tool.

On [Terminal-Bench 2.0](https://www.tbench.ai/?version=2.0), scores for the same Claude Opus 4.6 model span 18 points across nine harnesses, while scores for the same GPT-5.3-Codex model span 14. Those gaps reflect differences in the harness, including how it provides the model with context, invokes tools, and responds to test results. The model alone does not predict how well a coding agent will perform.

## [Copy link to heading](#how-an-agent-harness-works)How an agent harness works

An agent harness turns a model response into an iterative coding process. It gives the agent the context and tools to inspect a codebase, make a change, run a check, read the result, and decide what to do next. The loop continues until the work meets the task's completion criteria or requires human input.

The harness also controls the environment around that loop. Context management keeps relevant code and instructions available. Tools and MCP connections enable the agent to act within and beyond the repository, extending the same tool-calling model to external systems. Permissions and sandboxing limit what the agent can affect, while Git and deployment integrations make the result easier to inspect and verify.

Together, those design decisions determine whether the agent produces tested, reviewable work or leaves a developer to diagnose failures and manually validate the change.

## [Copy link to heading](#agent-harness-evaluation-criteria)Agent harness evaluation criteria

Choosing a harness comes down to four questions. What can the agent reach? How reliably can it work through a task? What limits its actions? And what does it hand back for review?

### [Copy link to heading](#what-can-the-agent-reach)What can the agent reach?

Model flexibility determines whether you can change providers without changing tools; tool support sets the boundary of what the agent can touch beyond the repository, and codebase understanding is what gets it to the right file in the first place.

### [Copy link to heading](#how-reliably-can-it-work-through-a-task)How reliably can it work through a task?

Context management governs whether a session holds together as the window fills, while edit-run-verify quality shows up as the share of finished work you still have to check yourself.

### [Copy link to heading](#what-limits-its-actions)What limits its actions?

Permissions and sandboxing limit the damage of a bad decision; local versus cloud execution puts the work on someone's machine and network; and autonomy determines how often the agent stops to ask.

### [Copy link to heading](#what-does-it-hand-back-for-review)What does it hand back for review?

Reviewable output is part of agent quality. A diff, a branch, a pull request, and a preview deployment give a reviewer different ways to validate the work. Choose the artifact that matches your team’s review process and the risk of the change.

Permission models are implemented and documented differently. One harness may spell out its filesystem, shell, network, and approval controls, while another relies on sandboxing, operating system permissions, or settings documented elsewhere. Missing detail is not proof that those controls are absent; it is a reason to verify the behavior in a trial or security review.

## [Copy link to heading](#open,-multi-provider-harnesses)Open, multi-provider harnesses

OpenCode, Goose, and Pi are open-source, multi-provider harnesses. Teams can bring their own provider credentials and switch models while keeping the rest of their agent setup in place. They differ in the level of functionality and control they provide out of the box.

[**OpenCode**](https://opencode.ai/) is an MIT-licensed terminal-first agent from Anomaly. It runs in the shell, edits files, executes commands, and works across a wide provider registry that covers many vendors' models. Because the source is public, teams can read exactly how context is assembled and how tools are invoked, which matters when debugging unexpected agent behavior in a large repository.

[**Goose**](https://goose-docs.ai/) is an Apache-2.0 agent originally built at Block and developed under the Agentic AI Foundation at the Linux Foundation. It runs as a desktop application, a CLI, and an API, works with 15+ model providers, and connects to external systems through MCP. This foundation-led governance prevents single-vendor lock-in and ensures community contributors steer the roadmap.

[**Pi**](https://pi.dev/) is a minimal MIT-licensed harness whose core stays small by design, extended through TypeScript extensions. Pi ships with defaults but skips features like sub-agents and plan mode, leaving them to extensions or packages. The project publishes example extensions for both. Pi's documentation states that it has no permission layer over the filesystem, processes, the network, or credentials, and that a session inherits whatever access the launching user already has. Teams that need stronger boundaries containerize or sandbox it.

Pi is a fit for teams that want to assemble their own agent workflow. Its minimal core leaves permissions, sandboxing, subagents, and plan mode to extensions or the surrounding environment, so the team takes on more setup and security responsibility.

## [Copy link to heading](#vendor-native-but-extensible-harnesses)Vendor-native but extensible harnesses

[**Claude Code**](https://claude.com/product/claude-code) is proprietary and designed around Claude models. Claude Code’s native subagents are configured around Claude models. A subagent can use `opus`, `sonnet`, `haiku`, `fable` or inherit the main session’s model. Other models can be exposed as external tools through an MCP server, command-line wrapper, or custom integration, but Claude Code does not natively route subagents across model providers.

[**Codex**](https://openai.com/codex/) is optimized for OpenAI models and more directly configurable around alternative providers. Its local configuration lives in `~/.codex/config.toml`, with project overrides in `.codex/config.toml`, and those layers set the default model and provider, approval policies and sandbox settings, and MCP servers. Codex also supports named permission profiles for filesystem and network policy, with built-in profiles of `:read-only`, `:workspace`, and `:danger-full-access`.

Its documented native subagents let you define custom agents with different model configurations and instructions for different tasks, which covers different OpenAI models and reasoning settings. Teams that need provider flexibility should use Codex’s local clients. They can connect to any model provider that supports the Responses API, and custom agents can override the parent session’s configuration. Codex cloud chats do not currently let teams choose the default model.

## [Copy link to heading](#integrated-development-platforms)Integrated development platforms

[**Cursor**](https://cursor.com/) combines an IDE, a CLI, and cloud agents. The agent is embedded in the editor a developer already has open, so suggestions arrive where the code is read and a human is usually one keystroke from intervening. The CLI supports the same modes as the editor, and a conversation started locally can be pushed to a cloud agent that keeps running unattended.

[**Devin**](https://devin.ai/) centers on managed, autonomous cloud execution. It runs as an AI software engineer in its own environment with a shell, an embedded IDE, and a browser, and it works toward a pull request. It also offers local interfaces, including a CLI with a `/handoff` command that sends longer tasks from a local session to cloud Devin.

Cursor and Devin handle more of the team's agent setup. That reduces the work needed to get started, but gives the team less visibility into and control over how the harness works.

## [Copy link to heading](#choose-based-on-how-the-harness-operates)Choose based on how the harness operates

Most coding harnesses now span multiple interfaces and environments, so their original category is a weak buying signal. Claude Code, Cursor, Codex, Goose, and Devin all span some mix of terminals, IDEs, desktop apps, and cloud environments.

The table below compares each harness by execution environment, autonomy, native model support, and licensing, so teams can see the trade-offs before narrowing a shortlist.

| Harness | Primary execution | Autonomy default | Native model support | License |
| --- | --- | --- | --- | --- |
| OpenCode | Local terminal, desktop, IDE | Human in the loop | Multi-provider | MIT |
| Goose | Local desktop, CLI, API | Human in the loop | Multi-provider | Apache-2.0 |
| Pi | Local terminal | Human in the loop, no permission gates | Multi-provider | MIT |
| Claude Code | Local terminal, IDE, desktop, cloud | Auto mode by default, configurable | Claude-native | Proprietary |
| Codex | Local CLI, IDE, cloud | Human in the loop, configurable | OpenAI-first, configurable providers | Apache-2.0 (CLI) |
| Cursor | IDE, CLI, cloud | Agent mode by default | Vendor-managed | Proprietary |
| Devin | Managed cloud | High, works toward a PR | Vendor-managed | Proprietary |

Use the table to match the harness to the team that will operate it. Teams that want more control should be ready to own permissions and sandboxing; teams that want more autonomy should choose a harness that returns work they can review and verify.

## [Copy link to heading](#choosing-a-harness-for-your-workflow)Choosing a harness for your workflow

If model choice and inspectability matter most, and someone on the team will own the configuration, use a multi-provider open-source harness.

Teams already standardized on Claude get the most from Claude Code, which brings Anthropic's native subagent, permission, and context-management features while still letting you call external models as tools. It accounts for 75% of agent-initiated deployments on Vercel, making it the most common harness behind those deployments.

Codex suits a team on OpenAI models that wants open local tooling, native multi-agent workflows, and configurable model-provider infrastructure.

Cursor fits developers who want the agent inside the editor they already have open. Devin fits work that should run autonomously in a managed cloud environment without depending on a developer's local machine.

Pi fits teams that want a small, inspectable core they can extend themselves, rather than a large set of built-in workflows. It gives teams more room to shape the agent loop, tools, and integrations around their own environment, but that flexibility comes with more implementation responsibility.

## [Copy link to heading](#closing-the-loop-with-a-deployment)Closing the loop with a deployment

Tests, builds, and pull requests can be enough for many coding tasks, but a preview deployment lets the agent inspect behavior that only appears when the application runs.

For web applications, those checks are often not enough, because a type check and a green test suite don't tell you whether a page renders, whether a route returns the right data, or whether a server function times out under a real request.

[Preview deployments](https://vercel.com/docs/deployments/environments) answer those questions because they give the agent a running instance to inspect. On Vercel, a connected Git repository creates one automatically when a commit is pushed to a non-production branch or a pull request is opened, once the project has had its first production deployment.

## [Copy link to heading](#deployment-paths-on-vercel)Deployment paths on Vercel

For most agent-driven changes, the target should be a Preview deployment. It gives the harness a unique URL to test the running application without affecting production. The team can then review the result before merging or promoting it.

A harness can create or access that preview in three ways:

- **Git integration.** The agent commits its changes and pushes a branch or opens a pull request. Vercel then creates the preview automatically. This fits teams that already use Git for review, and the agent can trigger a deployment without holding Vercel credentials.

- [**Vercel CLI**](https://vercel.com/docs/cli) or [**REST API**](https://vercel.com/docs/rest-api). The harness creates the deployment directly. The CLI fits terminal-based agents working from a local checkout; the API fits custom automation. Both require Vercel credentials with permission to deploy to the project.

- [**Vercel MCP**](https://vercel.com/docs/agent-resources/vercel-mcp). An approved MCP client connects through OAuth and uses Vercel tools directly. The harness can deploy source files, check deployment status, inspect build and runtime logs, and fetch a protected preview. This keeps deployment and diagnosis inside the same agent workflow.

The deployment path determines the permissions the harness needs. From the agent's perspective, Git-based deployment requires repository write access rather than direct Vercel credentials. CLI and API access give it direct deployment permissions. Vercel MCP uses the access of the person who authorizes the connection, so teams should enable human confirmation for changes to projects and deployments.

Vercel MCP currently supports Claude Code, Codex CLI, Cursor, Devin, Goose, Gemini CLI, and several other approved clients. A harness that is not on the list, including OpenCode or Pi today, can still use Git, the CLI, or the REST API. Vercel's [CLI workflows](https://vercel.com/docs/agent-resources/workflows) give command-line agents step-by-step sequences for deployment, debugging, and recovery.

Choose a deployment path based on the access you are willing to grant. Then ask whether the agent can use the preview to check its own work. An agent that can inspect the app and its logs, fix failures, and redeploy leaves less diagnosis for the reviewer.

## [Copy link to heading](#frequently-asked-questions)Frequently asked questions

**Is an agent harness the same as an agent framework?**

They overlap, but they aren't the same thing. A framework is a library for building agents into your own application, while a harness is the finished runtime a developer uses directly, with the tools and permissions already assembled. Some projects publish both.

**Do I need MCP to use a coding agent?**

No. The harnesses discussed here already include tools for working with files and running shell commands, which is enough for most coding tasks. MCP becomes useful when the agent needs to connect to systems outside the repository, such as a deployment platform or issue tracker.

**Can one harness use models from multiple providers?**

Yes, but support varies by harness. Open, multi-provider harnesses typically let you configure models from several vendors and may allow switching between them during a session. Vendor-native harnesses are usually more constrained: Codex exposes model-provider configuration locally, while Claude Code’s native subagent setup remains within Anthropic’s model ecosystem.

**How much autonomy should an agent be allowed?**

Match autonomy to what the agent can verify and what a mistake would cost. An agent that runs tests and inspects a preview deployment before it reports back can be given longer leashes than one that can't execute anything. Sandboxing changes the calculation, because an isolated environment like [Vercel Sandbox](https://vercel.com/sandbox) caps the damage of a wrong command rather than preventing it.