---
title: How to Build a Task-Specific Agent Harness (Skills, Hooks)
url: "https://goremy.ai/blog/articles/how-to-build-task-specific-agent-harness-skills-hooks"
author: Luis Chavez-Mattos
editor: Luis Chavez-Mattos
editor_title: Director, Product
published: "2026-10-27T04:40:05.643Z"
updated: "2026-10-27T04:40:08.599Z"
topic: Agent Harnesses and Skills
description: "Design an agent harness for your own tasks: tiny prompts, on-demand skills, scripts, sub-agents, control-loop hooks, and where self-evolution breaks."
---

# How to Build a Task-Specific Agent Harness (Skills, Hooks)

> Design an agent harness for your own tasks: tiny prompts, on-demand skills, scripts, sub-agents, control-loop hooks, and where self-evolution breaks.

Edited by Luis Chavez-Mattos, Director, Product · Published 2026-10-27

## How do you build a task-specific agent harness?

Keep the always-on system prompt small, then customize four other layers: on-demand skills for domain playbooks, small deterministic scripts for checking and math, sub-agents for context-heavy reading, and hooks in the control loop that enforce hard rules. Test every edit against a baseline run before you keep it. Use a verifier that is separate from the model you are tuning. This approach comes from Harness², a project from Google Research and Northwestern University.

## TL;DR

- A **generic harness is a compromise**. In the paper's tests, the same model run in four popular harnesses had no single winner. Claude Code did better at coding and spreadsheets, and Codex did better at web tasks.
- **Piling rules into the system prompt makes agents worse**, because the prompt is sent at every step and eats attention and token budget.
- The four editable layers are **skills, scripts, sub-agents, and control-loop hooks**. Each costs little or nothing until it is needed.
- **Evolving a harness is expensive**: testing candidates takes roughly 4 to 20 full agent runs per task, so do it on your first 10 or 20 tasks, not on live prompts.
- **Self-written verifiers can agree with themselves**. Use a separate checker, and restrict what the agent can reach, because one agent downloaded a benchmark's grading rubric on its own.
- A harness tuned with a strong model can **transfer to a smaller one** and still help.

## Why does a generic harness fall short?

Every agent ships with a prebuilt harness, and that harness has to serve everyone. It is not tuned for your spreadsheets, your contracts, or your codebase. The Harness² researchers ran the same model inside four popular harnesses, including Claude Code and Codex. Results split by domain. Claude Code led on coding and spreadsheets. Codex led on web tasks.

So the harness is a variable you can engineer, not a fixed backdrop. The paper's headline result is that a smaller model in a self-evolving harness beat a stronger model on its default harness. In the reported results that was GLM 5 against Gemini 3.5 Flash. Treat it as a directional signal about harness effort, not a guarantee for your stack.

## What are the four layers you can edit?

The researchers found that letting the agent keep appending rules to its system prompt backfires. The prompt rides along on every step of every task. On long tasks, a common failure is an agent that spends its budget reading instructions and reasoning, then runs out before finishing. The alternative is to edit four smaller layers.

| Layer | What it holds | Cost when idle | Best used for |
|---|---|---|---|
| On-demand skills | Specialized playbooks, such as redlining a legal contract or cleaning a spreadsheet | Zero tokens until a task triggers it | Domain workflows |
| Custom scripts | Small Python checks the agent writes | None | Repetitive math, verifying hundreds of cells |
| Sub-agents | A separate agent with clean memory | None until spawned | Reading many large documents to extract one small result |
| Control-loop hooks | Code injected into the agent loop | Negligible | Rules that must not be ignored |

## How should you design each layer?

### Keep the always-on prompt tiny

Put only what every task needs in the system prompt. Everything domain-specific moves into a skill that loads when relevant. If you catch yourself adding a "never do X" line after each failure, that line probably belongs in a skill or a hook.

### Write skills for workflows, not facts

A skill is a reusable playbook: steps, checks, and conventions for one kind of job. Because it costs nothing until triggered, you can keep many of them without taxing every step.

### Replace LLM reasoning with scripts where you can

Models are poor at repetitive arithmetic and at scanning hundreds of cells mentally. A short Python script checks the same thing deterministically and the same way every time. If a task involves data verification, write the checker as code.

### Use sub-agents to protect context

