Raft Founder: Anyone Who Says Harness Will Be Obsoleted Clearly Hasn't Done Engineering
Models can't solve everything.
The AI coding world is splitting in two.
On one side, there's the "minimalist agent" camp represented by Pi — prompts under 1,000 tokens, just four basic tools, a philosophy of no fuss, letting the model do its thing. On the other side, Agent Swarm and multi-agent collaboration, with systems growing ever more complex.
These two paths seem contradictory, but they point to the same core question: Will the underlying Harness eventually disappear?
Many see Pi's viral success as proof that the "model-first" camp is right — that as large models grow stronger, external Harness will eventually vanish. But RC, founder of Raft (@stdrc), offers a counterintuitive take: the stronger the model, the thicker the Harness becomes.
Only the direction of "thick" has shifted. Before, thickness sat at the bottom layer, using prompts and tools to compensate for the model's shortcomings. Going forward, thickness will sit at the top layer — because as models grow capable enough to tackle dirtier, heavier work, Harness is needed to manage multi-agent collaboration and control. Complexity hasn't disappeared; it's simply migrated from the "capability layer" to the "collaboration layer."
The following reflections don't come from a single blog post, but are scattered across RC's public conversations over the past few months.
On X, they're unvarnished, immediate reactions. A 3 AM thought on a decision. A post-experiment debrief. An instinctive read on industry trends. Any single tweet won't withstand scrutiny, but arranged chronologically, they reveal a founder's evolving mindset in real time.
RC compares the relationship between model and Harness to "yin and yang": the expansion of model capability is the swelling of yin, internalizing bottom-layer Harness; but each step up unlocks more complex scenarios, spawning demand for higher-layer Harness — the extension of yang. The higher the intelligence, the greater the friction with reality, just as the more developed the human brain, the more it needs language, law, the internet, and other complex interaction systems.
Harness won't disappear. It will only continue expanding outward as intelligence upgrades.
The Misunderstood Harness
To see the evolution logic of Harness clearly, we must first dismantle two widespread misconceptions in the industry.
Misconception one: Harness will eventually be trained into the model and vanish completely.
Many people assume that large models will eventually become all-powerful, and Harness will be trained into them and disappear entirely.
But anyone who's actually done engineering work knows this is confusing cause and effect. RC puts it bluntly: "Anyone who says Harness will be trained into the model definitely hasn't built Harness."
From a hands-on development perspective, he breaks this down into three points:
First, it's not that models grow strong and eliminate Harness — it's that Harness paves the way first, so the model knows what to learn. Like human society: division of labor came first, then people learned to collaborate. Harness is the model's training ground. Without this external framework, the model has nowhere to practice collaboration.
Second, higher intelligence demands more complex tools. The human brain evolved — we didn't devolve into primitives, we invented law and the internet. As model capabilities strengthen, the real-world scenarios they unlock grow more complex too. Bottom-layer capabilities get internalized, while new, more complex scenarios grow on top that need Harness to manage.
Third, single tasks may rely on the model alone, but complex business is fundamentally unrealistic. When facing long workflows, multiple agents, and states that need constant monitoring, relying purely on a large model's memory guarantees omissions, errors, even conflicts. This isn't about whether the model is smart enough — it's a systems engineering problem that was never meant for a single model to brute-force.
Misconception two: the stronger the model, the thinner the Harness.
Another popular claim: stronger models mean thinner Harness.
This seems correct on the surface, since bottom-layer prompts are indeed shrinking, and many previously complex tool wrappers are no longer necessary.
RC considers this view "understandable, but lacking imagination." The problem is it only sees the subtraction at the bottom layer, missing the addition at the top.
Undeniably, as foundational model capabilities improve, large numbers of "patch-style" Harness will gradually retire — things like forced constraints to prevent format output errors, lengthy prompts teaching the model to use tools, and rigid error-retry mechanisms. These bottom-layer designs that existed to compensate for model deficiencies will indeed grow thinner, even disappear entirely.
But this is not the death of Harness — it's complexity migrating upward.
When models no longer need human programmers to assist them, they require you to establish a new set of rules for them.
Stronger models unlock more complex task scenarios, which in turn spawn new Harness demands: How do you get multiple agents to coordinate? How do you sync state across sessions? How do you implement proactive memory management? How do you set dynamic permissions and interface standards with different systems?
These demands simply didn't exist in the weak-model era, so they were never part of people's conception of Harness.
How to Define True Harness?
After correcting these misconceptions, we need to return to the core question: how do we define true Harness?
The general public often narrows Harness to "system prompt + tool call wrapper." From a complete engineering perspective, Harness is the runtime engineering control layer wrapped around the model, fundamentally solving the problem of "how does the model stably, continuously, and controllably interact with the real world." It consists of four core elements: agent execution loop, context and state management, tool and resource scheduling, and safety and boundary governance.
The scope of Harness has been expanding all along. From early weak models, where Harness only assembled simple prompts; to mid-stage stronger models, where Harness evolved multi-tool parallelism and sub-agent scheduling; to today's extremely capable models, where Harness now tackles agent clusters, cross-system state sync, and multi-agent task handoff.
RC compares the model-Harness relationship to "yin and yang" — a dynamic of mutual ebb and flow, co-evolution.
The "internalization" of local functions is yin's expansion.
When foundational model capabilities strengthen, part of the bottom-layer Harness gets absorbed by the model. In past practice, RC had planned to remove dedicated subagent scheduling mechanisms, letting the model directly split subtasks through bash terminals; he also removed native parallel tool calls, letting the model generate tool call scripts to achieve parallelism instead.
This is the inevitable result of model capability expanding outward, and the real reason outsiders perceive "Harness getting thinner."
The "growth" of top-layer demands is yang's extension.
Each step up in model capability unlocks more complex business scenarios, spawning demand for higher-layer Harness. Mature single-task capability gave rise to multi-agent collaboration needs; mature single-session capability gave rise to cross-session memory and proactive context backtracking needs. In this yin-yang博弈, higher intelligence means greater friction with the real world.
This process has no endpoint. Just as the human brain is more developed than the ape's, humans invented language, writing, computers, the internet — ever more complex interaction systems.
The higher the intelligence, the more complex its interaction with the world.
Harness is the "interaction infrastructure" of agent intelligence, and will only continue expanding outward as intelligence upgrades.
Beneath this discussion, a developer named Monk Zero left an interesting comment on Twitter.
From a philosophical perspective, Monk Zero argues that Pi's approach is essentially "thin-layer prompt + thick-layer Harness." He likens the model to Dionysian chaos and creativity, while Harness is Apollonian order and structure. The two are eternally complementary.
Whether from RC's engineering evolution perspective or Monk Zero's definitional perspective, Harness will necessarily persist — it will not disappear.
From 0 to 1 Validation
RC's "complexity migration" theory isn't armchair speculation — it's grounded in the complete engineering practice of building Kimi CLI from 0 to 1.
Early Kimi CLI referenced no open-source frameworks; it grew entirely from scratch. From basic single-tool calls, it gradually developed parallel calls, sub-agents, state management. But in later iterations, the team made a bold "subtraction experiment": they cut all dedicated subagent scheduling code, discarded native parallel controls, and let the model handle everything through scripts itself.
The result: once model capability hit that critical threshold, bottom-layer Harness could indeed be discarded.
But no sooner had the bottom-layer code been deleted than the team discovered a more headache-inducing problem. Harness boundaries can't stop at a single agent's interior — how do multiple intelligences communicate? How do they hand off tasks? How do you nail down communication protocols and division of labor?
So they began adding weight at the top layer, proposing a multi-agent Harness architecture concept, building agent task handoff, communication protocols, and division mechanisms, while researching cross-session communication, proactive context compression, context backtracking, and other state management techniques.
These explorations became the technical precursor to Raft. And this directional judgment closely aligned with the later trend of Claude launching cross-session conversations and the industry's collective pivot toward multi-agent.
It was precisely this from-scratch growth experience that let them clearly observe Harness complexity's migration pattern, without getting trapped by static-phase thinking.
Raft Is the Next-Generation "Thick Harness"
If Kimi CLI was an evolution experiment, Raft is the direct practice of "thick top-layer Harness" architecture.
In building Raft, RC boldly removed the single-agent runtime he himself had built. Raft writes no agent loops, wraps no foundational tools — it directly plugs mature products like Claude Code and DeepSeek into the system as "team members."
His logic is simple: bottom-layer single-agent capability is mature enough, models have already internalized this portion of Harness, and reinventing the wheel holds no value. The next battlefield for Harness isn't inside a single agent, but between multiple agents.
Raft concentrates all firepower at the top layer, solving the systemic problems of multi-agent collaboration. Its "thick Harness" manifests across four core dimensions:
One: giving AI identity and memory. The model only handles single-turn responses, but Raft ensures every agent has independent process, memory, and work habits. If a task gets interrupted, it can resume seamlessly later.
Two: establishing rules and division of labor. Models don't spontaneously organize team collaboration. Raft imports the human workplace, using "channels" similar to work chat groups to isolate conversations, supporting task claiming, yielding, and handoff — all steps logged for human audit at any time.
Three: breaking vendor barriers. Raft built a cross-vendor communication protocol, letting Claude, DeepSeek, and others converse in unified standards within the same workspace. No single model company would ever do this on its own.
Four: building a workspace where humans and AI work together. Here, Harness is no longer a piece of code — it's become the team's workflow and authority system itself.
Even the pricing is interesting: each agent costs only 0.1 human seat, with cross-team sharing supported. At this point, Harness has transformed from a "technical tool" into the team's daily communication and collaboration rules themselves.
Finally, RC offers an intriguing take on Harness's endgame: "When everything is Harness, it becomes invisible."
Just as when using Raft, you don't feel like you're facing a complex "agent scheduling backend" — it looks like office software that pulls AI in. All state sync, permission control is hidden behind product intuition.
We don't go around declaring "corporate policy and law are humanity's Harness" every day at the office either. Once AI employees truly become widespread, this thickest layer of Harness will fully dissolve into daily workflows, becoming infrastructure as invisible as the power grid or running water.
So looking back at the original question — "will models swallow everything, or will Harness keep growing" — perhaps both underestimate the dimension of technological evolution.
What truly matters is looking upward: how to build new moats that others can't take away, in higher-dimensional upper-layer collaboration and complex business scenarios.