Prompt, context, loop and graph engineering each turned out to be one piece of the same machine. The harness is where they finally live together.
Every stretch of building with AI got its own job title. Prompt engineering came first, back when the whole craft was finding the right sentence.
Context engineering followed, once it became obvious the sentence mattered less than everything loaded around it. This summer it was loops, and a few weeks later, graphs.
The name spreading now is harness engineering, and it's the first one that explains all the others.
A harness is everything around the model: the tools it can call, the files it reads before anything else, the directories it may write to, the check its output has to pass, the schedule that wakes it up and the rule that ends the run.
Each discipline before this one turns out to be a single component of that frame, built separately and given its own name.
I started paying attention for a practical reason. The model underneath keeps changing, sometimes by seventeen leaderboard places in a single update, and the harness is the only part of the system that stays yours.
1/ Seven Engineerings, One Machine
Discipline
The question it answers
Where it lives in the harness
Prompt engineering
What exactly am I asking
SKILL.md, the task spec loaded first
Context engineering
What does the model see at each step
The context assembler: constraints, schemas, retrieved pages
Tool engineering
What can it touch, and in what shape
Tool definitions with typed inputs and outputs
Loop engineering
What starts a run and what ends it
The runner: triggers, stop conditions, budgets
Graph engineering
What it remembers and how things connect
The memory layer: nodes, typed edges, aliases
Eval engineering
How a result gets rejected
The verifier, outside the agent's control
Harness engineering
What holds all of the above together
The frame, the permissions and the hooks
Read the table top to bottom and it's a history. Read it bottom to top and it's an architecture: harness engineering is the job of deciding where each of the other six lives, so that none of them ends up hiding in a prompt.
That last point carries most of the weight.
A prompt is the easiest place to put anything, so everything drifts into it: the output format, the stopping rule, last week's corrections, the list of things the agent must never touch. It works beautifully on the model you wrote it for, and then the next model reads the same paragraph differently.
2/ Anatomy of a Harness
The most useful habit I've picked up is writing the whole harness down as one config file, so nothing important stays implicit:
1# harness.yaml2model: kimi-k3 # one line. everything below survives a swap3tools: [browser, fs, shell, search]4permissions:5 write: [./10-returns, ./20-graph, ./40-runs]6 ask_first: [send, publish, pay, delete]7context:8 always: [SKILL.md, CONSTRAINTS.md, SCHEMA.md]9 per_agent: return_schema10runner:11 trigger: cron "0 2 * * *" # nightly, while you sleep12 stop: 40 verified nodes OR 3 passes with nothing new13 budget: { agents: 300, minutes: 45, retries: 2 }14memory:15 graph: ./20-graph16 aliases: ./aliases.csv17verify:18 - script: checks/schema.py19 - agent: reviewer, fresh context20hooks:21 pre_tool: hooks/pre_tool.sh22 post_run: append 40-runs/
Three lines in that file do most of the work.
model: is one line on purpose. Everything else is written so it doesn't care what that line says. That is the whole portability story.
permissions: matters more than tools:, even though it sits lower in the file. Writing down what the agent may change and what it has to ask about first is what separates a system you leave running overnight from one you sit and watch.
verify: has two entries for a reason. The script costs nothing and catches anything mechanical. The reviewer is a second agent that never saw the first one work, because an agent grading its own output finds every reason to approve it.
On disk, the harness is one folder, and every engineering from the table gets its own address in it.
3/ Why Kimi K3 Is the Engine I'd Put in It
What the harness needs
What Kimi K3 brings
A runner that can fan out
Agent Swarm: up to 300 agents on one problem at the same time, without writing an orchestrator
Code strong enough to write its own checks
#1 on the Frontend Code Arena at 1,679, ahead of Fable 5 (1,631) and GPT-5.6 Sol (1,618), leading 6 of 7 domains
An engine that improves underneath you
#18 to #1 in a single July update
The first row matters more than it looks. Almost every homemade harness grows a hand-built orchestrator at some point, and it's usually the most fragile file in the folder. With the swarm, fan-out becomes a budget line, agents: 300, and the harness only has to handle what comes back.
The second row matters because a harness is mostly code the model writes for you: hook scripts, schema checks, the small dashboard that reads 40-runs. An engine that leads the frontend arena gets those right on the first pass far more often.
The third row is the case for harness engineering in one data point. When a model climbs seventeen places overnight, a harness puts that climb to work the same day, because the only line that has to change is model.
4/ Hooks: The Reflexes
A hook is a short script the harness runs at a fixed moment, whatever the model decides to do. Hooks are where a harness stops being a folder layout and starts behaving like a safety system.
Hook
When it fires
What it does
pre_tool
Before any tool call
Blocks writes outside the permission list
post_tool
After every return
Runs the schema check and rejects malformed output on the spot
pre_send
Before anything leaves the machine
Holds it in a queue until you clear it
on_fail
After a rejected result
Attaches the failure reason to the retry
post_run
When the stop condition hits
Appends the run record to 40-runs and diffs the graph
The pre_tool hook from the first row fits in five lines:
1# hooks/pre_tool.sh2case "$TARGET" in3 ./10-returns/*|./20-graph/*|./40-runs/*) exit 0 ;;4 *) echo "blocked: $TARGET is outside the write list"; exit 1 ;;5esac
The on_fail hook alone changes the economics of a loop. A retry that carries the reason the last attempt failed is a correction. Without that reason, the loop pays for the same mistake a second time.
5/ What a Night Looks Like
Put every piece together and the harness behaves like a night shift that follows rules. At 02:00 the trigger fires and the launch query picks every node that needs work. The swarm fans out, one agent per node.
Returns that miss the schema get rejected by post_tool before they reach the graph, and each rejected node retries once with its failure reason attached. When one agent tries to write outside its folder, pre_tool stops it without waking anyone.
Merged nodes and typed edges land in 20-graph. A drafted email reaches pre_send and waits. post_run appends the record, and the loop stops on its own condition, well inside the 45-minute budget from the config.
At 07:30 you read one file and make two decisions. That is the entire morning cost of running loop engineering and graph engineering this way, and it's the whole point of the harness: everything that could run without you did, and the few things that needed you are waiting in one place.
6/ The Swap Test
The fastest audit of any agent setup: change the model line and run it again. Whatever breaks was harness living in the wrong place.
What breaks after the swap
Where it was hiding
Where it belongs
The output format drifts
"always answer as JSON" in the prompt
A return schema plus a script that rejects anything else
Runs stop ending on their own
"keep going until it's thorough"
A stop condition made of counts
Last week's corrections are gone
The chat history
CONSTRAINTS.md, loaded every run
The same company shows up three times
The model's judgment
aliases.csv, checked before merge
It writes somewhere it shouldn't
A polite sentence in the prompt
A permission list and a pre_tool hook
A setup that passes the swap test is portable, and portable is what makes it worth money.
What It Costs and What It Pays
Companies put whole quarters into internal agent platforms. A working harness is one folder, one config file and five short scripts, and it runs on a Kimi subscription. That gap is the opportunity.
Channel
What it pays
What you need first
Harness setup for a small team
A one-time fee in four figures for the config, hooks and verifier around their workflow
One harness of your own, running on a schedule
Release-day retainer
A monthly fee to run the swap test on every major model release and move the team to whatever leads
A client whose runs already log to 40-runs
A niche harness template
The folder and the yaml packaged for one industry: research, recruiting, compliance
The same harness proven in two different markets
The second channel is the one I'd build first. Every major release reshuffles the leaderboard, K3 alone moved seventeen places in one update, and every team with a harness needs someone whose job is to run the swap test on release day.
The Short Version
Prompt, context, tool, loop, graph and eval engineering all turn out to be components of one machine, and harness engineering is deciding where each of them lives.
Put the model behind one line, permissions ahead of tools and the verifier outside the agent. Then the next leaderboard jump is a config change instead of a rebuild.
And if you found this useful:
- Bookmark this article. The links change and new repos pop up weekly, you'll need this as a reference
- For weekly deep dives into AI architecture, quant trading, and the agent economy, follow me: @polydao
- Join the TG Channel: Buzzoni Notes - here I share my raw prompts, custom skills, and alpha that's too early for X
