Best AI agents 2026: compared by what you can verify

The most useful thing you can know about an AI agent before you install it is where its tool calls execute and what it asks you before running one. Both are documented, both are checkable in an afternoon, and together they decide what a bad instruction can reach.

The eleven projects below are not peers. A terminal coding agent that lives in your repository, a chat-connected assistant that runs unattended, and a network-operations agent behind approval gates solve different problems and carry different exposure. So this page groups them and measures each against the boundary its own documentation claims, rather than ranking them against each other.

Every figure here was read from the project’s own repository, release feed or documentation on 17 August 2026, and each one links to the file it came from. Release tags and defaults move within days, so treat the linked source as authoritative and this page as a prompt to go and look.

What counts as an AI agent in 2026?

Two groups, and they are worth keeping apart.

Terminal coding agents run in a repository you already have open. The human is present, and the work arrives as a diff you review.

Project	Published by	Licence	Latest stable release, 17 Aug 2026
Claude Code	Anthropic	Proprietary, per LICENSE.md	v2.1.234, 17 Aug
Codex CLI	OpenAI	Apache-2.0	rust-v0.147.0, 7 Aug
Gemini CLI	Google	Apache-2.0	v0.55.1, 11 Aug
opencode	opencode, per its LICENSE	MIT	v1.18.18, 13 Aug
goose	Agentic AI Foundation	Apache-2.0	v1.46.0, 12 Aug
OpenHands	OpenHands contributors, per its LICENSE	MIT	v1.14.0, 17 Aug

Two notes on that table. “Published by” is what the LICENSE and README files say, which is not always the GitHub owner name: goose’s README states that “goose is part of the Agentic AI Foundation (AAIF) at the Linux Foundation”, while the repository sits under the aaif-goose org. And three of these paths have moved, so older links redirect: sst/opencode now resolves to anomalyco/opencode, block/goose to aaif-goose/goose, and All-Hands-AI/OpenHands to OpenHands/OpenHands.

Personal and autonomous agents run when you are not watching. They take input from a chat channel, a schedule or a queue, and the person who wrote the instruction may not be you.

Project	What it is	Licence	Latest release, 17 Aug 2026
OpenClaw	Self-hosted assistant and gateway. Its README says channels “bring the assistant to WhatsApp, Telegram, Slack, Discord, Google Chat, Signal, iMessage, and other messaging services”	MIT, per its LICENSE	v2026.7.1-2, 4 Aug, latest stable
Hermes Agent	Nous Research’s “self-improving AI agent”, Python, with a TUI and a gateway process for messaging platforms	MIT	v0.20.3, tagged v2026.8.16.2, 17 Aug
Vellum Assistant	”A personal AI assistant that evolves with you”, run locally or in containers	MIT	v0.11.3, 8 Aug
NetClaw	Network-engineering distribution, “Built on OpenClaw with Anthropic Claude, 222 skills, and 165 MCP integrations”	Apache-2.0	No tagged releases; last push 17 Aug
Netclaw	Unrelated to the above: self-hosted autonomous operations agent on Akka.NET, a netclawd daemon plus a thin netclaw CLI	Apache-2.0	0.25.4, 6 Aug; newest tag 0.26.0-beta.4, 12 Aug, pre-release

If you are still unsure what separates an agent from a model with tools bolted on, MCP vs agents settles that before you read on.

Why compare agents by trust boundary rather than features?

Because the features are converging and the boundaries are not. Every agent here plans, edits files, runs commands and speaks MCP. What differs is where the process that executes those commands sits relative to the rest of your machine.

Hermes Agent’s SECURITY.md heads section 2.2 “The Boundary: OS-Level Isolation” and opens it with this:

The only security boundary against an adversarial LLM is the operating system.

The same paragraph then refuses to count four things as containment: the approval gate, output redaction, pattern scanners and tool allowlists. Its reason is that any in-process component screening model output is, in its words, “a heuristic operating on an attacker-influenced string”.

