The same model, the weight of a parameter does not change, only a different set of Harness, and the performance may fluctuate significantly. This seems to be the "basics" of Agent engineering, which actually exposes the two questions that evolutionary products must answer: how to prove that improvement is really effective, and how to get enough continuous, true, and traceable data to make improvement possible in the long run.
EverMind is trying to use HarnessBank, Raven, and EverMe to put these two issues in the same product pathway.
If the model doesn't change, why would a different Harness be "changed"?
In the actual application of AI Agent, the model is only part of the capability. Wrapped around the model's prompts, knowledge inputs, tool calls, running time logic and configuration, together they form the Harness, or Agent's "running shell". The same model is placed in different Harnesses, and can enter different organizations like the same person: knowledge and intelligence do not change, decision-making processes, tool conditions and feedback mechanisms change, and the end result will be very different.
EverMind gave an intuitive result in the HarnessBank study: in the AppWorld test set, the same freeze-weighted Qwen3.6-27B model evolved through Harness alone, the Pass@1 test set increased from 41.3% to 56.7%. In seven benchmarks covering terminal operations, code generation, mathematical reasoning, web research, knowledge work, application control, and code repair, the Pass@1 test set achieved a positive improvement of 5.1 to 15.4 percentage points.
But the real difficulty is not to raise a certain score, but to prove that the increase comes from repeatable mechanism improvements, rather than random fluctuations, over-matching tasks, or even "fake successes" caused by overtime sandbox crashes and verifiers. Even if it is impossible to judge whether the improvement is real, so-called automation could turn into automated manufacturing regression.
HarnessBank: Turn self-improvement into verifiable engineering
01. Core architecture: an Agent running a mission, an Agent changing Harness
HarnessBank's core idea is to divide the system into two roles, forming a "non-asymmetric" evolutionary structure:
Task Agent: Responsible for performing specific tasks under the existing Harness. Its core model is frozen, using Qwen 3.6-27B by default, to maintain stability.
Evolver Agent: It is an independent, more capable model (e.g. Claude Opus 4.8) whose task is to read the execution trajectory of "Mission Agent", diagnose repeated failures, and generate a new candidate Harness.
The beauty of this design is that improvements are made to think from a "strong model" whereas improvements are made only from a shell of a "weak model".
Figure 1: Conventional AI optimization requires a large amount of manpower and inefficiency, while HarnessBank's automation has achieved precise, efficient automation iterations through dual Agent architecture and gene pool classification archiving.
In form, evolution only allows modification of the variable aspects of the Harness (such as prompt, input knowledge, running time logic, configuration), while the code associated with evaluation, logging, and automation is locked into a static kernel. This strict control ensures that the results before and after evolution are always comparable.
Figure 2: HarnessBank framework processes: 1) selecting the current strongest progeny; 2) running training tasks to obtain diagnoses; 3) reorganizing or reinventing mechanisms based on gene libraries; 4) screening through four gate controls; 5) evaluating and competing for libraries.
The evolutionary process is by no means a blind trial and error, but follows a rigorous four-step cycle:
Select the parent: Select the current strongest Harness as the parent from the "genetic library" by mass bias;
Running diagnoses: running a set of training tasks to obtain complete diagnostic information (scores, trajectories, evaluation metadata);
Generating offspring: Evolution: Diagnostically generating offspring: either reinventing a mechanism from a failed trajectory or rearranging different mechanisms;
Gate control screening: Successors must pass through a strict "gate of screening" before they can be fully evaluated and finally entered into the library.
02. Crater avoidance guidelines: the three biggest "overcar" traps in the existing evolutionary program
Why are many existing automation schemes often failing in practical applications? The EverMind team pointed to three typical "rollover" approaches in their paper, and HarnessBank specifically gave solutions.
Trap 1: The search collapses
Traditional greedy evolutionary strategies retain only the best present-looking modifications. As the algebra moves, the types of modifications become narrower, eventually crumbling into prompt-level conservative modifications. Those that are radical, structurally different, will be completely abandoned once they fail once and for all.
How EverMind responds: Harness Gene Bank
HarnessBank does not only store an optimal solution with high and low scores, but uses a similar idea to MAP-Elites, and archives it according to "semantic coordinates".
Where the horizontal coordinates are changed: prompt, knowledge, running time, configuration.
Longitudinal coordinates (why changed): for which types of failure pathologies.
Candidates from the same pathology compete on equal terms, with different pathology schemes that are the same, both maintaining diversity and ensuring the quality of each class. The premise behind this is that every step of the way has passed the threshold: it is only by confirming the mechanisms that are truly effective that they deserve to be preserved, and only by adding them together that we can explore better Harness, rather than accumulating noise.
Trap 2: Missions are over-adapted
Without a gate control mechanism, evolution can easily leave a "background patch" behind. It is effective in training tasks simply by remembering these specific tasks, rather than correcting the actual failure mechanism.
EverMind's response: strict removal and withdrawal
HarnessBank makes a clear distinction between "diversity" and "avoiding over-adaptation". It addresses issues of diversity and regroupment on a pathological basis; the real obstacle to over-adaptation is that testing groups do not participate in the entire evolutionary decision-making process and only make one final acceptance.
Trap 3: Income not verified
This is the most concealed and the deadliest trap. The increase in single-run scores may be the mechanism actually working, but it may also be the execution of noise, or even the failure of infrastructure such as sandbox crashes, verifier overtime is miscalculated as a success.
EverMind's response: Four strict "door controls"
03. Core mechanism: Four gates to stop "false elevation"
Gated Harness Screening is the core design of HarnessBank's entire text. Each generation generated has to go through four rigorous shutdowns on the sampling task subset:
Dissolving experiments demonstrated the proportions of the four doors: if the significant test doors were removed, 62% to 76% of the turnarounds after the closure were "phantom progresses"; and with a fully controlled version of the door, it can be cleaned out at the bottom of 10 rounds, ensuring that each deployment is a real improvement.
04. Core insights: Harness without omnipotence
In seven benchmark tests (covering terminal operations, code generation, mathematical reasoning, etc.), the HarnessBank Test Set Pass@1 achieved a positive improvement of +5.1% to +15.4%) and the overwhelming majority passed statistical verification.
But more importantly, there is no all-powerful Harness.
Intermodal experiments reveal a profound "pathology-to-pattern matching rule": each model has its own dominant failure pattern.
Qwen 3.6-27B is prone to die from "empty rotation", and verify-finalize patches can lead to an improvement of +15.4%.
Qwen 3.6-397B and Gemini 3 Flash are easy to die of "carelessness" and require "list patches".
Moving a patch from 27B to 397B almost reduces the effect to zero; even applying a recovery mechanism to one model incorrectly to another could result in severe negative optimization (e.g., -15.7%)
A more extreme example is mathematical reasoning: Qwen 3.6-27B's problem is "to think too much", and Gemini's problem is "to think too little", with the same spinning budgetary reasoning, and the two models need to rotate in opposite directions.
The conclusion is clear: what really migrates is this whole set of "processes" from diagnostic failures, structured searches to statistical verification, not any specific Harness or Prompt.
05. Four real-world suggestions for Agent developers
HarnessBank's methodology is not free - it requires strong model computing and a large rollout budget - but it provides extremely valuable guidance for Agent Optimization.
Verify the four questions that apply to any agent optimization: is the evaluation environment clean? are the changes actually implemented? have significantly improved inspections? are they stronger than the baseline?
Classification archives: Don't just leave the current best set of configurations, but sort them according to "where to change, what to solve".
Don't look for the optimum: Harness is model-specific, and other people's configurations can be ineffective or even harmful.
It's not worth it, depending on whether you've deployed a return of "looking silent, it's noise".
EverMind has demonstrated through HarnessBank that the evolution of Agents should be based on engineering practices based on rigorous statistical verification rather than science.
From HarnessBank to Raven: When Evolution Begins to Run
HarnessBank responded with "how to safely change" and Raven brought this approach to the real Agent operating framework.
As an evolutionary Agent Harness built on top of EverOS, Raven combines long-term memory, skill systems, operating strategies, and tool calls to enable the Agent to summarize experience from mission trajectories while continuously optimizing its skills, workflows, and peripheral operating logic without having to modify the underlying large model weights frequently.
This step gives EverMind a clear breakdown: EverOS is responsible for decentralized interactions, knowledge and personal information organized long-term memory; Raven is responsible for transforming these memories into better execution strategies; HarnessBank provides verifiable methods for strategic evolution; studies such as SkillCorpus help successful experiences be scaled up, retrieved, and replicated. Memory is no longer just an archive, but a raw material for Agent finding problems, forming experiences, and rewriting behavior.
However, moving from paper and developer frameworks to mass-produced products lacks the most critical element: consistent, authentic, user-generated data.
Benchmarking tests can demonstrate that the mechanism is effective, but cannot replace the long-term trajectory of a person working, learning, communicating and using different applications. Without this part of the data, it is easy for automation to remain in the lab; with this part of the data, Agents can truly understand "who evolved for, why evolved, and whether it was more useful after evolution".
EverMe on-line intuition: C-terminal direct data flywheel begins to take shape
EverMind's first C-terminal product, EverMe, is now in-line. It does not simply move the developer interface of EverOS to the consumer terminal, but on the basis of the EverOS memory architecture, provides easier, intuitive personal memory management and calling capabilities that allow ordinary users to collect, view, track and use their own memory and pass that memory data to different Agent services.
In terms of product structure at this stage, EverMe is developing around the Memory Hub, Knowledge Base, Digital Separation, and Agent Hub in four modules:
Memory Hub: 11 Agents are currently available, including Claude Code, Codex, OpenClaw, Hermes, Kimi Code, Raven, and others, supporting historical data cold start input and retrieval in real-time, and managing personal trajectories across Agents through Timeline.
Knowledge Base: supports the connection of common application data, and supports the import of content such as Notion, Obsidian and local files to form a personal knowledge base; users can also conduct Deep Research based on their own data, so that the results of the research are not only dependent on the open Internet, but can also be combined with personal materials, both projects and long-term contexts.
Digital Identity: Provides mainstream identity, Onboarding, conversation flow and memory tracking Reference, allowing users to see which personal memories they respond to and gradually form an updated digital identity.
Agent Hub: supports Agent sharing, and lays the foundation for subsequent discovery, evaluation and collaboration mechanisms, so that personal memories and professional agents are no longer locked into a single product.
In addition, EverMind has become one of the first seven ecosystem partners to support MiniMax Code. This means that the personal memory capabilities of EverMe/EverOS are becoming more directly connected to the mainstream coding agent ecosystem: users have the context, preferences and experience of tasks across different tools, the opportunity to be unified and continue to play a role in the next task.
Why the C-terminal data flywheel is the basis for automated manufacturing
For automation, the quantity of data is not the only key. More important is whether the data belongs to the same entity, whether it spans a long enough time, whether it contains complete task processes and outcome feedback, and whether users have the ability to manage and authorize the data. The value of EverMe is that it builds a direct input to the individual on the memory architecture of EverOS, making the data organizations that originally were scattered in files, knowledge tools and in different Agents a continuous personal memory asset.
When this set of inputs is used continuously, a C-terminal direct data flyer begins to form:
This flyer differs substantially from the traditional Internet data flyer. It does not simply train a unified model with more user behaviour, but builds manageable long-term memories around each user and allows multiple Agents to consume these memories within the scope of authorization. This results in not only larger data pools, but higher-quality personalized experiences: which information is worth remembering, which Agent is more effective in what scenarios, which workflows often fail, and what results match user preferences.
This also explains why EverMe's strategic significance to EverMind is far greater than a C-terminal memory tool. It uses the underlying architecture of EverOS, Raven's running time evolution and HarnessBank's verification mechanisms to access real users' long-term use scenarios. Academic research provides a "how to evolve" approach, C-terminal products provide "what to evolve data with, and the ecosystem of multiple agents provides a "tasking environment where to verify evolution".
From "smarter models" to "the more you know your system".
Today, the big model industry is still accustomed to measuring intelligence using parametric scales, benchmarks, and context lengths. But for users, the real perceptible progress is often simpler: whether it remembers what I did, whether it understands why I did it, whether it can improve from previous mistakes, or whether it can bring the experience in one tool to another.
HarnessBank demonstrates that models with frozen weights can also achieve significant and verifiable enhancements through peripheral mechanisms; Raven brings this enhancement into the continuous running process of the Agent; and EverMe starts connecting personal data, memory management, and multi-agent ecosystems.
As a result, EverMind is building a comprehensive path from academic research, open source infrastructure to C-end products.
The end of this path is not that everyone has the same stronger AI, but that everyone has an intelligent system based on their own memory, that can collaborate across applications, and that continues to evolve in real use. With the advancement of EverMe and more Agent access, the automation that EverMind explores is also evolving from the statistical significance of the paper to the ability for users to perceive it every day.
For more information please visit:
EverMe：
Raven：
HarnessBank：