A rare x-ray of a frontier coding agent—and why the real story is the harness, not the model

The accidental leak of Claude Code’s TypeScript source was instantly treated as a spectacle: a top-tier AI company shipping its own internals to the public by mistake, the community pouncing on the package within hours, mirrors spreading everywhere, and social media doing what social media always does when blood is in the water. But the real importance of the incident lies somewhere else.

For once, the industry got to peek behind the curtain of a production-grade coding agent—not the model weights, not the training data, not the secret sauce of pretraining, but something arguably more important for the next phase of AI systems: the product-layer machinery that turns a language model into a long-running, tool-using, semi-autonomous software worker.

Multiple outlets reported that the leak came from an npm release of @anthropic-ai/claude-code in which a large JavaScript sourcemap file was mistakenly included, allowing observers to reconstruct the original TypeScript source. Anthropic said the incident was caused by human error in packaging, not by a breach, and that no customer data or credentials were exposed. Reports consistently placed the exposed codebase at roughly 512,000 lines spanning around 1,900 files, enough to give outsiders a surprisingly detailed view of Claude Code’s architecture and internal product logic.

That distinction matters. This was not a model leak. It was not the release of frontier weights, and it did not suddenly flatten the underlying capability gap between labs. What leaked was the executable skeleton around the model: the code that manages context, orchestrates tool use, enforces permissions, carries state forward, and makes an agent viable over many steps instead of one. In other words, what leaked was not the “mind” of the system, but something closer to its nervous system, musculature, and operating discipline.

That is why the event matters far beyond Anthropic’s embarrassment. It exposed, in unusually concrete form, what the next competitive frontier in AI really looks like. The industry has spent the last two years obsessing over models. Increasingly, the harder problem is not how to make a model answer a question. It is how to make that model work for forty minutes, or four hours, across tools, files, commands, failures, interruptions, and handoffs, without collapsing into confusion or becoming unsafe. Anthropic’s own engineering writing has been moving in exactly this direction for months: away from prompt tricks, and toward context engineering, tool design, agent evaluation, sandboxing, and harness design for long-running tasks.

That shift is the real story.

The leak was interesting because it exposed a system, not a demo

There is a huge difference between an impressive AI demo and a productized agent. A demo shows that a model can do something once. A productized agent has to do it repeatedly, under constraints, with partial failures, ambiguous user intent, changing state, and real permissions. It has to survive success, survive error, and survive boredom. It has to keep working after the novelty wears off.

By the time this leak happened, Claude Code was already clearly far beyond the stage of “an LLM in a terminal.” Anthropic’s documentation and engineering posts describe a system with structured tools, context management, memory layers, subagents, hooks, permission modes, SDK support, and security controls designed specifically for real-world, iterative work. Anthropic has even described Claude Code as a flexible agent harness, which is a telling phrase: not just an assistant, not just a shell wrapper, but a runtime system for sustained model-driven execution.

That language is not cosmetic. It reflects a deep architectural truth. Once an AI system is expected to act rather than merely answer, the harness becomes first-class. The harness is what decides what enters the model’s context, what tools are exposed, what outputs are executable, how risk is bounded, how history is compressed, and how work resumes after interruption. The harness is what lets a model stop being a brilliant intern and start becoming a usable operator.

This is why the leak was so revealing. It made visible the fact that a frontier coding agent is not merely “LLM plus API calls.” It is a layered execution environment.

The architecture we should really be talking about

The cleanest way to understand what Claude Code appears to represent is as an early form of an agent operating system. Not an operating system in the old desktop sense, of course, but an execution layer sitting between human intent and the messy world of files, commands, network access, external tools, and long-lived work.

At the top sits the cognitive layer: the model itself. This is the part that interprets goals, plans steps, decides whether to inspect or edit, whether to run a command, whether to consult a tool, whether to delegate, whether to stop, and whether to revise a previous approach. Anthropic’s own framing of agents is useful here: unlike fixed workflows, agents are systems in which the LLM dynamically directs its own process and tool usage.

Beneath that is the context layer, which is far more important than most people realized during the first wave of prompt engineering. Anthropic’s context engineering work defines the problem as curating and maintaining the optimal set of tokens during inference—not just a prompt, but everything that lands in the model’s window: system instructions, conversation history, tool schemas, retrieved state, memory summaries, and external context. The point is not verbosity. The point is getting the right state into the right place at the right time, while staying within budget.

Then comes the capability layer: tools, skills, subagents, MCP-connected services, hooks, code execution, and the interface contracts through which the model can do real work. Anthropic’s engineering guidance on tools is blunt and correct: tools are the contract between deterministic systems and nondeterministic agents, which means they cannot be designed as if the caller were always a careful human programmer. They must be understandable to the model, robust to ambiguity, and economical in how they return usable context for the next reasoning step.

