The stronger the model, the more everything around it matters. In October 2026, two companies put this question on the table within the same month: in early October, Google Cloud AI Research and Northwestern University published "Harness²: Recursive Agent Harnessing for an Open World" and open-sourced the implementation; three weeks later, on the evening of October 31, DeepSeek's Harness team published "Exploring Super-agent Design" and open-sourced a prototype repository. Neither cites the other, and the press flattened the second story into "a Claude Code rival" — but read the two materials side by side and they answer two sides of the same question: when the model itself is no longer the bottleneck, what should an agent's base layer be made of?
The more interesting fact is that both answers share one premise completely: all model weights are frozen. Improvement happens only outside the model. That shared choice is itself the most important industry signal of this moment.
1. Harness: from prompt craft to systems problem
First, terms. An agent is two things: a model, and the harness wrapped around it — the system prompt, memory, skills, tools, guardrails, and orchestration through which the model acts. The same model in a different harness can differ by double-digit percentage points; on Harvey's legal benchmark (LAB), a single Harness² improvement step lifted GLM-5's partial pass rate by 11.8 points (59.6 → 71.4).
For the past two years harness engineering has existed in two forms. One is craft: teams hand-write prompts and tune skill files by hand, iterating on engineer intuition. The other is product: finished coding agents like Claude Code or Codex, where the harness ships inside the product, invisible and unmodifiable. Both forms are adequate for single tasks: one conversation, one job, one toolset.
But agents are outgrowing the single task. Personal assistants need to stay online around the clock and push many things at once; professional agents are entering office workflows and high-stakes domains like legal work, where tasks vary endlessly. Two new bottlenecks appear:
- Under multi-task concurrency, the bottleneck shifts from model capability to human attention. One person tracking three to five sessions is the ceiling; no model is strong enough to fix that — this is where DeepSeek's article starts.
- As the task distribution drifts, hand-written harnesses cannot keep up. Prompts tuned for office tasks fail on legal work; hand-designing a harness for every domain scales linearly with scenarios — this is where Google's paper starts.
Each company took one. DeepSeek took scheduling; Google took evolution.
2. DeepSeek's answer: scheduling, or the economics of attention
DeepSeek's article has a counterintuitive starting point: the more autonomous the agent, the greater the danger is not that it does wrong things, but that it wastes human attention. An agent that can work for a whole team can also drain a whole team's attention — every proactive report, every unnecessary confirmation question spends a resource scarcer than compute. The first document in the dsh-superagent-prototype repository writes this as a constitutional principle: "Take as little human attention as possible, and give as much value as possible" — every message, every notification, every setting must return more value than the attention it costs, or it goes.
Around that principle, the article moves classical computer-systems designs into the agent layer one by one. Scheduling: a resident Router layer only dispatches and never does the work (it may carry no Bash tool at all and run on a lighter model), while isolated Worker layers only work and never speak outward, contexts unpolluted. Caching: the context window is managed like memory — frequently used information is inlined, long texts are truncated with a read-back handle, objects are linked into a reference graph by ID and recalled hop by hop when needed; in the article's own words, "wasting the context window is wasting the model's intelligence." Fast/slow path: environment event streams — group-chat messages, code comments, CI results — are high-noise and low-trigger; a program-level admission table screens them first, and only survivors reach the model. Full duplex: tool calls become asynchronous start/stop, so long background jobs never block the front channel. Disaggregation and watchdog: compute moves to the cloud, state goes into a store, execution environments stay on local devices; and outside the main system hangs an independent watchdog session that uses a model to judge whether Workers are making real progress — because the common failure of an agent is not a crashed process but an unproductive loop.
The design thinking here has been widely relayed; what deserves a closer look is the prototype source — we read the entire repository (MIT, TypeScript, 216 files), and three observations are invisible from the article alone.
First, the LLM is systematically locked into three cages. The model appears in exactly three places: assessment (read-only tools, bash and delegation forbidden), routing (one of four choices: accept / attach / stop / ignore), and doing the work (Worker sessions). Everything else is deterministic code: the scheduling loop is a two-second timer; concurrency merging, retry backoff, and recovery semantics all live in code. The article never states this position, but the code states it plainly: the model judges; the state machine holds every invariant.
Second, authorization is first-class data, not prompts. Every work ticket freezes an immutable authorization record (Mandate) at creation: who approved, on what basis, with what scope, under which configuration version. When configuration changes, the system recomputes the effect per ticket — work whose authorization basis has expired stops on the spot. Proactive work runs by default in a record-only observe mode, released for real execution only once a human is satisfied. This is the first open-source agent implementation we have read that turns "why is this agent allowed to do this" into a complete audit chain.
Third, the costs are stated honestly. The article admits its experiments use synthetic load (coding work replaced by sleep-only tools) and trade more tokens for time; the README's first line declares it a research prototype, not an official product, and notes that some designs are future directions; the BYOM cross-device execution and external watchdog discussed in the article show no corresponding implementation in the code — zero hits by both name and function across the repository.
3. Google's answer: evolution, or improving yourself when no answer key exists
The question Google starts from is entirely different: not how to schedule many tasks, but how the harness itself evolves with tasks. Harness²'s setup: an executor model, frozen inside an off-the-shelf coding agent (OpenCode or Codex); an improver session (by default Claude Opus 4.8) observes execution traces and directly rewrites the harness's eight components — system prompt, guardrails, long-term memory, tool guidance, subagents, skills, scripts, and plugin. Each component is a file, so every edit is a reviewable, revertible diff. The eight components activate differently: the system prompt, guardrails, memory, and tool guidance are present on every call; a skill enters context only when triggered, costing nothing when unused — load-on-demand is itself a layer of context economy.
The paper places itself in a clear lineage: early harness optimization searched offline for one good configuration on training tasks and deployed it (the Meta-Harness line), but static configurations often fail to generalize when the open world's task distribution shifts; another line turned memory into retrieval (ReasoningBank), distilling strategies from past trajectories back into context while leaving the harness itself unchanged. Harness² argues for a third road: the harness evolves recursively with tasks in the open world — and the improvement process itself must be improved. Both levels of recursion hang on this claim: the task level designs contrastive evidence for a world without verifiers; the harnessing level lets improvement experience persist across tasks.
The hard part: open-world tasks have no ground-truth answers and no reliable verifiers. How do you know a change is a real improvement? Harness²'s answer is contrastive evidence. The task runs once as a reference; the improver then proposes two candidate harnesses — one aimed at cross-domain execution deficiencies (planning confusion, tool misuse, context mismanagement), one at the current domain's knowledge gaps — each candidate executes on the same task, the improver compares trajectories and outputs, judges each edit as mitigated, unchanged, or regressed, and composes the adopted version with every decision bound to an observed behavioral fact rather than an imagined score gain.
Task-level improvement is only half the recursion. The real mechanism sits one level up: after the task, the system reviews the complete improvement record, distills "what change, under what conditions, fixed what deficiency" into experience, and stores it together with the adopted harness in an experience library. The next task does not inherit the previous harness — a highly tailored harness is noise under a different task distribution — but the improver starts with all the experience. Recursively improving the improvement process is what makes the whole system hold.
Four readings from the experiments:
- Weaker models gain more. GLM-5 after one improvement step (64.2 → 75.7) overtakes Gemini 3.5 Flash's stock harness (72.4 on OpenCode, 74.5 on Codex — overtaken on both); the harness refined for Gemini, moved to GLM-5 unchanged, adds +17.3 on code. A weaker model with an improved shell beats a stronger one in its stock shell — the marginal return of harness optimization is higher for weaker executors, which directly reshapes the economics of "buy the strongest model vs. tune the shell."
- The experience library is the linchpin. Refining the base harness task by task, with no reference executions, no candidate probes, and no library, drops WorkBuddy-Bench code from 73.4 to 63.2 — the plunge comes from naive rewriting without evidence or library combined (in the fine-grained ablation, removing the library alone costs only 3.1 points on WorkBuddy); a library accumulated at k=1 is already enough to restore the baseline. Contrastive evidence and accumulated experience are both required.
- Recursion at k=2 already beats the baselines at k=5 (on WorkBuddy's code and office domains). Parallel and sequential recursion at k=2 already exceed the two plotted baselines — retrieval memory (ReasoningBank) and per-task revision (Harness Scaling) — at k=5; the gain comes from editing the right thing, not from stacking rewrites, and in the paper's compute–score Pareto plot, both evaluated Harness² configurations sit on the frontier. Harness Scaling, which likewise spends additional inference budget on revising per task, lands below the base harness in 7 of 12 benchmark×configuration pairs.
- A model as its own improver also works. Five same-model pairings, from GLM-5 to Opus 5, all improve with executor and editor as one — no stronger teacher required.
The anti-cheating design in the implementation deserves its own record: everything the improver receives arrives as files in an isolated working directory, and a guard function refuses to hand over anything containing rubrics or grader verdicts — scanned by filename and by content. Even harness trees written by the agent itself pass the same check before entering the library: a contaminated file can no longer be served as evidence to later tasks.
The costs, again honestly: each improvement step means every candidate harness executes the full task once — k=5 recursion is five times the execution overhead plus improver sessions; the paper concedes parallelism cuts latency, not compute, and lists nine regression cases in its failure analysis — selection can pick the weaker candidate (an output scoring 55 beating one scoring 95), and a wrong premise propagates across candidates.
4. Face to face: two organs of the same system
| Dimension | DeepSeek Super-agent | Google Harness² |
|---|---|---|
| Question answered | Under multi-task concurrency, who schedules | Under task-distribution drift, who improves |
| What is frozen | The model | The model (executor and editor can be the same one) |
| Who guarantees invariants | A code state machine (single-writer engine, Mandate, admission matrix) | Contrastive-evidence discipline (behavioral contrast, experience library, guard function) |
| State across tasks | Thread/ticket reference graph + subscription pass-through | Experience library (adopted harnesses + EXPERIENCE.md) |
| Where changes land | The scheduling and authorization layer | The harness files themselves (every edit a diff) |
| Open-source form | MIT, research prototype, not a product | Apache-2.0, paper-grade implementation, actively maintained |
| Self-declared gaps | BYOM and watchdog unimplemented; synthetic load | Library management and adaptive budgeting as future work; nine regressions |
Step back, and the commonalities matter more than the differences. Neither touches model weights — keeping changes in the layer of text and code means every change is diffable, reviewable, and revertible, an engineering property no weight update has. Both move the guarantee of invariants out of the model — DeepSeek locks the model into three cages with scheduling on a timer; Google's improver is itself an LLM, but its judgment is constrained inside a frame of contrastive evidence and bound observations, with guard checks before anything enters the library.
Both set explicit defenses, against different threats — DeepSeek marks all external input as untrusted data and bans bash in assessment sessions, against prompt injection; Harness² refuses any grading information entry into model context, against benchmark leakage. The two arrive at the same recognition by different roads, with Anthropic's "brain/hand separation" phrase (explicitly cited in DeepSeek's article) as a corroborating witness: the trustworthiness of an agent's base layer comes from deterministic structure outside the model's discretion.
The divergence is in the time scale. Scheduling answers questions during a task — many work items advancing at once, how attention is allocated and authorization flows; evolution answers questions between tasks — how what the last task taught makes the next task better. One runs, the other iterates.
So the real question is not "who is right" but when the two answers converge. An always-on, multi-tasking agent inevitably needs its harness to evolve with tasks — Super-agent's prompts, admission rules, skills, and subagent configuration are, in Harness²'s sense, the eight components; conversely, Harness²'s improver running in a multi-task environment needs scheduling, authorization, and attention management. Scheduling and evolution are two organs that the same system will inevitably grow. Both are open source (MIT and Apache-2.0), which puts both blocks into the public domain — the major labs each bet on their own vertical stack and have little incentive to assemble someone else's blocks, so the assembly work is more likely to happen downstream.
5. Judgments
Harness engineering is being promoted from craft to discipline. Two independent pieces of evidence: Super-agent manages its nine design documents as code (one test file verifies that the architecture document matches the actual files); every Harness² improver session carries cost-audit fields (dollar cost, cache hits, attempt counts) — improvement itself is treated as a measurable engineering process. Prompt-craft never had these; when a field starts doing consistency checking and cost accounting, it has become an engineering discipline.
The reference-implementation land grab has begun. DeepSeek has made three moves in the three months since August: the Harness runtime in August, the DeepInfer inference engine in mid-October, the Super-agent architecture at the end of October (about 14,000 stars within three days); Google set the standard with a paper-grade implementation under Apache-2.0. The fight for definitional power at the base layer has moved up from the model layer to the harness layer — and open-sourcing here is not a gesture; it is a first-mover move.
The direct implication for developers: a weaker model with a well-tuned harness is an undervalued trade. GLM-5 overtaking Gemini's stock shell, +17.3 from cross-model transfer, self-improvement holding across the board — the price-performance formula for model procurement is being rewritten by the marginal returns of harness optimization. In agent scenarios where inference cost dominates, that is real money.
The verification points stand here too: when Harness²'s self-declared library management and adaptive budgeting (allocating exploration by task difficulty) arrive; when the BYOM and watchdog promised in the Super-agent article turn from design into code; and where the first open-source implementation appears that fuses scheduling and evolution in one system. Both write their unfinished business in plain sight — another shared trait of this wave of work: publishing "what we cannot yet do" as part of the paper and the code.
Sources
- Harness² paper, arXiv:2610.14224 (2026-10-09); code at github.com/google-research/harness2 (Apache-2.0, 140 files)
- dsh-superagent-prototype at github.com/deepseek-ai/dsh-superagent-prototype (MIT, 216 files); DeepSeek Harness team, "Exploring Super-agent Design: Towards a More Autonomous Agent System" (2026-10-31, full text via Zhidongxi and other reposts)
- All source files of both repositories pulled and read on 2026-11-03, with file and star counts as same-day readings (both repositories keep updating); experiment numbers from the paper's body and appendices