The agent harness is the product now

The AI market spent the last few years talking as if the model was the whole product. GPT versus Claude. Sonnet versus Opus. Open weights versus closed labs. Bigger context windows, cheaper tokens, faster inference.

The agent wave has made that framing too small. A model can be powerful and still feel useless if the system around it cannot load context, call tools, recover from errors, track work, or meet the user in the right place. The real product is increasingly the harness: the operating layer that turns a language model into something that can act.

That is why the progression from ClaudeBot and OpenClaw to Hermes Agent and Pi matters. The story is not only about a sequence of open-source projects. It is the story of the market discovering what an agent actually needs around the model, then discovering that too much harness can become its own problem.

What people mean by harness

In ordinary software, the word harness has a long history. A test harness runs code under controlled conditions and records the result. A benchmark harness fixes the environment so two systems can be compared. In machine learning, an eval harness became the infrastructure that feeds tasks to a model, captures outputs, and grades performance.

Agents stretched the term. Anthropic draws a useful distinction: an evaluation harness runs the tests, while an agent harness, also called a scaffold, is the system that enables a model to act as an agent. It processes inputs, orchestrates tool calls, and returns results. When you evaluate an agent, you are evaluating the model and harness together.

In practice, the harness is the loop. It decides what the model sees, what tools it can use, how tool outputs come back, how much context is retained, when to compact, when to stop, when to ask the user, when to retry, and how to preserve state across sessions. Two products can use the same underlying model and feel completely different because their harnesses make different decisions.

Anthropic made the pattern explicit

Anthropic's December 2024 essay on effective agents gave the category its operating principle: find the simplest solution possible and only increase complexity when needed. That sounds obvious, but it is the rule most agent products violate. Every new tool, planner, subagent, permission layer, memory store, queue, and reviewer looks defensible in isolation. Together, they can make the system harder to debug than the problem it is supposed to solve.

By late 2025 and early 2026, Anthropic's own long-running agent work had moved from simple loops toward explicit harness design: initializer agents, feature lists, progress files, git history, structured handoffs, Playwright-style QA, planner/generator/ evaluator roles, and sprint contracts. Those pieces existed because the models needed help staying coherent over long tasks.

The more interesting part came later. As models improved, Anthropic started removing pieces. Context resets became less necessary. Sprint decomposition became a candidate for deletion. Evaluators became situational rather than mandatory. The principle was sharp: every harness component encodes an assumption about what the model cannot do on its own, and those assumptions go stale.

A mature harness is not the biggest possible wrapper around a model. It is the smallest structure that makes the model reliable for the job in front of it.

ClaudeBot showed the demand

The consumer version of this story broke into the open with the project many people first encountered as ClaudeBot or Clawdbot. Public reporting used Clawdbot, and OpenClaw's own history centers the assistant persona Clawd, but the reason the name stuck in people's heads was clear: it was tied to Claude, and it promised an AI that did things rather than merely chatted.

Peter Steinberger had built the early assistant for himself, first as a personal project for managing digital life and experimenting with human-AI collaboration. The project then ran through a wild sequence of identities: Warelay, CLAWDIS, Clawdbot, Moltbot, and finally OpenClaw. The January 2026 trademark pressure from Anthropic forced the first major rebrand. Moltbot kept the space lobster theme. OpenClaw arrived days later as the more durable public name.

The naming mess mattered less than the product behavior. OpenClaw was not just a chat box. It was a local-first agent platform that ran on the user's machine, connected to messaging apps, carried state across sessions, and could use tools to act on the user's behalf. Telegram, WhatsApp, Discord, Slack, Teams, Signal, Matrix, email, and other surfaces became entry points into the same agent.

That was the unlock. OpenClaw showed that users did not only want better answers. They wanted an agent that lived where they already worked and messaged. The interface was not the website. The interface was the user's existing communication layer.

OpenClaw made the harness visible

OpenClaw's rise made the harness legible to a much wider audience. To make a model useful across chat apps, the project needed far more than a model picker. It needed channel adapters, session routing, local configuration, skills, memory, command approval, provider keys, security guidance, and enough operational structure to keep a long-running agent alive on a laptop, homelab, or VPS.

That breadth is why OpenClaw captured attention so quickly. It represented the agent as personal infrastructure. Your assistant, your machine, your data, your rules. It also showed the tradeoff: an agent that can manage email, calendar events, messages, files, browser sessions, and shell commands is powerful precisely because it is dangerous. Prompt injection, overbroad permissions, skill vetting, secrets, and misconfiguration stopped being abstract safety topics. They became deployment concerns.

