The AI Agent Harness Era: Every Harness Becomes a Claw

Eighteen months ago the interesting argument in AI engineering was agents versus workflows. Today the thing you actually drive all day is neither — it is a harness: a durable, resumable, interruptible machine that runs for hours, spawns sub-agents, compacts its own context and leaves you a pull request in the morning.

And harnesses do not sit still. At AI Engineer in July 2026, Sam Bhagwat — co-founder and CEO of Mastra, the TypeScript agent framework, and author of Principles of Building AI Agents — gave that trajectory a name and a prediction: every harness will expand until it becomes a claw. He called it Steinberger's law, after Peter Steinberger, whose OpenClaw made the always-on personal agent a mainstream object. The prediction has an uncomfortable second half, which is the part most people skipped: after the expansion comes a shakeout.

TL;DR — An AI agent harness is everything wrapping the model: loop, tools, memory, durability, interface. Harnesses climb a ladder — LLM → agent → harness → claw — gaining durability and doggedness, then always-on presence, then initiative and self-improvement. Steinberger's law says every harness expands until it reaches the top, and that the field then consolidates the way mobile apps did in the 2010s. The strategic consequence: do not let your knowledge live inside the harness, because you will change harnesses. Keep it as plain markdown in a store every harness can reach — that is what MDflow is. Start free.

What is an AI agent harness?

An AI agent harness is everything around the model that is not the model — the agent loop, the tools and their permissions, memory and context assembly, retries, state persistence, scheduling, and the interface you drive it through. The formula that stuck in 2026, popularised by Mitchell Hashimoto, is simply agent = model + harness. Claude Code, OpenAI Codex, Cursor and OpenClaw are harnesses. So is the internal coding agent your platform team wired into Slack.

The reason the term earned its own discipline — harness engineering — is that two teams pointing the identical frontier model at the identical task now get very different results, and the difference lives entirely in the wrapper. As Bhagwat put it, we are somewhere on an agentic spectrum, the way self-driving has levels: lane assist and an empty driver's seat are the same technology at different rungs.

Here is the ladder from his talk, with the qualities that get added at each step.

The jump worth dwelling on is agent → harness, because it is where "doggedness" appears — a friend's word that Bhagwat borrowed, and the right one. A harness that loses its connection mid-turn resumes from the persisted stream. One that runs out of context compacts and continues. One that hits a wall spawns four sub-agents at it. You are no longer taking turns with the model like a game of Civilization; you queue, steer and interrupt while it works.

From local harness to always-on claw

The transition happening right now is local → cloud, and it changes where your agent's state lives. A local harness runs on your laptop against a git worktree. A cloud harness is always on: you talk to it in Slack, possibly alongside colleagues whose instructions it must disentangle; it runs in cloud sandboxes, which buys more parallelism than your machine can; and its output arrives as a PR rather than files on disk. That is a distributed-systems trade, with all the usual consequences — more power, different architecture, and state that can no longer be assumed to be sitting on one filesystem.

The final rung is the one OpenClaw made concrete. Launched by Steinberger in November 2025 and now past 385,000 GitHub stars, it is an open-source, local-first personal agent runtime, and its architecture is a clean reference implementation of "claw":

• A gateway runs as a background daemon and routes messages in from whatever channel you use — iMessage, WhatsApp, Telegram — resolving identity, session and policy before the loop runs.
• A heartbeat wakes the agent on a schedule (30 minutes by default) rather than waiting for you. It reads a checklist, decides whether anything needs action, and either messages you or reports that nothing does.
• Memory is files. Identity, long-term memory, skills, heartbeat rules and tool policies live in a workspace directory as ordinary markdown and YAML — SOUL.md, AGENTS.md, HEARTBEAT.md, MEMORY.md. The agent is instructed to write to them whenever it learns something worth keeping, on the entirely correct theory that mental notes do not survive a restart but files do.

That third bullet is the most important design decision in the whole category, and we will come back to it.

Steinberger's law and the shakeout nobody plans for

Steinberger's law has two halves, and the second one is the strategically interesting one. The first half — harnesses expand — is barely a prediction at this point; it is a description. They expand because we want them to. We want to DM them in Slack, kick off overnight tasks before bed, and get the small hit of putting tokens in and getting work out. Every harness vendor is shipping toward the same feature set because users keep asking for the next rung.