Prompt filtering, approval dialogs and system-prompt hardening all live inside the agent process. They reduce mistakes. They do not contain an adversary who controls model output and therefore controls everything downstream of it running under the same user account.

Where does each agent actually run a tool call?

Most projects here can be sandboxed if you configure it, and what ships on first run is what most installations keep.

Project	Default execution location	What the project documents
OpenClaw	Host, for the main session	The README states: “Tools run on the host for the main session unless you configure sandboxing.” The sandboxing guide adds that “Sandboxing is off by default”, and that “The Gateway process always stays on the host; only tool execution moves into the sandbox when enabled”
Hermes Agent	Host, via the local backend	Seven terminal backends ship. Configuration describes local as “The default. Commands run directly on your machine with no isolation.”
Vellum Assistant	Host or container, declared per action	Trust rules carry an executionTarget of sandbox or host, per its security architecture. Containerised deployment is the sandboxed path: VELLUM_WORKSPACE_DIR is documented in gateway/src/paths.ts as “used in containerized deployments where the workspace is a separate volume”, with ~/.vellum/workspace kept only as a legacy fallback that logs a warning
Netclaw (netclaw-dev)	A separate daemon	The README describes a daemon, netclawd, that “hosts LLM sessions, runs tools, and handles persistence”, and a thin netclaw CLI that connects to it over a local socket. Its docs cover “audiences, approval gates, tool policies”
OpenHands	Host by default, with other backends offered	The README says “It runs locally on your machine by default”, and offers agent backends running in Docker containers, on VMs or on your own infrastructure
Claude Code, Codex CLI, Gemini CLI, opencode, goose	Varies by configuration and platform	Check the documentation for the version you install

Hermes Agent’s carve-out is the one most likely to be misread. Choosing an isolating terminal backend does not isolate the whole agent: SECURITY.md states that what backend isolation “does not confine” is “everything the agent does in its own Python process”, and names the code-execution tool, MCP subprocesses, plugin loading, hook dispatch and skill loading. If you are picking a backend for containment, that is the list to read twice.

OpenClaw’s default deserves the same attention for a different reason. Connect it to WhatsApp or Telegram and the text arriving in its context was written by whoever messaged you, and with sandboxing off a tool call resulting from that text runs on the host as your user. The project documents this plainly, and a bundled distribution built on top inherits it unless the distribution changes it.

What does each one ask you before it acts?

Vellum Assistant ships four risk tiers, named in threshold-presets.ts as Strict, Conservative, Relaxed and Full access. Conservative is the default, described there as “Auto-approve low-risk actions, like web searches and reading and writing files in its own workspace.” Classification runs gateway-side in a data-driven command risk classifier rather than being decided by the model in-loop, and each trust rule carries a Minimatch glob pattern plus a scope that is either a path prefix or the sentinel everywhere, so “this directory is trusted, everything else prompts” is a thing you can state.

Codex CLI exposes default_tools_approval_mode with four values, auto, prompt, writes and approve, documented as the “Default approval behavior for app tools without per-app or per-tool overrides”. The override worth using is mcp_servers.<id>.tools.<tool>.approval_mode, because a single blanket mode across a mixed tool set means the loosest tool sets the policy.

Gemini CLI supports a per-server trust flag, and its documentation says that when true it “bypasses all tool call confirmations for this server (default: false)”. The same page adds a --trust flag on gemini mcp add and warns to “Use cautiously and only for servers you completely control”.

OpenClaw publishes its security stance in a stated order: “Identity first”, then “Scope next”, then “Model last”, the last of which reads “assume the model can be manipulated; design so manipulation has limited blast radius”. Settling who is asking before what may be done is the right ordering for a product with a channel catalogue this long. Note that this is a design priority rather than the runtime filter chain, which is documented separately as “profile → provider profile → global policy → provider policy → agent policy → agent provider policy → sandbox → subagent”, where “Each level can further restrict tools, but cannot grant back denied tools from earlier levels.”

