Better Harness（QoderAI）

Better Harness can inspect local evidence from multiple coding-agent hosts: sessions, configured assets, tool activity, and the engineering context around them. But once developers work with several Agents across projects and machines, the central problem is no longer simply aggregating scattered data.

The harder question is how to connect that data into a delivery chain that runs from task intent through execution and verification. How can the same system help an individual complete a task, a team reuse a working method, and an organization operate agent-enabled delivery at scale?

Our working direction is this: an Agent should not only finish one coding task. It should become a delivery capability that can be verified, reproduced, governed, and operated.

The shift: from a successful run to an operating capability

When adopting a new Agent, the first question is usually simple: can it complete the task in front of us? A successful run, however, is not yet a stable capability. The same task can produce a very different result when it moves to another developer, Agent, repository, or machine. Context, tools, permissions, project rules, Skills, MCP servers, models, and acceptance methods all affect the outcome.

An Agent capability therefore needs to mature through three layers:

Layer	Primary question	Desired outcome
Individual success	What context, knowledge, and tools make this task reliable?	A bounded task with a verifiable result.
Team reuse	Which parts of that success can be repeated?	Skills, templates, MCP services, and quality rules that make a class of tasks stable.
Organizational operations	How can proven capabilities be provided safely and economically to more teams?	Governed distribution through capability catalogs, gateways, evaluation, and model routing.

This progression moves from "can one task be completed?" to "can a class of tasks be repeated?" and finally to "can mature capability be operated safely, predictably, and at an acceptable cost?"

Session counts, token totals, and tool-call volume alone cannot answer those questions. A Harness needs a feedback mechanism centered on task outcomes: it must relate the execution of Skills and MCP services to acceptance evidence and resource consumption. Only then can teams improve Harness assets, refine practices, identify capability gaps, and reduce the total cost of a qualified delivery.

Different scopes require different Harnesses

As Builders move from individual work to teams and organizations, the problem changes. An individual needs to make one Agent collaboration work; a team needs to repeat an effective method; an organization needs to operate mature capabilities with bounded risk and cost. The Harness should be layered accordingly.

Individual: make one Agent collaboration complete

For an individual, the immediate question is: how do we get an Agent to complete this task well? That requires:

• Defining the task before execution. State the problem, change boundary, non-goals, deliverables, acceptance method, and risks. If the completion condition is not clear, the task is not ready for implementation.
• Preparing task-specific context and tools. Supply the relevant project, architecture, and domain knowledge, while exposing only the directories, commands, tools, and network permissions the task genuinely needs.
• Collaborating around real artifacts. Review and iterate on code diffs, pages, or documents, and require validation evidence such as test results and screenshots.

The individual view is about reconstructing one delivery from task definition through execution to acceptance.

Team: turn personal experience into an engineering practice

A team needs to make more than one task work. Its question is: how can a useful individual method become a reliable engineering practice?

• Make the environment operable by Agents. Standardize installation, startup, testing, debugging, reproduction, and recovery, so an Agent can reach a verification loop quickly.
• Make rules automatically checkable. Give architectural, security, test, and visual requirements executable checks and acceptance paths instead of leaving them as prose alone.
• Continuously distill task experience. Connect requirements, sessions, file changes, tests, commits, and review evidence. Turn repeatedly validated paths into project rules, Skills, scripts, Hooks, task templates, or quality gates.

The team objective is not an isolated success. It is a shared environment, automatic checks, and Harness assets that make a category of work consistently reliable.

Organization: operate Agent capability at an acceptable cost

Across multiple teams, projects, and devices, the question becomes how to use real cross-task evidence to continuously govern and improve delivery capability:

• Build a cross-Agent delivery evidence chain. Link task intent, Agent sessions, context and tool use, code changes, verification results, human acceptance, and later defects, so a delivery can be reconstructed and reviewed.
• Govern reusable Harness capabilities. Version Skills, MCP services, Hooks, rules, and evaluation sets that have demonstrated value; record their applicable task types, quality requirements, and maintenance ownership.
• Use outcomes to guide investment and rollout. Compare acceptance rates, human intervention, retry and rework, resource consumption, and follow-up defects by task type to decide which capabilities to promote, optimize, narrow, or retire.

The organizational question is not whether an Agent appears intelligent, or even just what a single invocation costs. It is whether scattered execution activity can become delivery evidence that supports a controlled expansion of effective capability.

A task feedback loop connects four Harness layers

Individual collaboration, team reuse, and organizational operations all depend on knowing how a task was completed, what it produced, and which capabilities helped. A complete task crosses four connected Harness layers:

1. Intent and acceptance. Organizational and team goals become task boundaries, acceptance criteria, risks, and ownership.
2. Execution environment. Context, tools, permissions, and rules shape how an Agent plans, acts, verifies, and recovers.
3. Delivery evidence. Source changes, test results, generated artifacts, reviewer decisions, and release information show what actually happened and what was accepted.
4. Harness assets and feedback. Methods that repeatedly work are refined into versioned Skills, MCP services, Hooks, rules, and task templates; outcome evidence decides whether those assets should expand, change, or stop.

This is a feedback loop rather than a one-way dashboard. The downward path makes goals executable; the upward path turns validated work into evidence and reusable capability.

Better Harness: from execution records to task feedback

Better Harness is an early implementation of this direction. It starts by making local Agent activity and project context observable, rather than treating a chat transcript as the whole delivery. The local Harness UI can surface project evidence about configured assets and execution activity, including Skills, MCP services, models, token usage, and tool calls where sources expose it.

This visibility is necessary, but it is not enough. An asset being invoked is not evidence that it helped. The next step is to connect activity to task intent, acceptance conditions, real artifacts, and human review. That makes it possible to ask more useful questions:

• Did the task pass acceptance, and did its changes reach the intended release?
• Were Skills and MCP services used at the right stage, with failures made visible to their maintainers?
• Which resource costs did not translate into meaningful progress?
• Which observed patterns are sufficiently supported to become reusable Harness assets?

The Dashboard is therefore an observation entry point, not the end state. The goal is a task-feedback system that makes Harness improvement and the cost of qualified delivery measurable.

Make rollout decisions falsifiable

An organizational Harness needs more than a catalog of available capabilities. It needs evidence that a capability makes a relevant class of work better under stated conditions. For a given task type, compare alternatives using signals such as:

• acceptance and release success;
• completeness of verification and review;
• human intervention, retries, and rework;
• execution time and token or credit consumption;
• later defect or rollback signals; and
• the scope, version, and owner of each contributing Harness asset.

These measures do not turn engineering judgment into a single score. They make rollout decisions inspectable: a capability can be expanded, constrained, improved, or retired for a reason that is visible in delivery evidence.

Explore Better Harness

Better Harness is evolving quickly. To explore its local Harness UI against a project checkout:

git clone https://github.com/QoderAI/better-harness.git
cd better-harness
npm install
npm run harness-ui:dev

Open http://127.0.0.1:3410 to inspect the local dashboard. Useful directions to explore include:

• connecting sessions, task histories, code changes, and delivery outcomes into cross-Agent evidence chains;
• identifying reusable work patterns across tasks and distilling them into traceable Harness assets;
• validating changes to Skills, MCP services, and rules through versioned components, evaluation sets, and controlled experiments; and
• improving cost and routing evaluation, long-running-task benchmarks, and real verification across Agents and operating systems.

Open an Issue, contribute an Adapter, or join the design and validation of Better Harness.