Below that sits the execution and safety layer. This is where many agent demos quietly die when exposed to reality. If the system can read files, edit code, run shell commands, browse networks, and touch external services, then it needs enforcement—not vibes, not promises, but hard boundaries. Anthropic’s sandboxing work makes this point clearly: if you want to reduce user interruption without inviting disaster, you need OS-level controls such as filesystem isolation and network restriction. In their write-up, the emphasis is not on polite model behavior but on containment via operating-system primitives. That is exactly the right instinct.

Finally, there is the continuity layer: everything needed for long-running work to remain coherent across time. This is where “chatbot thinking” breaks down. Long tasks span multiple context windows. They pause, resume, compress, branch, and sometimes recover after failure. Anthropic’s engineering writing on long-running agents explicitly calls out this challenge: an agent can do good work inside a single context window, but making consistent progress across many such windows is still an open systems problem.

Put those layers together and the picture becomes clear. A serious agent is no longer just a model. It is a control plane.

Why the most important word here is “harness”

“Harness” may sound like humble engineering terminology, but it is quickly becoming one of the defining words of the agent era.

A harness is the difference between a clever system and a dependable one. It is what transforms a raw generative model into a bounded actor that can perceive, plan, act, recover, and continue. The model reasons. The harness operationalizes that reasoning.

This is not a semantic distinction. It is the central engineering challenge of the field. Anthropic has been unusually explicit about this in its public writing. Their posts on long-running agents, tool design, multi-agent research, and agent evaluation all converge on the same principle: if you want real-world agentic performance, you must stop treating the model in isolation. Evaluation must include the transcript and the outcome. Tool interfaces must be engineered for model use. Context must be curated rather than dumped. State must be compressed across sessions. Autonomy must be mediated by permissions and environment controls.

That is what the leak inadvertently dramatized. The exposed code appears to have fascinated people not because it contained mystical prompts, but because it showed the accumulated scaffolding required to make an agent actually run. Even media coverage of more playful findings—such as references to a Tamagotchi-style pet or an internal “KAIROS” mode suggestive of a more always-on agent behavior—was interesting mainly because it hinted at a system that was already far more productized and exploratory than a public CLI façade would suggest. Those features were reported from code analysis and media review, not from official feature launches, so they should be treated cautiously. But even as signals, they reinforce the broader point: the product surface is only the visible edge of a much deeper execution architecture.

Long-running tasks are where the romance ends and the engineering begins

The industry has become very good at showcasing one-shot intelligence. Ask a hard question, get a sharp answer. Request a file edit, receive a plausible patch. That is the easy part, or at least the easier part.

The much harder problem is longitudinal coherence. Can the system stay useful after thirty tool calls? Can it remember what it already verified? Can it summarize its own work productively rather than dragging a giant transcript forever? Can it stop repeating failed actions? Can it resume from a checkpoint without becoming a different personality with amnesia? Can it work under constrained permissions without constant babysitting?

This is where modern agents either become infrastructure or stay toys.

Anthropic’s public materials make clear that Claude Code tackles this not by pretending every session is one endless conversation, but by treating continuity as a separate engineering concern. Their documentation around memory shows that sessions begin with fresh context windows, while persistent project knowledge can be reintroduced through artifacts such as CLAUDE.md and auto-loaded memory. That is a subtle but important design choice. It rejects the fantasy that bigger windows alone solve persistence. Instead, it treats persistence as a state-management problem: what should be carried forward, in what form, and at what granularity.

That design instinct is more profound than it may first appear. Long context is not memory in the full systems sense. It is a larger desk, not a durable institutional mind. Real memory for agents has at least three distinct forms.

One is task state: what has already been done, what remains open, and what the current frontier of work is. Another is policy memory: the rules, conventions, and preferences that should shape behavior across sessions. A third is experiential memory: what approaches worked, what failed, and what patterns the system should prefer next time.

The harness has to decide how these are stored, when they are retrieved, and how they are compressed so they remain useful instead of becoming token sludge. That is not the model’s “natural intelligence.” That is systems engineering.

Tools are not APIs anymore—at least not in the old sense

One of the most consequential implications of this leak is what it says about the future of software interfaces.

For the app era, APIs were built mainly for programmers. They assumed explicit calls, disciplined arguments, deterministic control flow, and external orchestration. In the agent era, that is no longer enough. The caller is often a probabilistic planner operating through language and partial context. It may misunderstand boundaries, misuse a tool, or invoke the right capability at the wrong moment. The interface therefore has to be legible not just to humans, but to models.