The second half is the shakeout. Bhagwat's analogy is the 2010s mobile platform era: iOS and Android opened dozens of categories at once — directions, rides, payments, music, short video, documentaries, food delivery, accommodation — and almost every one converged on one or two apps that people actually kept. His explanation is not technical but cognitive. You only have room for a limited number of these things. A product persists if it is economically valuable when you use it (you may book Airbnb twice a year, but you really want it when you do) or if it is frequent (Uber, DoorDash, several times a week). If it is neither, it fades — not because it got worse, but because nothing kept surfacing it. It becomes the college friend you have not called in three years.

Claws are extremely expensive in attention. You give one system-level access, you route your messages through it, you let it act while you sleep. That is not a slot you fill five times over. So the same convergence should be expected here, and Bhagwat's advice to builders follows directly: keep pace with capabilities, because users will switch to whatever is more powerful, and assume there is another wave after the one you win.

For everyone using these things, the implication is different and rarely stated: you will change harnesses, probably more than once, and quite possibly not on your own schedule. Which raises the only question that really matters about anything you have taught your agent so far — where is it stored?

Why this matters for developers and AI agents

For developers, it turns a preference into an architectural decision. If harnesses converge and consolidate, "which harness should we standardise on?" is the wrong question to answer permanently; the right one is "what must survive us changing our mind?" Concretely: your conventions, your architecture decisions and their rationale, your runbooks, your specs, the correction someone made at 2am after an agent got it wrong. That content has a much longer useful life than any harness currently competing for it — a point we made in more depth in Your Agent Architecture Has a Half-Life of 6 Months.

Store it inside the harness and it inherits the harness's lifespan. Prompt files in one vendor's format, a proprietary assistant memory, a workspace directory on the laptop you are replacing — each is a container with a shorter half-life than the thing inside it.

For AI agents, it is about continuity across the rungs. A claw with a heartbeat is only as useful as what it can read when it wakes up at 3am with no human in the loop. A cloud harness in CI needs the same conventions your local harness follows, or it will confidently violate them. Sub-agents fanning out need a shared place to leave findings that outlive each child run. Every one of those needs is a read or a write against a store that is not the harness's own scratch space — which is exactly why OpenClaw's "write it to a file" instinct is right, and exactly why a path on one machine is not far enough.

Which applications benefit most

1. Personal always-on assistants — heartbeat-driven agents that triage mail, watch feeds and message you first. They accumulate preferences and corrections continuously, and lose all of it on a rebuild if memory is not external.
2. Team coding harnesses in Slack or CI — multiple humans instructing one always-on agent, which needs shared conventions rather than one engineer's local config.
3. Multi-harness shops — the common 2026 reality of Claude Code locally, Codex on another repo, a cloud harness for background work. One knowledge store, several harnesses, no per-tool copy.
4. Self-improving loops — agents that review their own traces and write back what they learned. The write target has to be durable and inspectable, or "continual learning" is just an unlogged mutation.
5. Long-horizon and background runs — hours-long work with no user watching, where the run's conclusions are worth more than its transcript.
6. Regulated or audited environments — where "show me what the agent read, what it wrote, and who was acting" is a requirement, not a debugging nicety.

How MDflow fits

MDflow is deliberately not a harness. It is the memory that outlives one. We are not competing with Claude Code, Codex, Mastra or OpenClaw — those are execution, and execution is exactly the layer Steinberger's law predicts will churn and consolidate. What we do is hold the content half: the documents your agents read before acting and write back to afterwards, in a form no harness owns.

What already lines up today

The claw pattern already runs on markdown — we just move it off one box. OpenClaw got the format exactly right and the location only half right: plain markdown files are the correct substrate for agent memory, and ~/.openclaw/workspace is unreachable from the cloud harness in your CI, your team's Slack agent, or your phone. MDflow stores the same plain markdown in a workspace every harness can reach, with a raw .md twin for every shared document — this post included, at /blog/ai-agent-harness-era.md. No proprietary block model, no export step.

Several open interfaces onto one store. A remote MCP server that Claude and the ChatGPT app connect to with an OAuth sign-in and no pasted token, while Cursor, Codex and Claude Code authenticate with a Personal Access Token; a plain HTTP API with an OpenAPI spec; a VS Code and Cursor extension; an n8n node for the automation steps that never needed a model; a Web Clipper; and an iPhone and iPad app. Multiple doors onto one room is the whole point — when one harness is replaced, the memory is still reachable through the others.

