Every Harness Will Become A Claw

What changes when the coding assistant you use locally becomes an agent your whole team can message in Slack? The model may still generate code, but the surrounding system must do more. Sam Bhagwat approaches that expansion as co-founder and CEO of Mastra, a TypeScript agent framework, drawing on roughly eighteen months of observing agents in production.

The starting landscape contains three kinds of building material: local harnesses used for everyday coding, cloud harnesses sold as products or built internally around Slack, and open-source frameworks that supply primitives for constructing either. The move beyond an agent loop is already visible in how people access and operate these systems.

Earlier discussions centered on agents versus workflows. A broader comparison is the spectrum of driving autonomy: lane assistance, Tesla FSD, and riding in a Waymo with nobody behind the steering wheel represent different degrees of responsibility delegated to a system. Bhagwat similarly arranges LLMs, agents, harnesses, and claws along an autonomy spectrum. Its successive qualities are action, durability, always-on operation, and eventually initiative and learning. These are useful architectural distinctions rather than standardized autonomy levels.

The first transition is from a single model response to an agent loop. The model can call tools, inspect results, retain memory, and retry a failed task. Context engineering determines what information it receives on each pass. Agent state carries the work forward instead of requiring every invocation to begin from nothing.

These capabilities belong together: a tool call lets the system act, while state lets a subsequent turn respond to what happened. A failed operation can become input to another attempt. That repeated, stateful interaction is the foundation on which a harness adds longer execution and richer control.

A harness adds durability and doggedness: the ability to keep pursuing a task through interruptions and over longer periods. Bhagwat describes work lasting hours or days as the intended capability, not a measured runtime result. His concrete recovery example is a connection lost during a turn: if streamed progress has been persisted, the session can resume from retained progress instead of starting over.

Planning mode and parallel subagents give that persistence a work structure. A harness can split a task and run parts concurrently. A terminal user interface, slash commands, and skills provide additional ways to direct it, while dynamically created agents avoid requiring every specialist to be defined in advance. Background batch tasks let work continue outside the foreground exchange. Automatic compaction handles a full context window, and persisted threads let a user return after disconnecting. Bhagwat uses Claude Code and Codex as familiar examples of this capability family; the list is not a version-specific guarantee for either product.

Live control changes the rhythm of interaction. Users can queue, steer, and interrupt while the system works. Bhagwat compares strict alternating turns to Civilization, where a player waits for the other civilizations to finish. Steering a running harness is closer to StarCraft or Age of Empires: new instructions can arrive while activity continues.

Permissions also acquire a longer lifetime. Approval can cover a session rather than a single tool call. Bhagwat’s joke about approving every invocation of rm -rf / exposes the danger: a broad permission can authorize destruction before there is any meaningful opportunity to reuse it. Session approval reduces repeated interruptions, but its scope has consequences.

The intermediate step toward a claw is an always-on harness, a shift Bhagwat says had become especially visible over the preceding few months. In a shared Slack conversation, several colleagues may give instructions to the same agent. The system must interpret those instructions using user metadata, rather than treating every message as if it came from one undifferentiated operator. Mobile access adds another entry point; an app may tunnel back to a harness running on a local machine.

Access and execution location are separate choices. A mobile interface does not necessarily mean cloud execution. When execution does move into cloud sandboxes, more resources can support more parallel subagents than one machine can accommodate.

The additional capacity requires a different architecture and brings the trade-offs of distributed systems. Moving to the cloud changes more than the address of the process.

The output path changes too. A coding harness may move from editing local files or a Git worktree to pushing work through a GitHub pull request. That makes the result available through the team’s shared development workflow. Adoption remains uneven: some developers still work entirely with local harnesses, while others are figuring out how cloud agents fit into their organizations.

The next transition adds initiative and learning. Consider an assistant that notices an apparently urgent email and texts its user to ask whether the message is actually urgent or just spam. The user did not begin this interaction. An external feed supplied something to examine, and the agent initiated contact. A heartbeat provides another trigger: the system wakes at a defined interval and decides whether something needs attention.

A small TypeScript example makes the distinction between noticing a message and resolving it explicit. Here, an urgent-looking email becomes a proposed question; its urgency remains unconfirmed.

type Email = {
  id: string;
  subject: string;
  urgentCandidate: boolean;
};

type PendingQuestion = {
  emailId: string;
  text: string;
  status: "pending";
};