Anthropic’s guidance on writing effective tools for agents makes exactly this point. Tools should have clear names, clear boundaries, concise but informative descriptions, and outputs that help the model make the next decision rather than merely dumping raw data. This is more than documentation polish. It is a new interface discipline.

That is why I increasingly think the old vocabulary—API, plugin, extension—does not quite capture what is emerging. A high-quality agent skill is not just a wrapped endpoint. It is an executable capability unit designed for model planning, model invocation, error recovery, policy enforcement, observability, and often token efficiency. It is closer to a syscall with documentation, guardrails, and telemetry than to a classic web API.

This is also why capability density may matter more than raw model parity in the next competitive phase. Once leading models are all reasonably capable, the decisive difference may be the richness and quality of the harnessed capability environment: how many reliable skills exist, how composable they are, how well they are described, how safely they execute, how efficiently they pass context, and how well they integrate into longer task loops.

In that world, the ecosystem moat shifts upward. The battle is no longer only about who has the smartest model. It is also about who has the most usable action surface.

Multi-agent systems only matter if they improve division of labor

The leak also adds fuel to another active debate: whether multi-agent architectures are genuinely useful or just elaborate theater.

Here again, Anthropic’s public engineering perspective is more sober than much of the discourse. In its write-up on the company’s multi-agent research system, the key challenge is not “more agents equals more intelligence.” It is delegation. The orchestrator must know when to hand work off, how to specify the task, how to constrain the subagent, and how to turn partial results into progress without wasting effort or creating contradictory work streams.

That is the right framing. Multi-agent systems make sense when they create cleaner division of labor. A read-only exploration agent can map the repository. A planning agent can structure the work. An execution agent can edit and run tests. A verification layer can judge outputs. A human can step in only at leverage points. This is not “a bunch of bots chatting.” It is a labor system.

Seen that way, subagents are not an indulgence. They are the first signs of specialization inside AI runtime environments. Once tasks become large enough, one generalized process becomes clumsy. You want bounded workers, each with specific tools, scopes, and expected outputs. That is not unlike how modern computing systems evolved from single-process simplicity to structured concurrency and process isolation.

The lesson is simple: multi-agent is not a religion. It is organization design.

Safety, in practice, means the model does not get to be trusted by default

One of the deeper ironies of the Claude Code leak is that it hit a company whose public identity is heavily tied to safety. That irony wrote itself on social media. But the more interesting observation is technical.

When people say “AI safety,” many still imagine abstract alignment discourse or content filtering. Yet in real agent systems, a huge fraction of practical safety is operational: what can the agent access, what can it execute, what network paths are open, what approvals are required, and how exceptions are handled when the model confidently heads in the wrong direction.

Anthropic’s engineering material on sandboxing and permissions points toward a mature answer. Permissions alone are not enough if they require the human to approve every move. That destroys flow and keeps the system from becoming truly useful. But letting the model run without constraints is equally untenable. The way forward is layered enforcement: policy classifiers, execution sandboxes, file and network boundaries, and extension points such as hooks where custom organizational policies can be injected.

That is a fundamentally important design philosophy. It says that reduced human interruption should come not from blind trust in the model, but from stronger environmental guarantees around it. In other words, you do not make autonomy safe by teaching the tiger manners. You make it safe by building the enclosure properly.

This is also where the phrase “OS-level harness” becomes more than metaphor. Once agent systems interact with the real world, they start inheriting the old truths of operating systems and security engineering: privilege separation matters, isolation matters, explicit boundaries matter, auditability matters, and resumability matters. The romance of “AI that just figures it out” runs into the granite of systems design.

What the industry should learn from this moment

It would be easy to reduce the whole affair to a cautionary tale about release engineering, and it certainly is that. A misconfigured packaging process or an overlooked sourcemap can expose an extraordinary amount of internal detail. The operational lesson is obvious and a bit humiliating: modern AI companies, no matter how sophisticated, are still software companies, and software companies can still trip over the oldest rake in the yard.

But that would be the shallow lesson.

The deeper lesson is that frontier agent systems are now being built as full-stack execution environments. The model is still central, but it is no longer the whole product. Context curation, memory persistence, tool ergonomics, task orchestration, sandboxing, permissions, subagent specialization, evaluation methodology, and session-to-session continuity are all becoming part of the competitive core. Anthropic’s public work has effectively been spelling this out for over a year; the leak merely made the abstract thesis concrete.

That is why this incident will likely matter more as a strategic signal than as a one-off embarrassment. Competitors did not gain model weights, but they gained something almost as valuable for the near term: a sharper picture of how one of the leading coding agents is assembled into a production system. Even if no one can simply clone the whole thing, the leak accelerates convergence around architecture patterns. It teaches by exposure.