Hermes Agent documents the limit of its own gate in one sentence: “The gate catches cooperative-mode mistakes, not adversarial output.” An approval prompt shows you what the model chose to display.

An approval gate is a good defence against a model that is confused and a poor one against a model that has been instructed. That distinction is the whole of MCP prompt injection.

Which agents support MCP?

MCP client support is common enough now that its presence decides nothing. Transports, auth and whether MCP tools inherit the native tool policy still differ. All eleven projects are below, each cell linking the page or repository file it came from. Seven were read on 17 August 2026; the opencode, OpenHands and two Netclaw rows were read on 18 August 2026.

Project	Transports	Auth	Notable
Claude Code	stdio, SSE, HTTP and WebSocket, “though transport support may vary by server”. SSE is documented as deprecated	OAuth. The OAuth credential flags “only apply to HTTP and SSE transports”, and WebSocket auth is header-only	Answers roots/list with the launch directory plus each --add-dir working directory
Codex CLI	stdio, streamable HTTP	bearer_token_env_var, or OAuth by default	enabled_tools is an “Allow list of tool names exposed by the MCP server”; disabled_tools is a “Deny list applied after enabled_tools”
Gemini CLI	stdio, SSE, streamable HTTP	OAuth 2.0 on SSE and HTTP, triggered by a 401	Per-server trust bypasses confirmations
opencode	Two connection types, local, which is a command opencode launches, and remote, which is a URL. Neither the page nor the config schema names a transport beyond those two	headers, so a bearer token is written as an Authorization header, plus automatic OAuth: opencode will “Detect the 401 response and initiate the OAuth flow” and “Use Dynamic Client Registration (RFC 7591) if supported by the server”. Setting "oauth": false turns that detection off	”Your MCPs are available as tools in OpenCode, alongside built-in tools”, so the same glob-matched tools config and per-agent overrides that govern built-ins govern them
goose	stdio, and Remote Extension over Streamable HTTP	Per-extension OAuth, using Client ID Metadata Documents or Dynamic Client Registration, with client_id and client_secret_key overrides	”goose’s built-in extensions are MCP servers in their own right”
OpenHands	openhands mcp add --transport takes http, sse or stdio	--header carries a bearer token or an API key, and --auth oauth starts an OAuth flow. The web client’s credential strategies are none, api_key, bearer, basic, header and oauth2	The SDK guide uses an agent-level filter_tools_regex “to control which MCP tools are available to the agent”, and the CLI can add a server --disabled. Whether MCP tools follow the confirmation policy is not documented
Hermes Agent	stdio and HTTP, with transport: sse to opt into SSE instead of Streamable HTTP	OAuth 2.1, including discovery, PKCE and refresh	MCP sampling is “enabled by default for all MCP servers”
Vellum Assistant	stdio, sse, streamable-http, selected with -t on assistant mcp add	An OAuth provider, for sse and streamable-http only	Per-server defaultRiskLevel, which defaults to high, plus allowedTools and blockedTools
OpenClaw	”Streamable HTTP, SSE, or Stdio”	Per-server	Its docs state that MCP tools “go through the same tool-profile and tool-policy controls as everything else”, so “connecting a server does not bypass your policy”
NetClaw (automateyournetwork)	Whatever the runtime underneath provides: OpenClaw by default, Hermes optionally. Its own registrations live in config/openclaw.json, most of them a command plus args, a minority a remote url	Credentials are ${VAR} placeholders resolved from a shared .env, and remote entries may carry an Authorization header. Servers needing OAuth are not pre-registered at all: the guide files them as external, reason remote/OAuth	On a Hermes install scripts/openclaw-to-hermes-mcp.py translates the same mcpServers block into Hermes’ mcp_servers:, so one registry feeds two policy models. Its optional DefenseClaw layer lists “Component Scanning”, described in the README as “Skills, MCPs, and plugins scanned before execution”
Netclaw (netclaw-dev)	Transport is stdio, http, documented as “a remote MCP server over HTTP with streamable transport”, or sse for “servers that expose an SSE endpoint instead of streamable HTTP”	OAuth for HTTP and SSE servers through netclaw mcp auth <name>, with OAuthClientId and OAuthScope for “servers without dynamic registration”. Otherwise Headers, with the token held in a secrets.json the docs describe as “encrypted at rest”	Fail-closed by default: “New servers are fail-closed (blocked by default): all tools blocked for every audience until you grant them”, and each tool resolves to Auto, Approval or Deny per audience

