Start with how harnesses power the two InferenceNet challenges and what a harness is, then see how runnable Agent Harness systems evolved in 2025–2026 and how Harbor integrates diverse harnesses into a unified evaluation system. Next, inspect DeepAgents in detail, compare our four evaluated configurations side by side, and connect execution to self-evolution.
InferenceNet Challenge invites participants to build agents for empirical research and business analysis. A harness organizes context, tool execution, state and verification around a model. Our current multi-harness comparisons and self-evolution experiments were completed in Phase 1 on econometric replication; extending harness adaptation to the finance and HR workflow on Harbor and Claude Code is the next stage.
01 · Context and information
What enters each step
Arrange how task requirements, domain rules and source materials enter the context, and preserve key findings, intermediate progress and unresolved questions across long runs.
02 · Tools and actions
How the agent acts on data and files
Provide clear operations for inspecting datasets, running statistical or financial scripts, and generating documents or workbooks, returning structured execution output to the model.
03 · Checks and recovery
How errors and gaps become feedback
Turn runtime errors, statistical diagnostics and file readbacks into evidence for the next decision so the model can revise its analysis or deliverables before stopping.
04 · Resources and delivery
How limits and final outputs are enforced
Manage permissions, call caps, token budgets and sandbox timeouts, and check that required outputs exist, retain required formulas or code, and follow the submission format.
Subtrack 01 · Phase 1 completed
Econometric replication: four harnesses on Dev100
Evaluated in InferenceNet’s own runner with an isolated run_python sandbox tool. An agent inspects research data, implements sample and estimator specifications, and submits a final Python program for private scoring. In Phase 1 we evaluated 14 models across four harness configurations—DeepAgents, DeepSeek Harness, Claude Agent SDK and an OpenAI Agents SDK runtime—on the 100-task Dev100 set, and studied modular harness self-evolution on DeepAgents.
Business Analysis & Deliverables: Harbor + Claude Code
The finance and HR tasks contributed by Prof. Liwen Zhang’s team at SUFE currently use the Harbor (0.20.0) evaluation framework driving Claude Code (2.1.114) to reconcile multi-file evidence and produce Word (.docx) and Excel (.xlsx) deliverables for independent rubric grading. Multi-harness comparisons and harness evolution have not yet been run on this subtrack; adapting custom verification hooks and harness profiles to Harbor is our next stage.
The harness is the layer between a model and the task environment. It decides what the model sees, what it can do, how errors come back and when the run stops.
L1
Model
Reads the context it is given and proposes the next step or tool call.
Model
Next step
L2
Harness
Assembles context, exposes tools, turns errors into feedback and enforces limits and output checks.
Context
Tools
Feedback
Run limits
L3
Environment
The sandbox, data and files the agent acts on, and the evaluator that scores the final output.
Sandbox
Data and files
Evaluator
Interactive modelDrag to rotate
01 / Definition
What a harness is
A harness is the software that runs a language model as an agent: it decides what the model sees at each step, carries out the tool calls the model makes, returns the results, keeps the state of the run and decides when the run stops.
What a harness covers. The model only maps one context to one reply; the harness does everything else that makes it an agent. The environment the tools act on and the evaluator that grades the answer are outside the agent, which is why a benchmark such as InferenceNet can swap either the model or the harness and score the pair.
Definition details: terms, responsibilities and boundaries
A model takes text in and returns text. Anthropic defines an agent harness as “the system that enables a model to act as an agent” and adds that evaluating an agent means “evaluating the harness and the model working together”. LangChain puts the relationship as “Agent = Model + Harness”. The same model can score differently in a different harness, so a result belongs to the pair. Evaluation papers often call the same layer a scaffold.
The 1,000-task Selected_1000 board follows this split. A Model row is a single call with no agent loop: one code-generation call, after which InferenceNet executes the returned program. A Model + Harness row runs the model inside a named harness: the harness passes the model’s code to the run_python tool that the evaluation supplies and returns the tool’s feedback to the model before it submits a final program. The tasks, data, sandbox, budget and scorer belong to the evaluation, not to the harness. The Dev100 v10 development board has no Model rows: it runs 14 models in four harness configurations (section 06).
Six terms and where each one ends
The words this site uses, with the boundary each one draws
Term
What it is
Where it ends
In InferenceNet
Model
A language model behind an inference API: it reads one context and writes one reply, text and tool calls
It keeps nothing between calls and runs no tools. Request settings such as temperature or reasoning effort are set by whoever builds the request, often the harness
The model named in each leaderboard row
Harness
The software that runs the model as an agent: it builds the context, runs the loop, executes tool calls, keeps state, hands work to other agents, enforces limits and decides when to stop
It excludes the model’s weights, the environment its tools act on and the evaluator. An extension such as a skills plugin changes a host harness but is not a harness itself
DeepAgents, DeepSeek Harness or Claude Agent SDK; in the fourth Dev100 v10 configuration, a runtime InferenceNet assembles with the OpenAI Agents SDK
Agent
A model running inside a harness on a task: Agent = Model + Harness
The same model in another harness is another agent and can score differently
A Model + Harness row on Selected_1000, or any Dev100 v10 row
SDK
A programming interface. A model SDK sends requests to a model API; an agent framework SDK supplies building blocks; a harness SDK starts or embeds a ready harness so code can drive it
An SDK is a way in, not a layer of its own: one harness can be reached through a CLI, an SDK or a protocol
The DeepSeek Harness Python SDK starts the dsh process and the Claude Agent SDK runs its bundled Claude Code CLI; DeepAgents is imported as a library, and InferenceNet assembles its own runtime from the OpenAI Agents SDK
Environment
What the tools act on: files, a shell or container, data and outside services
The harness gives the model an interface to it; the environment itself is not part of the harness
The task’s data and a fresh container for each run_python call
Evaluator
The tasks, the limits, the code that runs trials and the grader; benchmarks often call it an evaluation harness
It sits outside the agent so that any model and harness can be scored the same way
InferenceNet’s budget, final replay and private scorer
Eight things every harness decides
Runs on
Where the harness runs and how it is driven: a library in the caller’s process, a separate CLI or server process, or a hosted service, and how it reaches models.
library
CLI or server
hosted service
model adapters
Execution loop
The control flow of a run: call the model, turn its reply into actions, run them, add the results and repeat, with hooks or events between the phases.
step
hooks or events
parallel calls
Tools
The actions the model can request and how each is carried out: the tool list and descriptions, the executor behind each tool and the result returned to the model.
built-in tools
MCP
executor
result format
Context and memory
What the model sees on each call and what is kept: system prompt, instruction files, the running history and its compaction, large results moved aside, and anything carried across runs.
system prompt
AGENTS.md
compaction
session log
Delegation
Whether and how work is handed to other agents: subagents with their own context, parallel workers, and how their results come back to the main run.
subagents
fresh context
depth limit
Stopping and recovery
When a run ends and how it survives failures: a reply without tool calls, a limit or a rejected step; retries, summarizing on overflow, resuming an interrupted run.
stop condition
step limit
retries
resume
Permissions and limits
Controls that hold whether or not the model cooperates: which tools may run and which need approval, sandbox and file permissions, and turn or spend limits inside the harness.
permissions
approval
sandbox
budgets
Extension points
How behavior is added or replaced without changing the harness’s own code: middleware or hooks, plugins, skills, MCP servers, custom tools and configuration profiles.
middleware
hooks
plugins
skills
profiles
Where a harness sits
Layers are roles, not fixed boxes: the same package is sometimes placed in two layers, and many harnesses use no agent framework at all.
Layer
What it provides
Examples
Runtime
Durable execution, persistence, streaming and human-in-the-loop pauses
LangGraph, Temporal
Framework
Building blocks: model and tool interfaces, an agent loop, middleware
LangChain, OpenAI Agents SDK, Google ADK, CrewAI; since April 2026 the OpenAI Agents SDK also ships sandbox agents, a harness layer introduced as a beta
Harness
A ready agent: default prompts, built-in tools, context management, state and controls
Deep Agents, the harness inside Claude Code, the Codex harness, DeepSeek Harness, mini-SWE-agent
Product
Surfaces people use; one harness can sit behind several
Claude Code, the Codex app and CLI, Cursor, Deep Agents Code
Platform
Hosts or routes a chosen harness for a team, an API or a chat gateway
QM, OpenAgentCore, OpenClaw’s Gateway
Extension
Packages loaded into a harness that add instructions, workflows, tools or hooks
Agent Skills, MCP servers, Claude Code plugins, Superpowers
Optimizer
A process that proposes, tests and keeps harness versions using feedback: offline, as an outer loop between runs, or online, editing the harness across a stream of tasks or within one run
ModularRSI, Self-Harness, Meta-Harness (offline, section 05); other regimes on the Self-evolving map
02 / Harness systems
Agent Harness systems, 2025–2026
First the structure: where a runnable harness sits among the systems that host it, the extensions it loads and the roles around it. Then a curated timeline of design changes, a common comparison of seven systems and a catalogue.
A benchmark supplies tasks and scores; a protocol connects tools; a framework supplies building blocks. They belong to the surrounding ecosystem, but are different comparison units from a configured, runnable harness.
The counts measure different things: 28 timeline milestones trace runnable harnesses, platforms, extensions and self-evolution methods across 2025–2026, 7 representative systems are compared mechanism by mechanism, and the Harbor section shows how diverse harnesses plug into one unified evaluation pipeline.
What belongs to the harness — and what surrounds it
The runnable harness is the unit compared on this page. Above it, OpenClaw’s gateway chooses a runtime per model, Qwen-Live-Harness runs a realtime voice and video loop that hands tasks to a background harness, and platforms such as QM and OpenAgentCore run the harness they select. Extensions load into a host; optimizers change a harness offline between runs or online across tasks or within a run. Names are representative; primary repository links are collected in section 06. Survey: taxonomy (§2.3) and systems (§6) · Claude Code architecture · OpenClaw runtimes · Qwen-Live-Harness · Self-evolving: optimization regimes
How the systems changed, 2025–2026
Twenty-eight milestones across four lanes: interactive and CLI harnesses, programmable and plugin runtimes, managed or durable platforms, and skills extensions or self-evolution methods, based on verified releases, repositories and papers in 2025–2026.Milestone dates and primary sources
28 developments across runnable harnesses, platforms, extensions and self-evolution
A separate dsh process; the loop itself is a Cordis plugin
Prompt sections each step; history rebuilt from an append-only JSONL log; compaction at 80%
Up to 5 retries per step; resume closes interrupted turns
About 25 tools in the sdk profile; OS file sandbox
Continuable or forked child agents, depth 3
Approval policy and timeouts; Cordis plugins from bundles and patch files
02.4 / Unified evaluation
Integrating diverse harnesses into a unified evaluation system via Harbor
Harnesses differ widely in how they are packaged: some are Python libraries (DeepAgents, OpenAI Agents SDK), some are standalone CLI binaries or JSON-RPC servers (Claude Code, DeepSeek Harness, Codex CLI, OpenCode), and others are minimal reference loops (Terminus-2, mini-SWE-agent). The Harbor evaluation framework unifies them behind a single task-and-container contract so every Model + Harness pair faces the same environment, budgets and independent verifier.
How Harbor turns heterogeneous harnesses into one comparable evaluation system. The task package, container workspace and final verifier stay identical across runs; only the mounted (Model, Harness) pair inside stage 2 changes.
01 · Standardized task bundle
One task format across domains
Packages the prompt, input datasets or business documents, environment image and resource limits while keeping reference values and grading rubrics outside the container.
02 · Pluggable agent adapter
Mount CLI, SDK or library harnesses
Wraps standalone CLI agents (Claude Code, Codex, OpenCode), JSON-RPC processes (DeepSeek Harness) and Python graph libraries (DeepAgents) behind a uniform run interface and model-routing proxy.
03 · Isolated execution & hooks
Reproducible sandboxes and pre-submit checks
Executes every tool call in an isolated container and records full JSONL trajectories, making it straightforward to inject statistical diagnostics or Word/Excel readback hooks before submission.
04 · Out-of-loop verification
Independent replay and rubric scoring
Grades the submitted Python program or business deliverables in a clean verification pass after the agent terminates, separating execution errors and verifier errors from task scores.
03 / Breakdown
Anatomy of a harness: DeepAgents 0.7.13
To see how a harness works on the inside, we break down DeepAgents (LangChain’s library harness, pinned at 0.7.13 in InferenceNet Phase 1) across the eight core responsibilities: its three-layer LangGraph architecture, its middleware stack, one complete run from start to finish, and how InferenceNet wires and evolves it.
DeepAgents 0.7.13 Library harness
Middleware around a LangGraph loop
DeepAgents is a Python library built on LangChain. Its main function, create_deep_agent(), takes LangChain’s standard agent loop (create_agent) and adds middleware, code that runs around every model and tool call, plus file tools, helper agents called subagents and a place to keep files. The result is a LangGraph graph that runs inside the caller’s own Python program. Most of what it adds keeps the model’s input within its context window.
Maker
LangChain
License
MIT
Form
A Python library whose main function, create_deep_agent(), returns a compiled graph
Runs on
The caller’s Python process (3.11 or later), on LangChain’s create_agent and LangGraph. 0.7.13 accepts langchain 1.3.18 or later, below 2.0; this page reads it with langchain 1.4.0 and langgraph 1.2.11, the versions InferenceNet pins
Models
Any LangChain chat model that supports tool calling
Version
deepagents 0.7.13 (1aae374), 2 Sep 2026, the version InferenceNet pins; upstream reached 0.7.23 on 7 Oct 2026
Use
pip install deepagents==0.7.13, then create_deep_agent(model=…, tools=[…]) and invoke it with a list of messages
The template: eight slots
DeepAgents 0.7.13 with its defaults, in the template every breakdown uses. Blue marks context and memory, the slot that most of its own code serves: a virtual file system for notes and offloaded results, summarization that moves old history into a file, subagents that work in a fresh context, and skills and AGENTS.md memory when configured. InferenceNet configures it differently (section 06).
One run, module by module
One run of a DeepAgents agent with the default stack, read from the pinned source. Blue boxes are where permissions are checked; the arrow on the left is the loop back to the model node; numbers in the right column refer to the steps.
How DeepAgents is assembled
The three layers assembled by create_deep_agent(). The left column is the middleware order; for wrap_model_call, earlier entries wrap later ones. New middleware from the caller lands between core and tail; middleware whose name matches an existing entry, core or tail, replaces it in place. Filesystem, Summarization, PatchToolCalls and Anthropic prompt caching are always added, and SubAgent too while any synchronous subagent exists, which by default is the general-purpose one. Skills, AsyncSubAgent, Memory and HumanInTheLoop depend on their arguments; profile extra_middleware and _ToolExclusionMiddleware on the model’s harness profile; Bedrock and Fireworks caching on langchain-aws or langchain-fireworks being installed. The LangChain and LangGraph layers describe langchain 1.4.0 and langgraph 1.2.11; the compiled middleware, nodes and channels come from building InferenceNet’s agent (dev-gyc-eval, 92e56c8) offline with those versions. The blue slot marks where caller middleware lands: InferenceNet’s own FilesystemMiddleware, limited to six file tools, replaces the core entry of the same name instead, so the slot stays empty until ModularRSI attaches there on the Self-evolving page.
Three layers: LangGraph, LangChain, DeepAgents
What each package contributes to a DeepAgents agent at the versions InferenceNet pins. The Self-evolving page builds on this stack and links back here.
Layer
Package
What it contributes
Runtime
langgraph 1.2.11
Executes the compiled graph in supersteps, keeps state in channels, saves a checkpoint after each superstep when a checkpointer is passed, pauses for interrupts and raises an error past the recursion limit
Framework
langchain 1.4.0, create_agent
Builds the model node, the tools node and the hook nodes; defines the six middleware hook kinds; sends each tool call to the tools node as its own task; sets the recursion limit to 9,999
Harness
deepagents 0.7.13, create_deep_agent
Chooses the default middleware stack, the file tools and storage backends, the general-purpose subagent, summarization and the harness profiles
The default middleware stack
What create_deep_agent() passes to LangChain’s create_agent in 0.7.13, in order. For wrap_model_call and wrap_tool_call the first entry is outermost.
Order
Middleware
Hooks
What it does
1
SkillsMiddleware, with skills=
before_agent, wrap_model_call
Lists each skill’s name and description in the system prompt; the model reads a skill’s full file when it needs it
2
FilesystemMiddleware, always
tools, wrap_model_call, wrap_tool_call
Adds ls, read_file, write_file, edit_file, delete, glob, grep and execute over the backend; hides what the backend cannot serve; moves tool results over 20,000 tokens into files; applies permissions= rules
3
SubAgentMiddleware, while a subagent exists
tools, wrap_model_call
Adds the task tool, which runs a subagent on a fresh message list and returns its final message
4
SummarizationMiddleware, always
wrap_model_call
Summarizes older messages once the history reaches 85% of the model’s input window and keeps the most recent messages that fit in 10% of that window; when the window is unknown, it summarizes at 170,000 tokens and keeps the last six messages. Saves the evicted history to a file and retries after a context overflow; summarized messages stay in state
5
PatchToolCallsMiddleware, always
before_agent
Adds a result for any earlier tool call that never got one
6
AsyncSubAgentMiddleware, with async subagents
tools, wrap_model_call
Starts, checks, updates, cancels and lists background tasks on remote Agent Protocol servers
–
The caller’s middleware=
any
Inserted after the entries above; an entry with a default’s name replaces that default in place
7
Profile extra_middleware
varies
Model-specific additions; the built-in Codex profile adds TodoListMiddleware and its write_todos tool
8
Prompt caching, always
wrap_model_call
Adds Anthropic cache markers, and Bedrock or Fireworks ones when those packages are installed; other models ignore it
9
MemoryMiddleware, with memory=
before_agent, wrap_model_call
Loads the listed AGENTS.md files once and adds them to the system prompt
10
HumanInTheLoopMiddleware, with interrupt_on=
after_model
Pauses before matching tool calls run; a person approves, edits, rejects or responds
11
Tool exclusion, if a profile excludes tools
wrap_model_call, wrap_tool_call
Removes excluded tools from each request and rejects calls to them
In 0.7.23, SkillsMiddleware moves to just before prompt caching and UnsupportedContentMiddleware is added after HumanInTheLoopMiddleware.
One task, step by step
01
Assemble the agent once
create_deep_agent() resolves the model and its harness profile, builds the middleware stack, the general-purpose subagent and the tool list, and hands them to LangChain’s create_agent, which compiles a LangGraph graph.
Default backend
StateBackend, files in graph state
Recursion limit
9,999
02
Enter the graph
invoke() starts the graph and runs the before_agent hooks once. In the default stack only PatchToolCallsMiddleware has one: it answers any earlier tool call that never got a result. Skills and memory, when configured, load their files here.
Default before_agent
PatchToolCallsMiddleware
03
Shape the request
The model node builds a request from the model, the tools, the system message and the history, and passes it through the wrap_model_call chain, outermost first. File tools the backend cannot serve are dropped, history past the threshold is summarized and cache markers are added.
Summary trigger
85% of the input window, else 170,000 tokens
04
Call the model
The innermost handler binds the tools and calls the chat model with the system message followed by the history; one AI message comes back. If the provider rejects the request as too long, the history is summarized and the call is made again.
Model input
system message, then the history
05
Route on the reply
after_model hooks run; the default stack has none, while human-in-the-loop adds one that can pause for approval. A reply without tool calls leaves the loop; otherwise each tool call goes to the tools node as its own task.
No tool calls
leave the loop
06
Run the tool calls
Each call passes the wrap_tool_call chain and runs as a task in the same superstep, so the calls of one reply run concurrently. Oversized results move into backend files; task runs a subagent and returns its last message. The results go back to the model node.
Result offload
over 20,000 tokens
07
End the run
When the model replies without tool calls, any after_agent hooks run and the graph ends; invoke() returns the final state, whose last AI message is the answer. Passing the recursion limit raises an error. Within a run, state passes from one superstep to the next as usual; a checkpointer, if one is passed, saves a checkpoint after each superstep so the run can be resumed later.
Answer
the last AI message
Checkpointer
none unless passed
In InferenceNet. InferenceNet’s DeepAgents arm runs this version with run_python and six file tools for notes, no subagents, and its own budget outside DeepAgents. It is the harness of the Selected_1000 Model + Harness rows and one of the four Dev100 v10 configurations (section 06); the ModularRSI study on the Self-evolving page starts from it with its own settings.
How InferenceNet wires DeepAgents for evaluation
InferenceNet’s DeepAgents evaluation wiring. Blue marks what InferenceNet configures around DeepAgents 0.7.13: a budgeted model client, six virtual file tools for notes, and the isolated run_python container tool.
In Phase 1 (Dev100 v10), InferenceNet evaluated 14 models across four harness configurations on the same 100 econometric replication tasks: DeepAgents, DeepSeek Harness, Claude Agent SDK and an OpenAI Agents SDK runtime. Below are the four configurations and a side-by-side comparison of their architecture, loop control, context management and evaluation wiring.
The four configurations in Dev100 v10
Library harness
DeepAgents 0.7.13
Runs the loop: LangChain’s create_deep_agent on LangGraph, inside InferenceNet’s Python process.
InferenceNet sets: run_python and six file tools for notes; no subagents.
Product harness
DeepSeek Harness 0.1.5rc1
Runs the loop: DeepSeek’s own dsh process, driven by the official Python SDK over JSON-RPC on stdio.
InferenceNet sets: a restricted profile whose only tool is run_python.
Harness SDK
Claude Agent SDK 0.2.165
Runs the loop: the Claude Code CLI bundled with the SDK, version 2.1.294 in every recorded identity.
InferenceNet sets: no built-in tools and no settings files; run_python as the one MCP tool; at most 6 turns.
Agent framework
OpenAI Agents SDK 0.23.1
Runs the loop: the SDK’s Runner, in a runtime InferenceNet composes from the framework’s parts.
InferenceNet sets: run_python as the one function tool; no built-in tools; at most 6 turns.
The four evaluated harness configurations compared across the eight core dimensions
Dimension
DeepAgents 0.7.13
DeepSeek Harness 0.1.5-rc.1
Claude Agent SDK 0.2.165
OpenAI Agents SDK 0.23.1
Category
Library harness on LangChain & LangGraph
Plugin-based product harness driven via Python SDK
Harness SDK driving bundled Claude Code CLI (2.1.294)
Agent framework Runner assembled by InferenceNet
Runs on
Caller’s Python process; compiled StateGraph in Pregel supersteps
Separate Node.js / binary dsh process over stdio JSON-RPC 2.0
Subprocess running the bundled Claude Code CLI binary
Caller’s Python process via Runner.run loop
Execution loop
model ⇄ tools graph with wrap_model_call and wrap_tool_call middleware
dsh-agent-loop Cordis plugin with waterfall events around each phase
Turn-based model-to-function-tool loop up to the configured turn cap
Tools in Dev100
run_python plus six virtual file tools (ls, read_file, write_file, edit_file, glob, grep) for notes
Restricted 14-row profile: run_python is the only tool
Built-in tools disabled; run_python exposed as the single MCP tool
No built-in tools; run_python bound as the single function tool
Context & memory
Virtual files in graph state; offloads tool results >20k tokens; summarizes at 85% window
Append-only JSONL session log rebuilt each step; stock compaction disabled in restricted profile
Session transcript managed by Claude Code CLI; local settings files disabled for isolation
Linear message history passed across turns within the run
Delegation
Supports task subagents by default; turned off in InferenceNet for controlled comparison
Supports depth-3 child agents in stock profile; turned off in InferenceNet profile
Supports subagents in stock Claude Code; disabled in restricted Dev100 configuration
Handoffs supported by SDK; single-agent loop used in Dev100
Stopping & limits
Stops on a reply without tool calls; capped at ≤6 model calls, ≤4 run_python calls, 1,800 s
Stops at turn/end; same 6-model / 4-tool / 1,800 s caps enforced by bridge
Stops on final response or max_turns=6; same 4-tool and 1,800 s caps
Stops on final response or max_turns=6; same 4-tool and 1,800 s caps
Extension surface
Python AgentMiddleware hooks and HarnessProfile (used for ModularRSI evolution)
Cordis plugin bundles and declarative YAML patch files (cordis.patch.yml)
MCP tool servers, lifecycle hooks and CLAUDE.md / skill packages (used on Harbor in Subtrack 2)
Python function tools, guardrails and run hooks
All four configurations share the same per-task caps in Dev100 v10 (≤6 model calls, ≤4 run_python executions, 32,768 output tokens, 1,800 s wall time, 90 s per tool call) and the same private replay scorer (local-paper-v1). Full per-model results and provenance are on the Leaderboard page.
An execution loop runs a fixed harness configuration on a task; an optimization loop sits outside execution, inspects trajectories and failure modes across tasks, proposes targeted edits to the harness (prompts, tool descriptions, observation formatting, middleware hooks or code), and retains only non-regressive improvements under a fixed evaluator.
The Self-evolving page presents the two-layer execution-and-optimization diagram, compares recent offline and online self-evolution methods (ModularRSI, Self-Harness, Meta-Harness, AHE, RHO, Harness-R1, RRSI and WHALE), and documents InferenceNet’s Phase 1 ModularRSI evolution study alongside our Phase 2 roadmap for Harbor and Claude Code.
Official engineering accounts, benchmark frameworks, high-star open-source Agent Harness repositories and self-evolution papers referenced on this page, verified via GitHub API and arXiv in October 2026.