Article body
Full article
A new generation of Agentic BI from HENGSHI Technology.
Recently, Harness Engineering has suddenly become a hot topic.
OpenAI published Harness engineering: leveraging Codex in an agent-first world. Anthropic published Effective harnesses for long-running agents. LangChain published The Anatomy of an Agent Harness. Martin Fowler and Thoughtworks also published Harness Engineering. GitHub even now has an awesome-harness-engineering list that collects dozens of related resources.
This is no accident. Agent Coding has evolved from writing individual functions to developing complete features over a full day. The industry is gradually recognizing that the main constraint on Agent adoption is not model performance, but the environment in which the model runs.
The bottleneck for Agents is not model capability. It is the model’s operating environment.
Harness Engineering has distilled a general implementation pattern. Some of its ideas overlap with the direction HENGSHI has been pursuing through JARVIS, but the two are still fundamentally different. This article explains where they align and where they differ.
1. What Is Harness Engineering?
The term harness originally came from Anthropic’s engineering practice around Claude Code. Its core idea is simple:
Agent = Model + Harness
The model provides reasoning capability. The harness provides everything that lets reasoning land in real work.
More specifically, Harness Engineering focuses on several areas.
Context Engineering
How should an Agent’s context window be managed? The answer is not to put in as much as possible. Context must be managed as a working-memory budget. Manus’s KV-cache locality, tool masking, and filesystem memory; Anthropic’s context condensation; and OpenHands’ bounded conversation memory all address the same problem: once an Agent runs for a long time, context can go out of control.
Constraints and Guardrails
How can an Agent remain autonomous without losing control? Sandboxes, permission policies, approval gates, and tool boundaries all matter. Anthropic discusses sandboxing and MCP execution control; HumanLayer discusses 12 Factor Agents; Thoughtworks discusses quality checks in the loop. They all answer the same question: where is the boundary of automation?
Specs and Agent Files
AGENTS.md, CLAUDE.md, and agent.md are repository-local instruction files that tell an Agent how to work inside a specific codebase. GitHub’s Spec Kit goes further by turning spec-driven development into a standard workflow.
Evals and Observability
How do we know whether an Agent is doing good work? The answer is not only to inspect the final result, but also to trace the whole process. OpenAI’s eval skills, Anthropic’s trace grading, and LangChain’s multi-turn eval all point to the same reality: the more autonomous Agents become, the more observability they require.
Runtime and Orchestration
This includes Agent lifecycle management: start, pause, resume, and coordinate multiple Agents. LangChain’s deepagents, Inngest’s AgentKit, and SWE-agent’s execution environment all sit in this layer.
In short, Harness Engineering focuses on how Agents can run reliably.
2. The Core Positioning of JARVIS
HENGSHI has already published several articles in the JARVIS series. Building a Software Company’s JARVIS focused on the overall implementation methodology, while From AI Writing Code to AI-Driven R&D argued that a Coding Agent is not the same thing as a complete R&D system.
This article will not repeat those arguments. The key conclusion is:
JARVIS is not mainly concerned with how an Agent runs, but with what is available in the knowledge base when the Agent runs.
More specifically, JARVIS is a product knowledge base organized across three temporal layers: History, Present, and Future.
- History: classification indexes for 57,000 issues, deep documentation for 18 modules, 635+ MR fix summaries, 7,311 rejected requirements, 60+ breaking changes, and a cross-module dependency matrix
- Present: current backlog snapshots, release plans, and team configuration
- Future: AI-based backlog deduplication, priority analysis, and scheduling recommendations
The core problem it solves is this: when an AI Agent faces a bug, it does not only inspect the current code. It can trace the original design rationale for that module from three years earlier, summarize past fixes for similar bugs, and understand which solutions have already been rejected.
In short, JARVIS focuses on how much organizational knowledge has been accumulated for the Agent to use.
3. The Essential Difference: Runtime Layer vs. Long-Term Memory Layer
The distinction is now clear.
To use an analogy, Harness Engineering gives the Agent a standardized operating room: lighting, instruments, monitoring equipment, and safety rules are all in place.
JARVIS gives the Agent on the operating table ten years of clinical experience. It knows the patient’s history, understands why previous operations failed, and remembers contraindications.
A complete operating room is indispensable, but a doctor without clinical experience can still make serious mistakes in an excellent environment.
By contrast, an experienced doctor can still treat patients in a rough environment, and with a complete operating room, that doctor performs even better.
That is the relationship between JARVIS and Harness Engineering: they have different responsibilities and reinforce each other.
4. Current Gaps in the Harness Engineering System
Looking across awesome-harness-engineering resources, memory is usually defined around Context, Memory and Working State, Constraints, Specs, Evals and Observability, Benchmarks, and Runtimes.
Context, Memory and Working State may look similar to JARVIS at first glance, but the implementation details reveal the difference. Anthropic focuses on optimizing context windows and saving token cost. Manus uses KV-cache locality to improve cache efficiency. OpenHands keeps key information through conversation compression. HumanLayer focuses on avoiding context drift. These approaches address runtime memory. They manage short-term memory within a single task lifecycle.
The long-term organizational memory accumulated by a product is not part of the Harness system: original module design logic, historical fixes for similar failures, abandoned technical routes, weak spots in feature testing, and cross-module risks introduced by code changes. This knowledge is not in the context window, not in AGENTS.md, and not in any harness component by default.
Harness Engineering’s memory is working memory, comparable to computer RAM. JARVIS memory carries lifecycle-level accumulated information, more like disk storage. Both are necessary, but their technical roles are different.
5. JARVIS Still Needs Harness to Land
Conversely, JARVIS cannot run by itself just because a knowledge base exists. In practice, Agents must be able to use the JARVIS knowledge base effectively. That implementation work falls squarely within Harness Engineering.
Context budget allocation
JARVIS contains 18 modules, and each module may have overview, known-issues, decisions, test-coverage, and FAQ documents. If an Agent receives a bug in the charts module, it cannot put all 18 modules of documentation into the context window. It needs intelligent routing. That is a Context Engineering problem.
Tool boundary design
Agents should be able to search JARVIS and update JARVIS, but they should not delete or overwrite critical knowledge without human approval. That is a Guardrails problem.
Evaluating knowledge updates
If an Agent extracts a known-issue entry from a bug fix, how good is that entry? Does it hallucinate? That is an Evals problem.
Multi-Agent coordination
One Agent fixes the bug, another updates the knowledge base, and another runs regression tests. How should they coordinate? That is an Orchestration problem.
Together, the relationship becomes clear:
JARVIS provides the knowledge Agents need, while Harness Engineering provides the reliable way for Agents to use that knowledge.
6. How They Work Together in Practice
In HENGSHI’s own work, JARVIS and Harness operate together like this:
A typical case looks like this:
- Issue enters the system: Harness receives the task and assigns it to an Agent.
- Knowledge routing: JARVIS matches the issue to the relevant module and pushes the related overview, known issues, and decisions.
- Context assembly: Harness Context Engineering decides how much knowledge to place into context.
- Solution generation: the Agent proposes a fix based on the knowledge base.
- Constraint check: Harness Guardrails check whether the proposal touches known risks, including JARVIS cross-module interactions.
- Code implementation: the Agent writes code.
- Test validation: Harness runs tests and compares against JARVIS test-coverage information.
- Knowledge write-back: after the fix, the Agent updates JARVIS known issues and fix knowledge.
- Evaluation record: Harness Evals records quality metrics for the whole process.
Every stage depends on the collaboration between JARVIS and Harness. If either layer is missing, the closed loop breaks.
7. Industry Outlook
Looking at the direction of the Harness Engineering ecosystem, we can expect this system to become standardized in 2026 and 2027. Context Engineering, Evals, and Guardrails will become basic infrastructure, much as CI/CD became standardized around 2015.
But organizational memory will not be standardized.
Every company has different product forms, iteration histories, design logic, and past problems. General harness frameworks can be reused across enterprises, but a memory system like JARVIS cannot be generic.
Harness capabilities can be purchased or adopted through open-source projects such as SWE-agent and AgentKit. A company-specific memory layer must be built by the company itself.
JARVIS is not a standardized commercial product in the usual sense. It is an organization’s own capability. Its value does not mainly come from development technology, but from the company’s accumulated understanding of its own business. The depth of structured organizational memory directly determines the upper limit of AI Agent capability.
8. Implementation Suggestions
For teams that are trying to involve AI deeply in R&D, HENGSHI offers the following recommendations.
Build the Harness first, then build JARVIS.
Harness has a more immediate return on investment: write a good AGENTS.md, configure the sandbox, connect testing, and set approval gates. These are practical steps that quickly improve the reliability of coding Agents.
After Harness is in place, begin building organizational memory.
Start with the issue system: export historical issues, classify them by module, and extract frequent bug patterns and rejected requirements. You will quickly find that simply letting AI know which approaches were previously rejected can save a great deal of repeated debate.
At the same time, pay close attention to how the two layers connect.
The connection between memory and runtime is where problems most often appear: Is knowledge routing accurate? Is the context budget reasonable? Is knowledge write-back quality controlled? These connection points determine the system’s real impact.
Conclusion
Harness Engineering did not become popular by chance. It marks the industry’s shift from a model arms race to an engineering infrastructure race.
Engineering infrastructure solves the problem of reliable Agent execution, but it cannot define the execution target or the basis for decisions. That is exactly where JARVIS fills the gap.
JARVIS is not a replacement for Harness. It is an upper-layer support system: Harness keeps Agents executing reliably, while JARVIS keeps their decisions aligned with accumulated organizational knowledge.
A mature AI R&D system needs both layers.