And perhaps most importantly, it nudges the broader AI conversation toward the right level of abstraction. The real frontier is no longer just intelligence in the narrow sense. It is controlled, sustained, economically useful agency.

The bigger picture: agents are becoming a new execution layer for software

If there is one conclusion worth carrying forward, it is this:

The future of agents is not “a better chatbot.” It is a new execution layer between human intent and software reality.

In the app era, users navigated menus, forms, dashboards, tabs, and icons. In the API era, developers stitched services together manually. In the agent era, the user increasingly declares intent, and a model-centered runtime translates that intent into a sequence of bounded actions across tools, files, services, and state.

That runtime needs memory. It needs policy. It needs permissions. It needs a tool contract. It needs recovery logic. It needs evaluation. It needs observability. It needs all the dull, durable things that software needs when it stops being a trick and starts becoming infrastructure.

Claude Code, as glimpsed through this leak and through Anthropic’s own public architecture writing, looks less and less like “an assistant that can code” and more like an early agent operating environment for software work. That is why the leak was so revealing. It showed that behind the glamour of modern AI lies a quieter but far more consequential truth:

The model may provide the intelligence, but the harness provides the agency.

And in the long run, agency is where the real systems battle will be fought.

• 立委关于大模型与AI的博客汇总

The answer isn’t “will it happen?” It’s already happening. Just not in the way we’re used to.

The Operating System in the Agentic AI Era

I. The history of operating systems is, at its core, a war over the front door

Each generation of operating systems didn’t merely improve kernels. It reorganized the entry point—how humans express intent.

DOS: the command line was the entry point.
Windows / macOS: the desktop GUI became the entry point.
iOS / Android: app icons became the entry point.
The web era: the browser became the entry point.

The strategic heart of an operating system has never been the kernel. It’s the question: how does a user make something happen?

Change the front door, and the entire software ecosystem gets reshuffled.

II. Agents change the way intent is expressed

In the old model, doing something looked like this:

You want something done → open an app → find the feature → click through the workflow.

In the agentic model, the loop becomes:

You want something done → tell an agent → the agent orchestrates the system.

This is not a feature upgrade. It’s the disappearance of the old entry point. Recent “OS-level agent” moments—whether you look at stunning phone demos like Doubao’s, or the grassroots explosion around OpenClaw—make one thing unusually vivid: when users stop opening apps and agents start calling them, apps stop being the front door. They become capability modules.

In that world, the operating system is no longer organized around an “app launcher.” It’s organized around a permission orchestrator.

That is the structural change.

III. When the agent becomes the default entry point, three things happen to the OS

3.1 UI moves to the second row

The UI doesn’t disappear, but it stops being the center of gravity. The interface becomes a governance tool, not an operation tool. It naturally splits into three roles:

a visualization layer
an approval layer
an audit layer

The real execution logic lives in the background orchestration layer. Icons shrink in importance. Menus fade. “Workflows” get flattened.

(1) Visualization layer
In traditional software, the UI is a control panel: you press buttons to cause actions.

In the agent era, actions happen in the background. The UI’s primary job is to tell you what happened:

what the agent plans to do
what it is doing right now
what it has completed

If the agent books your flights, reorganizes your files, refactors your code, or runs a batch of API calls, you don’t click through each step. You supervise the plan and the outcome. The UI becomes closer to an aircraft instrument panel than a steering wheel.

(2) Approval layer
This layer becomes critical the moment agents gain execution authority. Some actions must require explicit human confirmation:

deleting 2,000 files
wiring $5,000
signing a contract
sending sensitive data outside the organization

Now the UI isn’t a collection of “features.” It’s a set of risk checkpoints. Its core function is not “click to do,” but “authorize or deny.”

It must show:

risk level
blast radius
confirm / reject controls

This is the UI as the human’s final vote.

(3) Audit layer
If an agent can execute continuously, you can’t watch every step. The OS must surface accountability:

execution logs
tool and API call traces
permission usage history
resource consumption (tokens, API spend, data egress)
anomaly alerts

This looks less like a classic app UI and more like:

a bank statement
a cloud access log
a flight recorder

The UI becomes an interface for responsibility. It doesn’t help you “do the work.” It helps you know what happened—and assign blame when something goes wrong.

Put side by side, the shift is stark.

Traditional app UI:
menus, buttons, forms, step-by-step workflows

Agent-era UI:
plans, summaries, risk prompts, permission grants, audit trails

You are no longer the operator. You are the supervisor.

And that’s not just an interaction change—it’s philosophical.

Before: humans operate; software executes.
After: agents operate; humans arbitrate.

So the UI naturally migrates toward feedback, authorization, and oversight.

A concrete example
Imagine a future macOS where you say:

“Turn last year’s client invoices into a financial report.”