Retrieval built for agents, not for humans browsing. Every folder carries a description saying what its documents are for, and mdflow_get_context ranks those descriptions above folder names and titles — retrieval without a vector database, so nothing has to be re-embedded when the harness changes. Workspaces scope a query so a waking agent reads three relevant documents instead of thirty plausible ones.

Agents write back, and the writes are accountable. MCP write tools are real, so a claw that concludes something at 3am can record it in the workspace instead of losing it at session end. Version history and the document log record every change with the actor named — "automated · token name" for anything arriving over API or MCP — with a per-edit diff and restore, which is the difference between an agent that learns and an agent that silently overwrites. Body writes also refuse to empty a document unless the caller explicitly confirms it, because unattended runs are exactly where that mistake happens.

Scoping and privacy. Sharing, collections and comments control what a person, a client or an agent can see; client-side encryption covers the documents that should never be readable by anything but you — including by us.

Where we are headed

Direction, not a dated commitment: serving a whole collection to an agent as one cross-linked bundle, so a spec, its decision log and its glossary arrive together rather than as three retrievals; richer typed frontmatter so a document can carry status, owner and freshness as signals an agent can weigh when it wakes up; and tighter review round-trips for agent-proposed edits before they land.

The bottom line

Bhagwat is almost certainly right that harnesses keep climbing until they become claws, and probably right that the field then consolidates the way mobile did. Both halves point at the same practical conclusion, and it is not about which harness to pick.

Assume the harness is temporary. Make the knowledge permanent. Keep specs, conventions, decisions and corrections in plain markdown you own, reachable over open protocols, writable by the agent and auditable by you. Then the next rung on the ladder — or the next shakeout — costs you a migration of tooling instead of a case of amnesia.

Start free · Connect an AI agent · Read the API docs

Frequently asked questions

What is an AI agent harness?

A harness is everything wrapping the model that is not the model itself: the agent loop, tool definitions and permissions, memory and context assembly, retries, state persistence, scheduling and the interface you talk to it through. The formula usually quoted is agent equals model plus harness. Claude Code, OpenAI Codex, Cursor and OpenClaw are harnesses; so is an internal coding agent your company runs in Slack. Two teams using the identical frontier model can get very different results because the harness differs.

What does "every harness will become a claw" mean?

It is the thesis of a July 2026 AI Engineer talk by Sam Bhagwat, co-founder and CEO of Mastra. A claw is a harness that has crossed two more thresholds: it is always on, and it has initiative and learning. It listens to external feeds, wakes on a heartbeat rather than waiting to be prompted, reaches you through channels like Slack or WhatsApp, keeps memory somewhere accessible, and improves itself from its own traces. Bhagwat named the pattern Steinberger's law, after Peter Steinberger, creator of OpenClaw: every harness will expand until it becomes a claw.

Why does Steinberger's law predict a shakeout?

Because attention is the binding constraint, not capability. Bhagwat's analogy is the 2010s mobile platform era: dozens of categories opened at once, and almost every one converged on one or two apps people actually kept. A product survived if it was economically valuable or used frequently, and faded if it was neither. Claws are expensive in attention — you talk to them daily and trust them with real work — so most people will end up keeping only a small number, and the ones they abandon will take whatever was stored inside them along too.

Where should an always-on agent keep its memory?

Outside the harness. The local-first pattern that OpenClaw popularised is already the right format — identity, memory and skills as ordinary markdown files in a workspace directory — but the wrong location once you run more than one harness. A file at a path on one laptop cannot be read by the cloud harness in your CI, the agent in your team's Slack, or the harness you switch to next quarter. Keep the same plain markdown in a store reachable over an open protocol, so every harness reads and writes the same memory.

Is a knowledge base a harness or part of one?

Neither, and that distinction is the point. A harness is execution — the loop, the tools, the scheduling, the interface. A knowledge store is the durable content those runs read from and write back to. Coupling the two is what makes switching harnesses cost you your institutional memory. MDflow is deliberately only the second half: markdown documents reachable over MCP, an HTTP API, a VS Code extension and an n8n node, so the harness on top stays swappable.

Further reading

• AI Engineer — Every Harness Will Become A Claw, Sam Bhagwat, co-founder and CEO, Mastra
• Mastra — Principles of Building AI Agents
• GitHub — openclaw/openclaw, the open-source always-on personal agent
• Addy Osmani — Agent Harness Engineering
• MDflow — Your Agent Architecture Has a Half-Life of 6 Months · Portable AI Memory · Context Engineering for AI Agents · Folder Descriptions as Agent Context · MCP documentation · API documentation