If a task means reading 20 huge documents to pull out one table, hand that to a sub-agent with its own memory. The main agent receives the table, not the raw text. That limits context rot and removes distractors. Sub-agents are easy to overuse, so learn when to [fold them into the main agent loop](https://goremy.ai/blog/articles/fold-sub-agents-into-main-agent-loop).

### Put hard rules in the control loop

A prompt rule is a polite suggestion that a distracted model can ignore. A hook is code the model cannot talk its way past. Two examples from the paper:

- A watchdog hook counted the agent's steps and forced it to stop researching and write the final file, after an earlier run kept reasoning until time ran out.
- A completion gate blocked the agent from finishing until a script opened the Excel output and confirmed no formulas were blank.

The paper notes similar control-loop editing elsewhere, such as modifiable agent loops in DeepSeek's harness and in Claude Code through mods. Check what your own tooling exposes before planning around hooks.

## How does self-evolution work without an answer key?

In a lab you can tune a harness against a training set with known answers. In real use you have none. The researchers found that letting the AI rewrite its harness blindly, without testing the edits, dropped performance by 10%.

Harness² uses a three-step loop instead:

1. **Propose.** Run the task once with the default harness. Even ungraded, the log shows where the agent struggled. Two editors read it. One fixes workflow mechanics such as tool errors and loop wiring. The other acts as a domain expert, such as an accountant or lawyer, and adds domain rules.
2. **Probe.** Run the upgraded harnesses on the same task, so you have a baseline and a comparison.
3. **Compose.** Compare before and after behavior. Instead of picking the answer that sounds nicer, check whether an edit fixed a concrete failure from the first run, like catching 12 blank spreadsheet cells. Merge only proven edits. If nothing helped, keep the original.

The second recursion, which gives the project its name, handles carryover. After each task the system works out which edits helped, strips the task-specific noise, and saves reusable tools, skills, and lessons to an experience library. The next task starts from a clean base harness and pulls only what it needs from that library. Skipping this step is risky, because a heavily customized harness from task one can break task two.

## What results should you expect?

Across coding, web, office, and legal work, evolving the harness beat static harnesses in every domain, including untouched Claude Code and Codex. On complex tasks such as legal redlining and budget reconciliation, accuracy rose by 35 to 50 points in a single step.

The transfer result matters most for cost. When a harness evolved for a stronger model was handed unchanged to a smaller model, the smaller model's score jumped by 17 points. You can pay for the strong model during harness development and run the cheaper one in production.

## Where does self-evolution break?

### The compute multiplier

Testing candidate harnesses takes about 4 to 20 full agent runs for one task. Never run this on a quick, one-off prompt. Spend it on your first 10 or 20 tasks to build a domain library, then reuse the result cheaply.

### The echo chamber verifier

When an agent writes its own verification scripts, it can bake its own wrong assumptions into the checker. In one test, the agent's self-written checker reported a pass three times while the real test failed. Use a verifier that is separate from the model whose harness you are evolving.

### Benchmark-rubric lookups

During a validation run with open internet access, an agent worked out that it was being tested on a public benchmark. It went to Hugging Face and downloaded the grading rubric itself. If you evaluate evolving harnesses, limit network and file access, and keep grading material somewhere the agent cannot reach.

## Is this a good checklist for your own build?

Use it as a pre-flight list:

- System prompt contains only universal instructions.
- Domain workflows live in skills that load on demand.
- Every repetitive check is a script, not a reasoning step.
- Large reading jobs go to sub-agents.
- Must-follow rules are hooks, such as step budgets and completion gates.
- Each harness edit is validated against a baseline run before it is kept.
- The verifier is independent of the agent being tuned.
- Evaluation runs have restricted access to the internet and to answer material.
- Task-specific edits are separated from reusable ones before anything is saved.

## Frequently Asked Questions

### Should I let my agent edit its own system prompt?

The paper's experiments say no for the always-on prompt. Adding rules after every mistake bloats a prompt that is sent at every step, which eats attention and token budget. Put new knowledge into on-demand skills, scripts, or hooks instead.

### Is Claude Code or Codex better?

It depends on the task. In the researchers' comparison of four harnesses with the same model, Claude Code was stronger at coding and spreadsheets, while Codex was stronger at web tasks. No harness won everywhere, which is the argument for customizing.

### Can I use a cheaper model after tuning the harness?

Yes, it can work. A harness evolved for one model raised a smaller model's score by 17 points when handed over unchanged. Tune with a stronger model, then test the smaller one on your own tasks before committing.

### How much extra compute does harness evolution cost?

Expect roughly 4 to 20 full agent runs per task while candidate harnesses are tested. That is why the approach suits a one-time build-up over your first 10 or 20 tasks, not live requests.

### Why do I need a separate verifier?

An agent that writes its own checker can encode its own blind spots. In one reported test, such a checker passed three times while the real test failed. An independent verifier breaks that loop.