The agent quietly:

searches files
extracts data
calls spreadsheet tooling
uses email APIs if needed
generates a PDF

And the UI shows only:

a plan of steps
a warning: 3 anomalous files detected
a lock: authorize access to the finance folder?
a result: report generated

You didn’t “open” any app. You supervised. The UI didn’t vanish—it evolved from a control panel into a responsibility panel. And whoever controls that panel controls the final decision.

That is what the OS must defend.

3.2 The permission system becomes the core asset

Classic OS security models are built around:

file permissions
process isolation
sandboxing

But the agent era demands something more dynamic:

just-in-time permission grants
temporary execution authorization
revocable capability interfaces
verifiable execution logs

The OS shifts from a resource management system into a governance system for delegated execution.

3.3 APIs rise; apps fade

When agents are the default gateway, UI value goes down and API value goes up. The ecosystem starts to look like:

foreground: one “super agent”
background: countless capability interfaces

In that world, the App Store itself may morph—from an “app market” into a “skill market.” Users don’t download apps; agents call capabilities. Distribution is rewritten.

IV. Why big platforms don’t fully open the gates

Because once an agent becomes the default entry point:

OS vendors lose the privileged control that UI once provided
the app ecosystem gets abstracted into a capability layer
revenue models face renegotiation

If every iPhone app becomes a background capability and the user interacts primarily through an agent, do app icons still matter? Does the 30% toll still feel defensible?

Entry-point control is profit control. That is why platform players ship agent features cautiously and incrementally.

When a product like Doubao pushes toward OS-level agency and triggers visible pushback, it’s not mysterious what it threatens. But the direction is hard to reverse: once consumers taste the productivity of an OS-level agent, they rarely want to go back to tapping through menus.

V. OpenClaw is a preview of an “ungoverned OS”

OpenClaw is, in essence, a simplified shell of an agent operating system.

It lacks mature permission governance. It lacks compliance frameworks. It lacks serious auditing. And yet it demonstrates a key fact:

model + permission orchestration + local execution is already enough to simulate a micro-OS.

That is why it shocks people. Not because it invented new intelligence, but because it shows what happens when you attach intelligence to execution without governance.

VI. The real future shape

When agents become the default gateway, the operating system becomes:

a permission allocation platform
an execution-log platform
a capability marketplace
a risk-control hub

UI gets simpler. Apps become invisible. Capabilities become modular.

The user sees a conversational entry point. Underneath is a governance engine for delegated action.

VII. Final judgement

Agents will not eliminate operating systems. They will force operating systems to evolve—from “resource schedulers” into “arbiters of delegated execution.”

The core asset in the agent era is the power to define boundaries:

what can be done
by whom
under what permissions
with what logs and accountability

Whoever defines those boundaries becomes the next platform.

https://liweinlp.com/category/english

My answer: not immediately. But its structural profits will be quietly, steadily eroded—and the way it happens is subtle enough that many people won’t notice until the numbers start to move.

In the mobile era, we got used to a simple truth: if you control the home screen, you control the money. The App Store was never just a software catalog. It was a tollbooth placed at the one place users had to pass through.

That premise is what the Agent era challenges.

I. The App Store Doesn’t Really Sell Apps—It Sells Gatekeeping
The App Store’s core asset has never been “distribution” in the neutral, technical sense. Distribution is a commodity now. What the App Store truly owns is the gate:

the default user entry point
the power to route attention and traffic
control of the payment rail
the right to tax the ecosystem

In the classic mobile loop, the sequence looks like this:

user → opens an app → uses a service
platform controls the entry point → takes ~30%

That structure works for one reason: the user must consciously open the app. As long as the app icon is the front door, the platform owns the doorframe—and can charge rent.

II. The Fatal Change in the Agent Era: Apps Stop Being the Entry Point
Once an agent becomes the default gateway, the flow changes into something like:

user → tells the agent → agent dispatches capabilities → calls an app’s backend APIs

The key shift is psychological as much as architectural: the user no longer “opens an app.” The app becomes a background capability provider.

And when the user can’t even tell which app is being used, two things happen at once:

brand gravity weakens
entry-point value decays

Traffic follows the new front door. Whoever controls the agent increasingly controls attention and intent. And that is the App Store’s structural threat in one sentence.

III. The App Store Won’t Disappear—But It Can Be Hollowed Out
This won’t look like a dramatic collapse. It will look like slow “hollowing,” where the storefront still exists, but its economic center of gravity shifts. Three changes are likely.

First: fewer UI-heavy apps.
A large class of utility apps—especially those built around routine workflows—will be absorbed into agent behavior:

calendar coordination
lightweight editing
information aggregation
copy-and-paste data movement