Three things to take from this.

Whether MCP tools inherit native tool policy is the question to ask. OpenClaw and Vellum both answer it explicitly and in opposite styles: OpenClaw by stating that a connected server is still subject to your policy, Vellum by attaching a risk level and tool lists to each server entry, with a default risk of high that makes MCP tools prompt under every preset except Full access. Netclaw (netclaw-dev) answers it a third way, by starting from nothing: a newly added server is blocked for every audience until you grant its tools, and each granted tool carries its own Auto, Approval or Deny mode. Where a project does not say, assume MCP tools are governed separately from native ones and test it.

Hermes enabling MCP sampling by default is a real decision. Sampling lets a server ask your client to run a model completion, so a server can spend your tokens and put text of its choosing through your model. It is a legitimate primitive that inverts the usual direction of trust. MCP sampling covers what to check before you leave it on.

goose collapses two categories. Its extensions are MCP servers, so the supply-chain question about extensions is the supply-chain question about MCP servers, with no separate answer.

How does each agent keep credentials away from the model?

A credential the model can read is a credential that leaves in the next tool call. Three projects document a position.

Vellum Assistant brokers credential access through a CredentialBroker that “issues single-use tokens for policy-checked credential access” and “never exposes plaintext secret values”, with allowedTools and allowedDomains checked per credential. Its security architecture lists four invariants, of which the first two are “Secrets never enter LLM context”, because “secret values are never included in model messages, tool outputs, or lifecycle events”, and “No generic plaintext read API”, because “there is no tool-layer function to read a stored secret as plaintext.” That is the right shape: the secret is held outside the model’s reach and released per call against a declared scope.

Hermes Agent filters the environment it hands to lower-trust components, so that “Credentials like provider API keys and gateway tokens are stripped by default”. Its security guide goes further for MCP, passing only PATH, HOME, USER, LANG, LC_ALL, TERM, SHELL, TMPDIR and XDG_* through to stdio subprocesses. The project then says the quiet part itself, in SECURITY.md: “This reduces casual exfiltration. It is not containment.”

OpenClaw treats ~/.openclaw as sensitive, wants 700 on the directory and 600 on openclaw.json, and blocks provider credential variables and any OPENCLAW_-prefixed key from being set by an untrusted workspace .env file. Keeping credentials out of the workspace is the detail worth copying, because a workspace is exactly the tree an agent has been given permission to read.

For the rest, check before you assume. A secret in an environment variable is visible to every subprocess that inherits it, and a secret in a file inside the working directory is visible to any tool with read access.

Is OpenClaw the same thing as NetClaw?

No, and there are two different NetClaws.

OpenClaw was, in its README’s words, “built for Molty, a space lobster AI assistant, by Peter Steinberger and the community”. Its VISION.md records the name lineage: “It evolved through several names and shells: Warelay -> Clawdbot -> Moltbot -> OpenClaw.” The repository was created on 24 November 2025 and the project now sits under the OpenClaw Foundation, announced on 8 July 2026 as a non-profit “with a full-time team, world-class partners, and a mission to bring personal AI to everyone”. If you have seen the project under an older name, it is the same codebase.

NetClaw, first meaning: automateyournetwork/netclaw, published under the account of John Capobianco. Its README describes it as “A CCIE-level AI network engineering coworker. Built on OpenClaw with Anthropic Claude, 222 skills, and 165 MCP integrations”. Those two counts are exact, and the README says its dashboard recomputes them from the codebase on each open. OpenClaw is the default agent runtime and Hermes is offered as an alternative. Apache-2.0, no tagged releases, last pushed 17 August 2026. It is a distribution, not a fork of the idea.

