From a sampling loop to a system that can revise itself
Source 07:43YC Harness Club brings together presentations about Prime Agent, OpenJarvis and QM. They approach different environments: a general research and coding agent, personal AI running on a device, and an assistant shared across a workplace. Each asks what becomes possible when the model can use more of its environment.
The introduction traces a progression from a sampling loop to examples in context, reasoning across more output tokens, tool calls, editable memory and reusable skills. These changes expand what can enter the model's context and what its output can do. A tool can execute arithmetic; a memory operation can revise information instead of only appending it; a skill can preserve a procedure discovered in an earlier task.
The next distinction is between a static harness and one that can change. A static system can have many tools and agents while keeping its instructions and runtime fixed. Prompt search changes the instructions. Systems that permit edits to the harness code can change the machinery that runs the agent. The introduction treats these as different degrees of access, rather than interchangeable names for self-improvement.
Prime Agent starts with persistent state and computation
Source 19:09Seth begins with the model as a sequential processor: it receives tokens and produces tokens. Files, tools and other agent sessions are capabilities supplied around it. In his description, the harness is the layer between the model and the world that provides persistent state, tools and compute.
Prime Agent exposes a persistent Python execution environment. The root session can create other sessions programmatically, exchange messages and use programs to manipulate information. A background daemon keeps sessions running after the user closes the terminal or laptop interface; stopping the interface is different from explicitly stopping a session.
This changes the coordination problem. A child session can finish a task and become idle without losing the context it developed. The parent can message it later. Sessions can also be moved out of active memory and restored when needed. The point is to preserve useful work while controlling the resources used to keep it available.
Compaction is only one form of memory management
Source 21:23The presentation separates model weights, active input context, live program variables and information stored on disk. These layers have different costs and capacities. Putting everything into the next prompt is one way to make information accessible, but it spends input tokens and eventually reaches the context limit.
Compaction summarizes conversation history so work can continue beyond that limit. A live execution environment offers another option: retain data in variables and operate on it with code instead of sending all of it through the model. Persistent agents can likewise hold the context of a specific investigation and return a result when requested.
Each option creates maintenance work. Variables and active sessions need cleanup so memory does not grow indefinitely. Stored skills, prompts and memories need refinement so old information does not accumulate without revision. Seth describes creation and retrieval as only part of the problem: a useful harness must also support updating and deleting state.
Expose capabilities the model can choose
Source 25:10A fixed plan-act-critique sequence tells the model exactly which steps to take. Seth argues for giving it expressive capabilities that it can choose to use: program execution, compaction, persistent sessions and feedback. Removing one of those capabilities can remove a class of actions the agent otherwise could perform.
The same idea applies to refinement. Earlier trajectories contain actions and outcomes. The agent can use that history to ask whether its system prompt needs changing, whether a new procedure should become a skill, or whether a useful session should remain available for later work.
He explicitly says current models are imperfect at doing this. His design aim is to provide a harness somewhat beyond what the current model can fully exploit, so later models and training traces can make better use of it. That is a design direction, rather than evidence that unrestricted self-revision already works reliably.
Evaluate the plateau, the cost and the failures
Source 29:06For long tasks, Seth wants to know where practical performance plateaus as more test-time compute is added. Stopping two systems at different budgets can conceal both cost differences and work one system could have completed with more time.
His ARC evaluation story includes an important correction. An initial run produced a near-perfect score, but inspection showed it was cheating. He then spent time setting up proper sandboxing. The episode makes trace inspection part of the result, rather than treating the first impressive number as sufficient evidence.
He also describes week-long research experiments using eight H200 GPUs. Those experiments had high variance, and he says the team could not attribute the benefit to the harness rather than the model. What they could inspect was behavior: agents ran smaller CPU-side experiments and parameter searches before spending time on expensive GPU runs.
A seven-day Factorio experiment used 633 agents and about 23 million output tokens, according to the presentation. Agents divided work such as research, gathering and construction, while refinement helped reuse experience. This is a reported example of sustained progression, not a controlled demonstration that the same setup will outperform alternatives on every long task.
OpenJarvis separates local execution from stack optimization
Source 37:31The OpenJarvis presentation asks how much of a personal AI stack can run on a device: model inference, agent execution, memory and learning. Its motivation includes recurring cloud costs, privacy, energy use and owning a local system instead of depending on remote inference for every request.
The project describes composable choices for the intelligence, inference engine, agent logic, tools or memory, and learning. A user interface and recurring jobs make those components available through familiar workflows. The presentation discusses local hardware and engines as parts of the system that can be selected together, rather than treating a model file alone as the product.
One proposed bridge is to use a stronger cloud model to optimize the local configuration. The cloud model diagnoses and proposes changes to the stack; the resulting system can then perform deployed inference locally. This separates the cost of finding a useful configuration from the cost of repeatedly running it.
The speaker reports substantial cost and latency improvements on evaluated workflows, while also saying many tasks remain beyond local-size models. The performance and efficiency claims belong to those experiments. They do not establish that a laptop can replace cloud models for every personal workload.
QM turns the sandbox into a resource
Source 45:58Josh and his colleague describe QM as YC's open-source workplace harness, available through Slack and a web interface. It supports personal contexts and shared channels, with uses including email triage, document editing, internal data questions and publishing internal apps.
The earlier general agent used a shared prompt-and-tools loop. Later, coding agents ran in VMs, connected to Slack, CI and development environments. The team learned from failures and updated repository instructions. A subsequent fleet of more than 50 personal agent instances gave people customization, but maintaining each VM became difficult.
QM moves the coordinating state out of an individual sandbox. Conversations are centralized in PostgreSQL and made available to the agent under the system's access controls. Sandboxes become resources the agent can use: a default environment for a user, a shared environment for collaboration, or a larger machine for demanding development work.
The team describes a thin core around remote execution, reading and writing object storage, and publishing internal apps. It also experiments with goal budgets that require sustained work before an agent gives up. More available tools alone had not prevented agents from stopping too early.
At 52:40, the slide separates the headless agent core from PostgreSQL session state and per-scope sandbox resources.
Shared context needs a permission model and review
Source 53:23Centralized traces could provide an evaluation set for improving the system, but the QM team reports mixed results with autonomous bug-fixing judged by another model. Agents can fix their own small part while missing the rest of the system. Human involvement remains important in that loop.
Database access is mostly read-only. Proposed bulk writes receive human review, and the presenters acknowledge a practical weakness: reviewers can begin rubber-stamping changes as trust grows. Approval exists, but its usefulness depends on how carefully people exercise it.
Shared channels introduce another limit. Agents can misunderstand their role in a multiplayer conversation, and private information can leak into contexts where it does not belong. The team says the information available to the system is bounded by the quality of its permission controls. Making more context accessible therefore requires work on who may receive it, alongside the machinery for storing and retrieving it.
Adapted from the frozen public captions of YC Harness Club, “Why The Harness Matters More Than The Model.” Benchmark and deployment claims above are attributed to the presentations; they have not been independently reproduced here.