These become invisible background functions. Users may not know which product is powering the result, and they won’t care—until someone asks who gets paid.

Second: the commission logic gets challenged.
If an agent can complete a purchase by calling a cloud API directly—without going through an in-app purchase flow—the traditional platform toll lane can be bypassed.

The 30% model works best when the platform owns the transaction surface. Agents, by design, prefer capability surfaces: web APIs, service endpoints, programmable commerce. That route is harder to tax.

Third: a “skills market” starts to replace an “apps market.”
It’s not hard to imagine an ecosystem that looks more like:

agent skill marketplaces
capability modules / plugins as tradable units
API ecosystems designed for agent orchestration

In that world, the store doesn’t vanish. It mutates. It stops selling “apps” as user-facing products and starts selling “capabilities” as agent-callable services. That’s a form shift—not an extinction event.

IV. The Real Conflict Isn’t the App Store—It’s Who Owns the Default Agent
The strategic question is not whether an App Store survives. The strategic question is: who becomes the default agent?

If it’s Apple’s agent, the App Store is absorbed and reinterpreted inside a new orchestration layer.

If it’s an OpenAI/Anthropic-style agent, the platform can be partially bypassed—relegated to infrastructure while value capture migrates elsewhere.

If it’s a local, open-source agent (think OpenClaw-like trajectories), then platform rent extraction weakens: the platform remains in the chain, but with far less bargaining power.

Once entry-point control shifts, profit follows. This is the true reason platforms are anxious. It’s not a debate about UX. It’s a battle over who owns the choke point.

V. Why Big Platforms Move So Carefully on Agents
This is why the largest platforms push agents with visible caution. They are walking a tightrope.

If their agent is too strong:

users open fewer apps
platform commission pressure increases
developer economics get restructured

If their agent is too weak:

users migrate to third-party agents
entry-point control gets stolen
the platform becomes a “hardware shell” around someone else’s brain

It’s a delicate game. The likely strategy is not “build an agent that replaces apps,” but “build an agent that strengthens the existing ecosystem while preventing displacement.”

Agents won’t directly destroy the App Store. But they can demote it—from an entry-point platform into a capability supply market.

Entry-point value compresses. Profit formulas get rewritten. And the ultimate winner is not the party who sells apps, but the party who defines the orchestration rules.

VI. The Final Question
The mobile internet era rewarded whoever controlled the entry point.

The agent era will reward whoever controls intent interpretation and execution scheduling.

When a user says just one sentence—“get this done for me”—the person (or system) deciding where the request gets routed is the one deciding where the money flows.

At that moment, the most valuable asset is no longer the app icon on the home screen.

It’s the agent in the background doing the dispatch.

https://liweinlp.com/category/english

I. OpenClaw is a structural event.

What makes OpenClaw shocking isn’t a new algorithm. It’s the fact that it exposes a new reality:

LLM capability + local execution privileges + open-source scaffolding is already enough to rewrite how software gets produced.

When a solo developer can stitch together an agent with something close to “OS-level permissions” using off-the-shelf models and open frameworks, it tells us something uncomfortable yet important: raw capability is no longer scarce. The scarce variable is now composability—the ability to combine tools, permissions, and workflows into outcomes.

And composability isn’t linear. It’s exponential. When your building blocks are callable functions, “more blocks” doesn’t add—it multiplies.

II. Why “80% of software” gets swallowed

Once agents can:

understand natural language intent directly,
break a task into steps automatically,
call tools dynamically,
and correct their own execution paths in real time,

a huge category of “workflow-frozen software” starts losing value fast.

For decades, software has trained humans to adapt to software. You open the right app, learn the right menu tree, follow the prescribed workflow, and hope your problem fits the box. The agent era flips the direction: software adapts to human intent.

That shift has a brutal implication: the core of software stops being UI, menus, and fixed workflows. The core becomes APIs and capability interfaces. Everything in the middle—the layers whose main job is turning workflows into a clickable experience—gets compressed.

Many products won’t “die.” They’ll be absorbed.

Tools that are mostly UI-wrapped procedures.
SaaS products that are largely data shuttling.
Systems whose main value is rigid rule execution.

Agents don’t need to replace them by competing head-on. They can simply embed them as invisible steps in an orchestration graph.

III. The moat is moving

Traditional software moats looked like:

complex feature depth,
data lock-in,
sticky workflows,
custom enterprise integrations.

But in an agent world, features can be composed on demand, workflows can be generated dynamically, and data can be surfaced through standardized interfaces. The moat migrates to things that are harder to synthesize by “tool composition” alone:

high-quality proprietary data assets,
specialized vertical knowledge,
security, compliance, and governance maturity.

Put bluntly: software shifts from selling features to selling capability access and safe execution.

