Engineering brief
Stop Blaming the Model: Your Agent Harness Is the Real Problem
At a glance
The brief is enough
- Relevance
- Practical value
- Radar
- Time horizon
- This year
- Warnings
- None
Most agent harnesses are the same. Alex Zhang argues the real signal is opinionated harness design—RLMs being one example—that forces models to learn shared solution structures.
Agent harness design, not model capability, is the bottleneck for reliable long-running task execution.
Watch if you are designing agent infrastructure for a platform team and need concrete harness architecture.
Summary
The core insight. Alex Zhang argues that most agent harnesses—Claude Code, Codex, Cursor—are functionally identical. The real opportunity lies in designing opinionated harnesses that change how models generalize, not in incremental tooling improvements. The recursive language model (RLM) is one such design: a harness where the only tool is code, and every sub-agent call runs inside an IPython kernel with context offloaded to a file system. This lets the model decompose tasks into locally in-distribution subtasks, even when the full problem is out of distribution.
Why this matters now. Zhang points out that frontier models are already capable enough to handle most tasks reliably for a month, but current harnesses fail to deliver that. He calls this a "skill issue"—not a model capability problem. The evidence: Harvey, a legal AI company, post-trained an RLM on legal document work and got strong results. The RLM abstraction also powers Prime Agent, which uses a persistent sub-agent system and a "continual harness" that lets the agent modify its own tools and system prompt.
The generalization argument. Zhang's key claim is that RLMs naturally generalize across tasks because the meta-strategy (spawn sub-agents, verify solutions) stays the same even when the domain changes. Training on short tasks transfers to tasks 8–30 times longer, and training on math tasks transfers to writing tasks. This is not magic—it's the result of the harness forcing the model to learn a shared solution structure rather than task-specific trajectories.
What's missing. The evidence is still largely anecdotal or based on internal results. Zhang acknowledges that most published results are from collaborations with Prime or Harvey, and that training RLMs at scale requires compute he doesn't have as a PhD student. He also notes that OpenAI's swarm approach for solving Navier-Stokes cost an estimated $40 million, which raises questions about the efficiency of current multi-agent designs.
The trade-off. RLMs are slower and more expensive than compaction-based harnesses for simple tasks. Zhang recommends using simpler approaches for the 95% of cases where they suffice. The benefit of RLMs comes when you need reliable long-running task execution or generalization across very different domains. The cost premium may not be justified for most teams yet.
What teams should watch. Zhang believes we will see dedicated models trained specifically for RLM-like workflows, and that the boundary between model and harness will blur. Teams should track whether Prime or others release post-trained RLM models that are both capable and cost-efficient. For now, the practical value is mostly in understanding the design principles: offload context to code, let the model write its own tools, and treat harness design as a first-class optimization problem.
My take
I buy the core argument that harness design is under-optimized, but I'm not sold on RLMs as the answer for most teams. The cost premium and complexity are real barriers, and the published evidence, Harvey's results aside, is still thin. What I find more useful is the framing: treat your agent scaffold as a design problem, not a product choice. Most teams pick Claude Code or Cursor and stop thinking. That's where the slack is. I'd rather see teams run their own small experiments: replace the default tool loop with an offloaded-code harness and measure whether task completion rates improve before committing to a full RLM architecture. The idea is right; the implementation details still need to be worked out by practitioners, not PhDs.
What to do with this
- Run a 2-week experiment: compare your current code agent harness against a minimal RLM-style harness (context offloaded to filesystem, only code tools).
- Audit your team's agent usage: identify which tasks consistently fail after 10+ steps, those are the candidates for a redesigned harness.
- Ask your AI tooling vendor (Cursor, Codex) how they handle context offloading and persistent sub-agents. Push for a concrete roadmap.
Watch the video
This video is blocked due to your privacy settings. To watch this video, please accept YouTube marketing cookies.
Related breakdowns
Cerebras CTO: 200 TPS is the new batch mode—ultra-fast inference changes everything
Cerebras CTO Sean Lie on why 200 TPS is becoming 'batch mode,' how CS4 is already inside OpenAI for real-time incident response, and why CS5 will push…
Voice AI: The hard parts are pipeline design and latency, not models
Voice AI success hinges on pipeline orchestration, not model choice. Latency, cost, and reliability are the real constraints. Teams should expect a hybrid…
Your inference stack is now writing its own GPU kernels
Baseten's GLM52 is writing its own GPU kernels in production. This shifts inference from static optimization to a continuous learning loop. The bottleneck is…
Get TL;DW
Too Long; Didn't Watch.
A concise breakdowns of the AI and devtools videos that actually matter for engineering leaders.
Free. Weekly. No hype.
Video and thumbnails remain the property of their respective creators. tldw.news provides editorial analysis, commentary, and discovery links to original content.