Steinberger joining OpenAI in February 2026 made the split even clearer. OpenClaw was moving toward foundation stewardship and staying open and independent, while its creator went to work on bringing agents to a broader audience. That is the category in one sentence: the self-hosted harness proved the shape, but the mass market still needed a product that ordinary people could use.

Hermes Agent pushed richness further

Hermes Agent took the rich-agent side of the fork and pushed it harder. Its docs describe a system built around persistent memory, skills, scheduled automations, subagents, tool use, messaging gateways, voice, browser automation, and model/provider flexibility. It is not shy about being a full environment.

The most revealing detail is Hermes' OpenClaw migration path. The project ships commands and skills for migrating an OpenClaw setup: memories, persona files, command allowlists, user skills, model provider configuration, selected workspace assets, messaging settings, and secrets where they can be resolved. That migration path says something important about the market. OpenClaw users were not just running a bot. They had accumulated a customization footprint large enough to move.

Hermes is impressive because it accepts the full consequence of that footprint. If the agent becomes a persistent work environment, then it needs memory, skills, scheduling, subagents, voice, channels, provider configuration, and migration tools. But it also sharpens the counterargument. The more complete the harness becomes, the more users have to understand before they can safely benefit from it.

Pi answered with a smaller core

Pi.dev enters the story from the other direction. It is not trying to win by shipping the largest surface area. Its docs call Pi a minimal terminal coding harness designed to stay small at the core while being extended through TypeScript extensions, skills, prompt templates, themes, packages, custom models, and custom providers.

Mario Zechner's design notes are blunt. The default useful tool set is tiny: read, write, edit, and bash. Pi intentionally avoids built-in MCP, subagents, permission popups, plan mode, built-in todos, and background bash. If a workflow needs those things, it can add them through extensions, packages, files, containers, or external tools such as tmux.

That is not a lack of ambition. It is a harness philosophy. Keep the default loop understandable. Make state visible. Let planning live in files if it needs to persist. Let specialized tools be loaded only when they matter. Make custom behavior something the user can build, inspect, and version rather than something hidden inside a sealed orchestration layer.

Pi's popularity comes from that restraint. In a fast-moving model market, large harness features can age quickly. A permission model, planner, evaluator, memory system, or subagent abstraction that makes sense for one generation of models may become overhead for the next. A small core with strong extension points has a better chance of staying useful as the model layer changes underneath it.

The market is splitting

OpenClaw and Hermes prove one side of the market: serious users want agents with real reach. They want messaging apps, memory, skills, scheduling, files, browser control, and persistent identity. They want the agent to keep working after a single chat turn ends.

Pi proves the other side: serious users also want control over complexity. They do not want every workflow assumption baked into the product. They want primitives that compose, visible state, and an extension model that lets the harness grow only where the work demands it.

These are not opposite futures. They are the two pressures every agent product has to balance. Too little harness and the model cannot act reliably. Too much harness and the user inherits a system they cannot see through.

Where agentAnderson fits

This is the product lesson behind agentAnderson.ai. Most users do not want to begin by self-hosting an agent stack, choosing model providers, wiring channel adapters, protecting secrets, configuring memory, and debugging gateway state. They want the useful thing first: a simple agent they can talk to.

Then, when the work earns it, they want the harness to grow. Web chat should be enough for lightweight questions. Telegram should be available when the user wants the agent in a daily messaging surface. Slack or Discord should make sense when the context is a team or community. Conversation continuity, account state, hosted task workflows, and usage controls should appear as the relationship deepens, not as mandatory setup steps on day one.

That is the same architectural taste Pi represents, translated from a developer-owned terminal harness into a managed product: start with the minimum useful surface, keep the system understandable, and add capability only when the user reaches for it.

agentAnderson is not trying to make users carry OpenClaw or Hermes levels of machinery before they know they need it. It is trying to make the path from simple chat to real agentic work feel natural. The harness should be there when the task gets bigger. It should not make the first interaction feel like infrastructure.

The durable pattern

The next agent products will not be judged only by model choice. Everyone will have access to strong models. The difference will be the harness: how it loads context, exposes tools, manages state, handles safety, shows its work, preserves continuity, and adapts without drowning the user in configuration.

ClaudeBot and OpenClaw showed the hunger for persistent agents in everyday channels. Hermes showed how rich and portable that persistent agent environment can become. Pi showed the corrective: the harness should start small enough to stay yours.

That is the concept agentAnderson is building around. Do only what the user needs now. Grow when the work demands more. Keep the experience coherent as the harness gets deeper.

The harness is no longer background plumbing. The harness is the product.