In the agent era, the winning product is less “a beautiful UI” and more “a reliable interface to real power—with guardrails.”

IV. Startups are being rewired

The classic playbook for software startups was familiar:

pick a scenario,
build a product,
polish the UX,
retain users,
scale subscriptions.

The agent-era playbook is different:

pick a high-value capability domain,
expose it as an agent-callable interface,
integrate into the skills ecosystem,
create value through execution, not clicks.

Entrepreneurship shifts from “building an app” to building callable capability modules.

In a world where agents orchestrate work, owning the right tool interface is like owning a critical interchange on a highway system. You don’t need to be the entire city. You just need to sit on the route everything passes through.

V. Investment logic is being repriced

Investors used to ask:

How many users do you have?
What’s your ARR?
What’s your SaaS retention?

Increasingly, the questions will mutate into:

Can your capability be orchestrated by agents?
Do you control a defensible data interface?
Is your execution verifiably safe—auditable, permissioned, compliant?

Valuation logic will follow. Pure “feature SaaS” gets pressured. Execution infrastructure and governance layers get rewarded.

Because in the agent era, the truly expensive asset isn’t UI. It’s the right to execute—safely.

VI. Local agents are a transitional form

OpenClaw’s explosion also reveals something practical: demand for action-oriented AI is already there. People don’t just want a model that answers. They want a system that does things.

But local deployment is likely a bridge, not the destination. At scale—especially in enterprises—agents will converge toward:

cloud integration,
enterprise-grade governance,
least-privilege architectures,
compliance and audit systems.

Individuals can unlock power by removing constraints. The commercial world must do the opposite: it has to constrain power before it ships.

The long-term winners won’t be those most willing to grant authority. They’ll be those best at granting authority safely.

VII. Software won’t disappear. It will become invisible.

OpenClaw’s creator suggested that “maybe 80% of software will lose its value.” The number may be rhetorically inflated. But the direction is right.

Software doesn’t vanish. It goes dark.

Users stop operating software directly. Agents operate software on their behalf. Products shift from foreground experiences to background capability modules.

That’s not a collapse. It’s an industrial migration.

VIII. The real watershed isn’t OpenClaw. It’s what it forces us to talk about next.

OpenClaw isn’t the endpoint. It’s the first public, living demonstration of something many suspected:

LLMs are already capable of executing real-world tasks—if you give them the keys.

For the past two years, the mainstream conversation was “intelligence augmentation.” In the next few years, the dominant conversation will be delegated execution:

Who sets the boundaries of capability?
Who defines execution permissions?
Who bears responsibility when things go wrong?

Those questions—more than model size or benchmark scores—may determine where the next generation of tech giants comes from.

Closing

The significance of OpenClaw isn’t what it did. It’s what it made obvious:

the software era is ending, and the capability era is beginning.

And in the capability era, what’s truly scarce isn’t the model. It’s controllable execution power.

Authority and safety are natural enemies. The biggest winners will be the ones who can make them coexist—without pretending the tension isn’t real.

https://liweinlp.com/category/english

In the Agent era, the most common confusion is not technical — it’s architectural. We keep mixing abstraction layers, and then we end up debating terms that were never meant to be equivalent:

Is a plugin basically an app?
Is a special agent the new app?
What’s the difference between an API and a skill?
Is a general agent a tool, or a platform?

If we don’t separate layers, these questions will keep looping forever. So here’s a clean mental model: a six-layer stack from intent down to execution.

Human Intent → General Agent → Special Agent → Skill → Plugin → API

General Agent is the default entry point and the scheduler. It interprets natural language goals, decomposes complex tasks, decides which specialists to call, determines which capabilities to invoke, sequences execution, and manages permissions. Structurally, it resembles what browsers were in the web era, what desktop operating systems were in the PC era, and what iOS SpringBoard was in mobile: the “front door” where intent is translated into actions. It is not necessarily a specialist — it is the orchestrator.

Special Agents are domain experts: coding agents, math agents, legal agents, research agents, trading agents, and so on. Functionally, they look like “apps” because they are optimized around a task domain — specific knowledge, specific toolchains, and domain-specific execution strategies. But structurally, they are no longer the entry point. In the agent era, the entry point is owned by the General Agent.

Apps belong to the mobile-era abstraction. The traditional loop is user-driven: the user opens an app, navigates a UI, and triggers actions. In the agent era, the loop becomes orchestration-driven: the user expresses intent once, the General Agent dispatches the work, specialists and tools execute, and the result returns. Apps won’t disappear overnight, but many will lose their role as the primary interface. Some will degrade into background capabilities; others will survive as “special agents with UI.”

Then come the lower layers that people often collapse into one.