function reviewInbox(emails: Email[]): PendingQuestion[] {
  return emails
    .filter((email) => email.urgentCandidate)
    .map((email) => ({
      emailId: email.id,
      text: `Is "${email.subject}" actually urgent, or is it spam?`,
      status: "pending",
    }));
}

const inbox: Email[] = [{
  id: "email-42",
  subject: "Urgent: confirm today's delivery",
  urgentCandidate: true,
}];

const pendingQuestions = reviewInbox(inbox);

A feed listener or periodic heartbeat could invoke this review. The result is a pending question, not a sent text or a confirmed emergency. That boundary preserves the uncertainty in the assistant example.

Channels make that initiative reachable through text, WhatsApp, or Telegram. Memory can live somewhere more accessible than simple file storage, while an always-running daemon or gateway handles incoming and outgoing requests. Together, these mechanisms let the assistant maintain continuity outside a terminal session.

Learning adds a feedback path from execution traces back into future behavior. A run can produce a reusable skill, or the system might modify the code that drives it. In this discussion, continual learning means adaptation through artifacts such as skills and code; it does not establish that model weights are being trained during use. Bhagwat emphasizes that the right method remains unsettled. Automatic modification is a mechanism to explore, not evidence that every modification improves the system.

Projects such as OpenClaw and Hermes Agent make these capabilities concrete enough that framework users begin asking for them. Bhagwat describes demand for their features with greater power and control: builders want more than installing a claw on a machine. They want primitives they can assemble into their own agents and harnesses. That demand shapes Mastra’s direction.

The progression now has a clear shape: action becomes durable, persistent work; that work becomes always available; availability gains initiative and learning. Bhagwat gives the resulting prediction the informal name Steinberger’s law, joking that he has not asked permission to use the name: “every harness will expand until it becomes a claw.” It is his forecast about where user demands lead, not an established technical law.

The pressure to expand is technological, economic, and psychological. Once a harness produces useful work, users want more ways to reach it: a Slack DM, a text message, or a request sent before bed so that a task runs overnight. Availability follows an existing desire to delegate.

Bhagwat calls the reward loop a “dopamine casino”: put in tokens and get out code—or other useful actions, since agents extend beyond programming. He credits Dex Horthy for the accompanying image. The appeal helps explain why users keep asking for broader access and greater autonomy.

But the expansion phase does not imply that every product survives. After systems become more powerful, Bhagwat expects a shakeout. To understand that second phase, the relevant constraint shifts from what a harness can do to how many services a person can keep using.

Android and iOS provide the analogy. Mobile platforms made directions, ride hailing, payments, and music available on phones. Video, browsing, food ordering, and accommodation booking expanded the range further; some activities migrated from desktops, while others emerged over the decade. A platform could support many categories without users adopting many competing products in each category.

Bhagwat points to Uber and Lyft as an example of people keeping a small set of familiar services. His explanation is limited mental space: even when alternatives exist, users can remember and return to only so many products. This is a consumer analogy, not a measured market-concentration result.

Two routes can keep a service relevant:

• High value when needed. Airbnb may be used only occasionally, but accommodation can matter a great deal at the moment of booking.
• Frequent use. Uber or DoorDash can recur often enough to remain readily available in a user’s mind.

Bhagwat contrasts these with Thumbtack, which he characterizes as less frequent and less valuable in this comparison. That is his assessment of perceived usefulness, not an independent valuation of the business. His proposed retention condition is that a product needs high economic value or high frequency; lacking both, it is easy to forget.

The same fading relevance happens with a college friend after a move or a change in careers and social circles. The relationship may once have mattered, yet fewer recurring circumstances bring that person to mind. The analogy explains why initial enthusiasm alone cannot sustain a product’s place in daily life.

Today’s excitement comes from turning tokens into useful results. Bhagwat expects categories to emerge as that excitement matures, leaving users with room for only a limited number of claws. More capable systems still compete for finite attention.

Builders therefore face an immediate obligation to keep learning what users need. If the pace of change accelerates, understanding the field must become more frequent too; this is the motivation behind Bhagwat’s appeal for events and continued learning. An agent that lacks newly expected capabilities risks replacement by a more powerful alternative.

Capability leadership does not remove the second risk. Even a product that reaches the top of its category must survive the consolidation that follows. Bhagwat places that possible shakeout in the later 2020s. The practical tension is to keep pace with expanding autonomy while building something valuable or frequent enough that users continue making room for it.