Welcome to Grind Engineer, your guide to becoming a better software engineer! No fluff. Pure engineering insights.
In partnership with
No apps to learn, no forms to fill. Just talk to Catch like any assistant, type it or call and say it out loud. Say it once, consider it done. Meet your admin savior at catchagent.ai.
AI help, without the trust tax.
Most AI tools ask you to trade your data for intelligence. Norton Neo doesn't. It's the first safe AI-native browser built by Norton, and it gives you powerful built-in AI without handing your privacy over to get it. Search, summarize, and write with AI built directly into your browser. Your data stays yours. Your context stays private.
Built-in VPN, anti-fingerprinting, and ad blocking come standard. No add-ons. No setup. No compromises.
Fast. Safe. Intelligent. That's Neo.
TL;DR: Harness engineering is the discipline of building everything AROUND an AI agent so it ships reliably. Think of it as the third evolution: Prompt Engineering → Context Engineering → Harness Engineering. This article breaks down the 5 layers every agent needs, using Claude Code as the concrete example.
Added Job Opening in the end of the article!
88% of enterprise AI agent projects never make it to production. Not because the models are bad. The models are the best they've ever been. The problem? Engineers spent years building better brains and forgot to build the nervous system around them.
That nervous system has a name now: harness engineering.
The Evolution Nobody Saw Coming
2023 was the year of prompt engineering. Write better prompts, get better outputs. Simple.
2024 brought context engineering. Give the model the right documents, the right code, the right history. Better inputs, better outputs.
2026 is the year of harness engineering. And it changes the game completely.
Here's the formula that Martin Fowler put on paper:
Agent = Model + Harness
The harness is everything except the model itself. The memory that persists between sessions. The tools the agent can call. The permissions that stop it from doing something dangerous. The hooks that run checks before and after every action. The logs that let you trace what went wrong at 3 AM.
Without a harness, you have a chatbot. With one, you have an autonomous agent that can actually ship code to production.
Why 88% of Agent Projects Fail
That stat comes from real market data. And the reason is always the same pattern.
Teams pick a powerful model. They wire it up to a few tools. They demo it to leadership. Everyone's impressed. Then they try to run it in production and everything falls apart.
The agent deletes files it shouldn't. It forgets instructions from yesterday. It calls APIs without rate limiting. It hallucinates a fix and pushes it straight to main. Nobody can figure out what went wrong because there are zero logs.
Problem | Root Cause | Harness Layer That Fixes It |
|---|---|---|
Agent forgets rules between sessions | No persistent memory | Memory (CLAUDE.md) |
Agent can't read files or call APIs | No tool integration | Tools (MCP) |
Agent runs dangerous commands | No safety boundaries | Permissions (settings.json) |
Agent pushes broken code | No automated verification | Hooks (PostToolUse) |
Debugging failures takes hours | No audit trail | Observability (session logs) |
The model isn't the bottleneck. The harness is.
The 5 Layers (With Real Examples From Claude Code)
Claude Code is the clearest example of harness engineering in the wild right now. Every layer maps to something you can configure today.
Layer 1: Memory
Memory is how an agent knows who you are, what your project does, and what rules to follow. Without it, every conversation starts from scratch.
In Claude Code, memory lives in CLAUDE.md files. You can have one at the repo root, one per project, and one globally in your home directory. These files survive context compression, meaning the agent reads them even when earlier messages get summarized away.
💡 Key Insight: The harness, not the model, determines whether an AI agent reaches production. Every component in a harness encodes an assumption about what the model can't do yet.
Layer 2: Tools (MCP)
A raw LLM can only generate text. That's it. MCP (Model Context Protocol) is the open standard Anthropic released to connect models to external tools without recompiling anything.
An MCP server defines tools in JSON with descriptions and input schemas. The harness presents these tools to the model as if they were native. Claude Code ships with built in tools for file editing, bash execution, and web search. But you can add any MCP server: a database connector, a Jira integration, a Slack bot.
Layer 3: Permissions
This is the safety net. Without permissions, an agent with bash access can rm -rf / your production server. That's not a hypothetical. It has happened.
Claude Code uses settings.json with allow/deny rules and 6 permission modes ranging from "ask for everything" to "full auto." You can allow npm test but block npm publish. You can let the agent read any file but require approval before writing to *.env.
Permission Mode | What It Does | Risk Level |
|---|---|---|
Plan | Read only, no edits | Lowest |
Default | Asks before writes/commands | Low |
Accept Edits | Auto approves file edits | Medium |
Auto | Runs everything without asking | High |
Start restrictive. Loosen as you build trust.
Layer 4: Hooks
Hooks are programmatic callbacks that fire at specific lifecycle events. They're the secret weapon most engineers skip.
In Claude Code, hooks trigger on events like PreToolUse, PostToolUse, UserPromptSubmit, and Stop. The proposed action gets passed as JSON on stdin. Your hook script can approve, modify, or block it.
Real use case: a PostToolUse hook that runs eslint after every file edit. If the linter fails, the agent sees the error and fixes it automatically. No human needed. Another: a PreToolUse hook that blocks any git push --force to main.
Layer 5: Observability
When your agent does something wrong at 2 AM, you need to know exactly what happened. Session logs capture every tool call, every model response, every decision.
Claude Code stores full session transcripts. You can replay an entire agent session to understand why it chose to refactor that one file or why it skipped running tests. This is your post mortem toolkit.
The Before and After
The difference between a raw LLM and a properly harnessed agent isn't subtle. It's the difference between a prototype that impresses in demos and a system that runs in production without waking up the oncall engineer.
I've seen teams go from "we can't trust the agent to do anything unsupervised" to "the agent ships 30% of our PRs autonomously" just by adding proper hooks and permissions. The model didn't change. The harness did.
What Comes After Harness Engineering
Martin Fowler makes a point worth repeating: every harness component encodes an assumption about what the model can't do. As models get better, some layers become unnecessary overhead.
Anthropic's own team found this when upgrading from Sonnet to Opus. Sprint based decomposition that was critical with Sonnet became dead weight with Opus, which could handle 2+ hour coherent sessions without it. They call this "progressive harness reduction."
So the discipline isn't just about building harnesses. It's about knowing when to remove them.
Try This Today
Start with CLAUDE.md. Write down your project's conventions, banned patterns, and testing requirements in a
CLAUDE.mdfile at your repo root. This alone eliminates 50% of "the agent did something dumb" complaints.Add one PostToolUse hook. Pick your most important quality gate (linter, type checker, test suite) and wire it up as a hook. The agent will self correct on every edit.
Set permissions before going to auto mode. Never run an agent in auto mode without explicit allow/deny rules. That's like giving a junior engineer root access on day one.
Job Openings: https://grindengineer.com/p/top-tech-jobs-3
See you in the next one!
Scortier, Signing Off!