Skills are capability declarations — a semantic contract the model can understand. They describe what can be done, which parameters are required, what outputs are produced, and which permissions are needed. Skills live in the language layer; they don’t execute code. They exist so the model can plan.

Plugins are execution wrappers — the part that actually runs. They encapsulate API calls or local system access, handle authentication and permissions, manage errors, and return structured results. If skills are “what can be done,” plugins are “how it gets done.”

APIs are the lowest-level interfaces — the protocol surface that exposes underlying systems as callable endpoints. APIs do not think, decide, plan, or schedule. They are passive responders. If you like metaphors: electricity is the capability; the API is the wall socket.

So who is the “new app”?

From a task-function perspective: Special Agent ≈ the new app.
From an entry-point perspective: General Agent ≈ the new operating system.
From an execution-unit perspective: Plugin ≈ the new software primitive.

In other words, the mobile-era “app” is being decomposed into entry-point control, capability interfaces, and execution wrappers. The most strategic control point shifts to orchestration: whoever controls the General Agent controls the new default entry point.

Finally, a quick note on industry evolution. Early agent architectures were plugin-first: LLM + plugins = an executor. OpenAI even explored a “plugin store” storyline, reminiscent of app stores. The reason that pattern didn’t become the dominant ecosystem isn’t that plugins are useless. It’s that plugins are dangerous: they hold real privileges, and in an agent loop they can be triggered automatically, not necessarily by a human click. Discovery and scheduling are also harder when the “buyer” is a model. Most importantly, plugins expand what can be done — but the harder bottleneck is deciding what should be done, in what order, under what constraints.

That is why skills emerged as a lighter semantic layer, and why modern architectures insert governance and orchestration between the model and execution. Plugins didn’t disappear; they moved downward in the stack.

This isn’t “plugins failed.” It’s the software unit migrating. The new game is not only capability — it’s orchestration.

https://liweinlp.com/category/english

The agent era just hit a visible inflection point, and OpenClaw is a useful (and slightly terrifying) case study.

What’s striking about OpenClaw is not a technical breakthrough. It didn’t train a new model. It didn’t propose a new reasoning mechanism. It didn’t “beat” scaling laws.

It did something simpler—and far more consequential: it connected an already-strong LLM to real-world execution privileges.

Browser control. Filesystem access. Shell execution. API orchestration.

The model always had the “brain.” What changed is that we finally handed it the “keys.”

That’s why OpenClaw feels like a capability explosion. The intelligence didn’t suddenly appear; it was already there. We just didn’t dare to give it OS-level agency. OpenClaw shows us, in a vivid and unfiltered way, what happens when we do.

There’s also a psychological accelerant here: local deployment.

When something runs on your own machine, it creates a strong sense of sovereignty—“my process, my disk, I can kill it anytime, worst case I pull the plug.” That physical sense of control is real, but the safety inference often isn’t.

Local deployment improves visibility and the feeling of controllability. It does not automatically reduce the attack surface. Prompt injection doesn’t disappear because the agent is local. Permission creep doesn’t shrink because the hardware sits on your desk. Visibility can create calm; calm can be mistaken for security. That “controllability illusion” is arguably a major reason agentic systems are suddenly easier for people to accept.

The deeper reason this moment feels explosive, though, is composition.

In the traditional software world, capability composition is slow and human-driven—projects, teams, tickets, code, deployment, an entire lifecycle of a software development and deployment. In the “LLM + skills” world, composition becomes real-time, automated, and continuous. An agent can run 24/7, try pathways, fail, self-correct, and recombine tools endlessly. When capabilities are modular functions or skills, combinatorics becomes the growth engine. Explosion is not a metaphor; it’s the natural math of composition.  Hence the explosion.

It’s also telling that an open-source / individual-driven project became the flashpoint. Large companies have strong reasons not to grant OS-level permissions lightly: legal liability, brand risk, regulatory pressure, and security maturity constraints. Individuals and small teams have fewer brakes. With fewer constraints, capabilities surface faster, making it a clearer window into the future agent world.

All of this reframes the real safety problem.

LLMs are the brain. Agents are the hands.

The brain-safety conversation has been loud for two years. The hand-safety conversation is just beginning, a much riskier and more challenging one. A wrong answer is frustrating. A wrong action can be irreversible. Killing a process isn’t governance. Pulling the plug isn’t governance. Governance means boundary verification and least-privilege execution designed into the architecture, not added as a last-minute guardrail.

We may still debate whether “AGI” is here. But one thing is already clear: we’ve entered the era of automated action. 2025-2026 marks the phase transition from generative AI era into agentic AI.  The central challenge now is not purely technical—it’s designing a workable balance between delegated power and embedded safety, before the diffusion of OS-level agency outpaces the diffusion of governance.