Netclaw, second meaning: netclaw-dev/netclaw, published at netclaw.dev and unrelated to OpenClaw. Its README calls it “an open-source, self-hosted autonomous operations agent” built on Akka.NET, “the actor framework from Petabridge”, and closes with “Built with care by Petabridge”. It ships the netclawd daemon and the netclaw CLI, whose netclaw mcp subcommand is documented as “Manage MCP server profiles”. Its site, read on 18 August 2026, calls the product “MCP-first” with “Native Model Context Protocol support with OAuth”, and closes the page with “Built by the team behind Akka.NET”. Apache-2.0, 0.25.4 stable on 6 August with 0.26.0-beta.4 following on 12 August. Same name, different product, different ecosystem, different people.

Is Hermes an agent or a model?

Both, from the same lab, which is the confusion. Hermes Agent is Nous Research’s agent: Python, a TUI plus a gateway, seven terminal backends, MIT. Hermes 4 is Nous Research’s open-weight model family, whose 405B card describes “a frontier, hybrid-mode reasoning model based on Llama-3.1-405B by Nous Research”. An agent and a set of weights are not interchangeable, and a search for “hermes ai” returns both.

Is Vellum an assistant or an LLM development platform?

Both names are live under one brand, and the answer depends on which URL you landed on.

vellum.ai leads with Vellum Assistant, the personal agent described above, whose repository README calls it “A personal AI assistant that evolves with you.” docs.vellum.ai still documents the Vellum LLM development platform, and describes itself as offering “resources and support for prompt engineering, semantic search, agent orchestration, and more.” That is the commercial SaaS product.

That overlap creates one concrete trap. The platform documentation mentions MCP only as a way to read the docs themselves, through a docs MCP server, so it is easy to conclude the assistant has no MCP support. The CLI says otherwise: assistant mcp add configures servers over stdio, SSE or streamable HTTP, with an OAuth provider and a per-server risk level. If you are checking MCP capability here, read the CLI help rather than the docs index.

What should you check before you install any of them?

Five checks, in the order that changes your decision fastest.

• Read the LICENSE file, not the badge. OpenClaw’s LICENSE is a plain MIT licence, plus a line pointing at THIRD_PARTY_NOTICES.md, which is enough to make GitHub’s licence detector report NOASSERTION for the repository. Claude Code goes the other way: GitHub detects no open-source licence, but LICENSE.md exists and reads ”© Anthropic PBC. All rights reserved. Use is subject to Anthropic’s Commercial Terms of Service.” A detector result is not a licence, in either direction.
• Read SECURITY.md and look for a stated boundary. Hermes Agent names its boundary in one sentence and tells you what falls outside it. A project with no stated boundary has not necessarily got a weak one, but you now have to determine it yourself.
• Check whether sandboxing is on by default, not whether it exists. Install it and look, because the answer changes between releases and the shipped default is what most deployments run.
• Check what a bundled distribution pulls in that you did not choose. automateyournetwork/netclaw ships 165 MCP integrations on top of its base runtime. Every one is a dependency you did not evaluate, arriving with the base agent’s execution defaults.
• Score the servers, not just the agent. The agent sets the boundary; the servers decide what crosses it. The directory scores the components published in the official registry, marking anything it cannot verify as inconclusive rather than guessing, and how we score sets out the rubric behind the number.

Where to go next

• What an agent actually is, and how it relates to the protocol: MCP vs agents.
• Choosing the servers rather than the agent: best MCP servers.
• The same trust-boundary test applied to two other decisions: MCP vs Skills and MCP vs CLI.
• What the current spec revision deprecated, and why several client features above are on that list: MCP 2026-07-28.
• Why Hermes enabling sampling by default is worth a second look: MCP sampling.
• The live scores for everything you are about to connect: the directory.

Pick the agent by the boundary you are willing to run behind, then spend the saved time on what you connect to it.