Monitoring a competitor who publishes no feed is the case every RSS guide skips. Twenty-one platforms sorted by which of three jobs they do, and the finished setup is business process automation you own outright, with no seat licence to renew.
Blaming the content is the reflex when a post underperforms, and it is usually the wrong diagnosis. A second reader decides distribution before any human sees the post, and most of what it checks is mechanical enough to automate business processes around, on five platforms at once.
Gloves on, tape measure in hand — nobody types a query. Three voice surfaces for ai automation tools (terminal, Telegram, Discord), 10 TTS and 6 STT providers compared on cost and latency, plus a setup that costs nothing.
Buy the model and you have bought the smallest part. Tool injection, permission enforcement, context compression and validation loops are where the measurable gains sit — and where workflow automation software vendors say the least.
In the source code of a leading AI coding tool, 98.4% of the codebase has nothing to do with AI reasoning. VILA-Lab's academic teardown of Claude Code revealed that only 1.6% of its roughly 1,900 files handle model inference. The rest? Tool injection, permission controls, context compression, state persistence, and safety checks. The system that makes an AI agent actually productive is not the model itself but the runtime infrastructure wrapped around it. That infrastructure has a name: a harness. The engineering discipline for building it is harness engineering, and this methodology has emerged as the defining skill gap in AI coding since early 2026.
Key Takeaways
It is the harness, not the model. You will hear that sentence more this year, usually from somebody explaining why their setup works and yours does not, and it is worth decoding rather than nodding along, because unlike most claims in this field it has actually been measured. Hold a model completely fixed, change only the runtime wrapped around it, and the same system starts solving problems it could not solve before. That wrapper handles tool invocation, permission enforcement, validation, and state. When you compare workflow automation software, that layer is most of what genuinely differs and almost none of what the marketing describes.
Harness engineering designs the runtime environment that wraps around an AI model. The model handles reasoning. The harness handles everything else: tool invocation, permission enforcement, validation loops, state persistence, and observability.
The community distills it into one equation: Agent = Model + Harness.
An AI model without a harness is a brain that can think but cannot act. The harness gives it hands, sets boundaries, and installs radar. From my experience running multi-agent systems daily, harness quality determines whether a task takes 20 minutes or 6 hours — and whether the output is usable at all.
The harness breaks down into four core subsystems, each covered in depth below:
Think of "harness" the way you think of riding tack: reins, saddle, bit. A rider does not weaken the horse. The equipment makes the horse's power controllable and directable. You would never ride an unbridled horse on a highway. You should never let an unharnessed agent write production code.
Harness engineering did not appear overnight. AI engineering paradigms evolved through three phases, and harness engineering is the latest.
Phase 1: Prompt engineering (2023–2024)
The core question was "how do I phrase my request?" You typed a prompt into ChatGPT and iterated on wording to get better output. Scope: a single prompt. Goal: optimize one question-and-answer exchange.
Phase 2: Context engineering (2025)
Shopify CEO Tobi Lutke's widely shared post reframed the problem: "I really like the term context engineering over prompt engineering. It describes the core skill better: the art of providing all the context for the task to be plausibly solvable by the LLM." The question shifted from "how do I ask?" to "what information does the model receive?" — not just the prompt, but the entire input assembly.
Phase 3: Harness engineering (2026)
On February 5, 2026, Mitchell Hashimoto (HashiCorp co-founder, Ghostty terminal developer) described his practice in a blog post titled "My AI Adoption Journey" and gave it a name: harness engineering. His definition is strikingly simple: "anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again."
Six days later, Ryan Lopopolo from OpenAI's engineering team published a formal article defining harness engineering systematically. The central question he explored: when the primary job of a software engineering team shifts from writing code to designing environments, clarifying intent, and building feedback loops for Codex agents, what changes?
That article marked the moment harness engineering graduated from personal practice to formal engineering discipline.
Two people arrived at the same concept almost simultaneously and independently. That is not coincidence — once AI agents enter production, "how do we manage the agent?" becomes an unavoidable problem. Hashimoto approached it from hands-on practice; OpenAI approached it from team engineering management. Different starting points, same destination.
| Phase | Core question | Scope | Analogy |
|---|---|---|---|
| Prompt engineering | How do I phrase my question? | A single prompt | Writing exam questions |
| Context engineering | What information does the model see? | All model inputs | Compiling a textbook |
| Harness engineering | How does the entire system operate? | Tools + permissions + validation + memory + observability | Building a school |
These phases stack, not replace. Effective harness engineers must understand context engineering. Effective context engineers must understand prompt engineering. Building a school requires knowing how to compile textbooks and write exams.
These three concepts get conflated constantly. They overlap, but mixing them up means solving problems at the wrong layer.
| Dimension | Prompt engineering | Context engineering | Harness engineering |
|---|---|---|---|
| Controls | How you talk to the AI | What information the AI sees | The environment the AI runs in |
| Scope | One prompt | All inputs for one call | Tools + permissions + validation + state + observability |
| Output determined by | Wording quality | Information completeness | System architecture quality |
| Failure signal | Vague output, format errors | Missing background, irrelevant answers | Multi-step crashes, infinite loops, unpredictable results |
| Fix method | Reword the prompt | Reorganize input data | Redesign the system architecture |
A practical diagnostic:
This diagnostic prevents wasted effort. Many developers reach for prompt rewrites when an agent fails a multi-step task. The real issue is almost always a missing validation loop or broken state management — harness-level problems that no prompt change can fix.
The harness splits into two categories: feedforward guides (constraints set before the agent works — guardrails) and feedback sensors (mechanisms that detect output quality after the agent works — radar). This two-part model comes from Birgitta Boeckeler's analysis on Martin Fowler's site.
Constraint layering is the first line of defense. Before the agent touches anything, boundaries are already drawn.
Concrete constraint carriers:
default, acceptEdits, plan, auto, dontAsk, bypassPermissions) and a machine-learning classifier, built on a "deny by default" design.The foundational principle: constraints are more valuable than capabilities. In OpenAI's internal products, all architectural constraints are enforced by custom linters and structured tests — code can only depend in one direction along a fixed layer hierarchy (Types → Config → Repo → Service → Runtime → UI). Violations fail the build. Not suggestions. Physical-law-level hard constraints.
Tool injection turns an agent from "can only think" into "can take action."
MCP (Model Context Protocol) is the dominant standard for tool injection — a universal adapter that lets agents connect to external tools and data sources. Through MCP, an agent can read and write files, execute commands, call APIs, and query databases.
VILA-Lab's source analysis shows Claude Code ships with 19 unconditional tools and 35 conditional tools, plus MCP extensions. But Cat Wu, Claude Code's product lead, emphasized a counterintuitive principle: fewer tools, not more. The team keeps only the minimum viable tool set: make a plan, manage a to-do list, edit files, ask clarifying questions. Unless a tool demonstrably improves token efficiency or accuracy, it stays out.
OpenAI follows the same logic. Their roughly 100-line AGENTS.md serves as a table of contents, not an encyclopedia. Actual instructions live in a structured docs/ directory, maintained by dedicated linters, CI tasks, and a periodically running "doc-gardening" agent.
Validation loops are the most critical subsystem. A harness without validation is a car without brakes — it moves, but a crash is inevitable.
Anthropic's practice provides a four-level progressive validation scheme:
Why is level four necessary? Anthropic's own research confirmed that agents grading their own work "reliably skew toward positive evaluation." They are too lenient, too easy to convince themselves a bug is minor. So the harness must separate the "generator" and "checker" roles.
Rules files and hooks form a two-tier execution model. The critical distinction: a rules file is advisory — if the file gets too long, the model may skip entries. A hook is deterministic — exit code 2 blocks unconditionally, no negotiation. The hook is the dividing line between "hoping the agent gets it right" and "guaranteeing the agent gets it right."
State management solves the agent's "memory" problem. Context windows have finite capacity. In long tasks, early information gets compressed or lost entirely.
Claude Code uses a five-stage compression pipeline: budget reduction → temporal pruning → micro-compression → context folding → auto-summarization (model-generated semantic summaries as a last resort). This pipeline runs before every model call.
But compression is not a cure-all. Anthropic's long-task harness design documentation acknowledges that for tasks exceeding a single context window, context resets are necessary — though resets add orchestration complexity and token overhead. The solution: subagents. A subagent works in an independent context window, completes its task, and returns only a summary to the main agent, protecting the main agent's context budget.
Anthropic's documentation puts it concisely: context is your most fundamental constraint, and subagents are how you work around it.
Harness engineering is not one company's theory. Multiple leading teams independently validated the same methodology in production.
OpenAI ran a large-scale harness engineering experiment for internal products. Roughly one million lines of code, all generated by Codex, zero hand-written. About 1,500 pull requests, team scaling from 3 to 7 people, averaging 3.5 PRs per person per day. OpenAI estimates efficiency at roughly ten times hand-written code.
The most instructive part is not the output volume but the harness design decisions:
Practical takeaway: Do not pack every detail into your rules file. Longer files mean the model is more likely to skip critical entries. Write pointers ("see docs/auth/ for the authentication flow"), not inline content ("here is the complete authentication flow...").
Birgitta Boeckeler proposed a clear mental model: Harness = Feedforward Guides + Feedback Sensors. Feedforward guides constrain before the agent acts — rules files, type systems, permission configs narrow the solution space. Feedback sensors detect after the agent acts — lint results, test pass rates, build exit codes judge outcomes and trigger corrections.
She also introduced a key concept: "harnessability" should become a first-class criterion for technology selection. Choosing frameworks, languages, and toolchains should factor in how friendly they are to AI agents — how easily you can add rules, validation, and permission controls.
LangChain ran a clean controlled experiment on Terminal Bench 2.0. Same model (gpt-5.2-codex), only harness changes. Score jumped from 52.8% to 66.5% — a 13.7 percentage-point improvement, ranking from roughly #33 to top 5.
Three optimization directions:
The single most effective change was the PreCompletionChecklist middleware — intercepting the agent before it declares "task complete" and forcing a validation loop. They also found a counterintuitive result: reasoning budget is not "more is better." A "reasoning sandwich" strategy — maximum budget for planning, standard for implementation, maximum again for verification — scored 66.5%, far above the 53.9% from maximum budget throughout.
Anthropic tested a three-agent architecture for long-running applications:
| Agent | Responsibility |
|---|---|
| Planner | Expands 1–4 sentences into a full product specification |
| Generator | Implements features, self-reviews before sprint end |
| Evaluator | Tests as an end user via browser automation |
Why three? Because generator and evaluator must be separate entities. Agents grading their own work reliably go easy on themselves.
The cost data is transparent: single-agent mode ran 20 minutes, cost $9, core features non-functional — effectively zero output. Full harness ran 6 hours, cost $200, features complete and operational. The V2 iteration removed the sprint structure, ran 3 hours 50 minutes, cost $124.70.
The key insight is not "$200 is expensive." It is "$9 produced zero usable value." The harness investment is not adding cost on top of a working baseline. It is the ticket from "nothing works" to "everything works."
Hashimoto's approach in the Ghostty project was radically simple. Every line in his AGENTS.md traces back to an observed agent mistake. His summary: "Each line in that file is based on a bad agent behavior, and it almost completely resolved them all."
He splits harness engineering into two forms:
He also articulated a core principle: give an agent a way to verify its own work, and it usually fixes its own mistakes. "If you give an agent a way to verify its work, it more often than not fixes its own mistakes and prevents regressions."
A shared theme across all five perspectives: well-designed constraints make agents stronger, not weaker.
After examining how industry leaders approach harness design, here is what a real production harness looks like in daily use. I run a multi-agent AI coding system that handles content creation, code audits, SEO operations, and course production. The harness started in late 2025 as a single rules file and grew into four layers through iteration — never through upfront architecture.
Every layer emerged from a real problem. Not one was planned in advance. That is the core philosophy of harness engineering: you do not need a blueprint. You need an observe-and-patch iteration cycle.
The constraint layer answers the most basic question: what can the agent do, what is forbidden, and how should things be done?
Four-level rules file hierarchy
My rules files follow a four-level hierarchy, each level scoped to its own domain:
The logic mirrors variable scoping in programming. Rules at the workflow level do not interfere with other workflows. When rules conflict, local overrides global — exactly like CSS specificity.
What real rules look like
Every rule is short, hard, and actionable:
- **Tools first**: Check the tool routing table; prefer local CLI. Fall back to MCP only if the local tool does not cover the operation. Never skip the routing table.
- **Read standards before creating**: Before creating or modifying any deliverable, locate and read the relevant standard in the standards directory.
- **Forward evolution**: When updating tools, standards, or documentation, overwrite with the correct approach. No backward compatibility. No deprecation warnings.
- **Tool crystallization**: Any operation repeated 3+ times gets packaged into a CLI tool before the next use.
- **Document sync**: After adding, deleting, or modifying files, immediately check and update all upstream and downstream references.
Notice the pattern: each rule has an explicit action verb ("check," "locate and read," "overwrite"), no hedging with "try to" or "consider." These are not coding guidelines for humans. They are behavioral constraints for agents — read and execute.
Each rule traces back to a real agent failure. "Tools first" exists because an agent once skipped the local routing table, called an external MCP service directly, and the task crashed due to rate limiting. "Read standards before creating" exists because an agent produced a deliverable with a non-compliant file structure. "Forward evolution" exists because an agent added "DEPRECATED" warnings during edits, accumulating outdated information across the knowledge base.
Every rule maps to a real failure — exactly Hashimoto's "AGENTS.md as failure log" principle.
The constraint layer defines "what and how." The tool layer defines "with what."
Local-first routing principle
A core routing rule: all operations prefer local CLI tools. MCP external services are fallback only.
The reasoning is determinism. Local tools produce predictable behavior — same input, same output, no network timeouts, no API changes, no rate limits. You can debug locally, version the tool, write tests. MCP services are remote calls, and any fluctuation in the network path can break an agent mid-task.
Harness engineering values system predictability over feature richness. A simple tool that runs every time beats a feature-rich external service that times out every third call.
Tool crystallization principle
Tools are not designed upfront — they crystallize from repeated operations. The rule: any operation repeated 3 or more times gets packaged into a CLI tool before the next execution.
The math is compound interest. First manual execution: 5 minutes. Second: 5 minutes. Third: you spend 30 minutes building a tool. From the fourth execution onward, each takes 10 seconds. Over 100 executions, manual totals 500 minutes; with the tool, roughly 47. Tools are compound-interest assets. Invest early, benefit exponentially.
Constraints set rules. Tools provide capabilities. But an agent can still produce low-quality work within valid boundaries. The validation layer ensures quality reaches a bar before delivery.
Three-tier review: objective gate → subjective rounds → human sign-off
The review mechanism directly maps to Anthropic's progressive validation and "generator-evaluator separation" principle:
| Review tier | Nature | Method | Bypassable? |
|---|---|---|---|
| Static quality check | Objective | Scripts + rules, quantifiable metrics | No. Non-zero exit code rejects the output |
| Dynamic refinement | Subjective | Multi-role review panel, iterative rounds | No. Must reach panel consensus |
| Human review | Manual | User-led, agent executes | No. Loop continues until explicit approval |
Static checks catch objective errors with deterministic tools — like a compiler catching type errors. Dynamic refinement uses multi-perspective review to catch subjective issues — one reviewer has blind spots, multiple roles cover more dimensions. Human review gives the final decision to a person — no AI review panel should decide "this is what I want."
The final gate: dual-layer pre-publish check
Before publication, a dual-layer gate enforces the "trust but verify" principle.
Layer one: script-based checks — hard metrics like word count minimums, frontmatter completeness, broken bold syntax, internal link HTTP status codes, and structured data validity. Mechanical, deterministic, agent-proof.
Layer two: independent agent deep review — a fresh agent instance with a clean context window reads the final draft end to end, specifically hunting for problems the upstream pipeline might miss: inconsistent terminology across sections, unsourced statistics, fabricated configurations, FAQ sections that merely repeat the body text.
Why a clean context window? An agent that has been "deeply involved" in creating the content for hours struggles to evaluate it objectively. A fresh agent in a fresh window provides physical isolation for evaluation independence.
Both layers must report zero errors before publication. Not a recommendation — a hard constraint.
The first three layers solve single-agent, single-task harness problems. Batch operations — optimizing dozens of published articles, generating cover images site-wide, converting a library of books to structured format — exceed what any single agent context window can hold.
Parallel dispatch with context isolation
Batch tasks split into independent subtasks, dispatched to multiple agents running in parallel across separate context windows. Each agent handles its assigned subtask with no information leakage from other tasks.
This mirrors Anthropic's subagent philosophy. When an agent processes item 12, its context window contains only item 12's information, uncontaminated by items 1 through 11. Isolation delivers predictability: item 12 receives the same processing quality as item 1, with no degradation from a filling context window.
State persistence and checkpoint recovery
Every execution produces a versioned run archive — unique run identifier, versioned stage outputs, progress state file, and an artifact index for cross-stage handoffs.
This solves a practical problem: long tasks will be interrupted. Network drops, context window fills, model service outage — interruption causes vary. Without state persistence, interruption means starting from scratch. With run archives, the agent picks up from the last checkpoint. Completed stages do not re-execute.
Not one of these layers was planned in advance. The system started with a single rules file — a few dozen lines documenting the agent's most common mistakes. Manual operations piled up, so CLI tools emerged. Tools ran but output quality varied, so validation hooks and review processes followed. Single-agent capacity could not handle batch work, so multi-agent scheduling arrived.
Each layer was forced into existence by a real problem. This is exactly how harness engineering works: do not architect top-down. Iterate from practice.
Concepts and architectures are useful, but a practical question remains: with limited resources, should you invest in a better model or a better harness?
I argue that harness investment delivers higher returns than waiting for the next model generation. Model improvements are out of your control. Harness improvements are deterministic. Data backs this up.
Evidence 1: LangChain — same model, +13.7 points. Model gpt-5.2-codex unchanged. Pure harness optimization. Terminal Bench 2.0 score from 52.8% to 66.5%. This gain exceeds what most model upgrades deliver.
Evidence 2: Opus 4.6 — default harness #33 vs. custom harness #5. Same model, same benchmark. Default harness: rank roughly #33. Custom harness: roughly #5 (both with approximately ±4 position variance). Nearly 30 ranks apart. Zero code changes to the model.
Evidence 3: Anthropic — $9 for zero output vs. $200 for complete features. Single-agent mode cost $9, ran 20 minutes, produced nothing usable. Full harness cost $200, ran 6 hours, delivered working software. The harness is not a cost multiplier — it is the difference between zero and one.
Evidence 4: OpenAI — roughly one million lines in production. One million lines of Codex-generated code merged into production over five months. 3-to-7-person team, roughly ten times the efficiency of hand-written code. This efficiency does not come from "a better model" — teams using the same model without a comparable harness cannot replicate this output level.
All four data points converge: model capabilities are commoditizing. Harness quality is the differentiator. Everyone can call GPT-5, Claude Opus, or Gemini. Not everyone can build a high-quality harness. When the model becomes a commodity, the engineering around the model becomes the real moat.
If you think harness engineering solves everything, you have only heard the positive side. I believe the concept carries some hype risk. Here are five real limitations.
Martin Fowler's site states it plainly: harnesses are hardest to build where they are needed most. A decade-old codebase with missing architectural constraints, sparse test coverage, and fragmented documentation resists reliable agent operation. Every success story cited above — OpenAI, LangChain, Anthropic — comes from greenfield projects or teams that built harnesses from scratch.
Constraints are assets, but too many become liabilities. Augment Code's guide warns: set complexity ceilings too low and legitimate refactors get flagged as violations. Lint rules that reject valid patterns slow the agent without improving quality. The hard problem is not "should I add constraints?" but "how many constraints are exactly right?" — an engineering judgment with no universal answer.
Cat Wu's practice reinforces this. As models improve, her team actively removes scaffolding from system prompts and tool descriptions. The method is not adding rules but deleting them. When the model gets stronger, workarounds that compensated for old weaknesses become dead weight.
Anthropic's own data: full harness pipeline cost $200 and 6 hours. For exploratory prototypes or throwaway scripts, that investment may not be justified. Harness engineering fits scenarios where tasks run repeatedly, reliability requirements are high, and failure costs are steep. Not every project meets those criteria.
Sutton's Bitter Lesson suggests that general methods leveraging compute scale ultimately defeat specialized methods leveraging human domain knowledge. Critics extend this to harness engineering: the harness you meticulously designed for 2026 model weaknesses may be dissolved by the next model generation.
The critique has merit, but it also has a rebuttal. Some harness elements are permanent: "run tests to confirm correctness," "no unreviewed code merges to main." Others are temporary: "limit file length because the model handles long files poorly." Cat Wu's practice of continuously pruning system prompt scaffolding illustrates the distinction.
A practical test: if the model became smarter than you, would this rule still be needed?
After each model upgrade, spend 30 minutes reviewing your rules file. Delete the second category. Your harness should get lighter as models get stronger.
The community raises this. Strip away the model, and what remains is containers, callable tools, read-output-decide-next-step loops, logging, timeouts, cleanup — overlap with what DevOps engineers have done for years.
The difference is the constraint target. DevOps constrains the deployment pipeline for human-written code. Harness engineering constrains agent behavior itself — how it interprets tasks, searches for information, validates output, and remembers lessons. But the underlying mental models overlap heavily: deterministic constraints beat manual review, automated verification beats manual checking, graduated trust beats blanket authorization.
If you have a DevOps background, harness engineering comes naturally. The core mental model is already there. What is new is applying it to AI agents as the constraint target.
Regardless of your AI coding tool — Claude Code, Cursor, Windsurf, Codex — start here:
Step 1: Create a rules file.
Add a CLAUDE.md (Claude Code), AGENTS.md (Codex), or .cursorrules (Cursor) to your project root. Write down basic rules: project conventions, coding style, forbidden operations. Three to five rules is enough. Do not over-engineer.
Step 2: Observe agent failures and log them.
Run real tasks. Record every mistake. Wrong command? File that should not have been edited? Incorrect API parameter? These observations are your raw material.
Step 3: Turn observations into rules.
Convert step 2 logs into step 1 rules. Each new rule reduces the probability of that error class recurring.
This loop compounds. Hashimoto's Ghostty project followed exactly this process, and the result was "almost completely resolved them all."
After the starter loop stabilizes, layer up as needed:
Layer 1: Constraints (lowest difficulty, immediate impact). Rules files are the foundation. Write them like failure logs. Each rule traces to a real observed failure. As rules accumulate, agent behavior becomes progressively more predictable.
Layer 2: Tools (moderate difficulty, capability expansion). When the agent needs external data or specific operations, inject tools via MCP. Remember Cat Wu's principle: unless a tool demonstrably improves performance or accuracy, do not add it. Fewer tools mean a more controllable harness.
Layer 3: Validation (higher difficulty, quality assurance). Add hooks — scripts that run automatically before and after tool calls. This is the step from "advisory" to "mandatory." Tests fail → execution halts. Linter errors → no commit allowed.
Layer 4: Orchestration (highest difficulty, scale). When task complexity exceeds a single agent's context window, introduce subagents and multi-agent coordination. Subagents work in isolated windows, protecting the main agent's context. Multi-agent orchestration requires explicit state management and task dispatch mechanisms.
Each layer builds on the stability of the one below. Do not attempt all four at once. Master constraints first, then progress upward. The core of harness engineering is not an architecture diagram — it is the continuous cycle of observing, fixing, and improving.
What this does: Designs the four runtime subsystems around your model — tool injection, validation loops, constraint layering, state management — confirms the harness matters more than the model, and runs a readiness self-check so the agent goes from capable to reliably capable.
Based on: Harness Engineering: The Complete Guide to Building Reliable AI Coding Systems — https://aiworkflowpro.com/harness-engineering-guide/
Time to run: ~5 minutes
Copy this prompt into Claude Code, ChatGPT, or any AI assistant:
ROLE: You are an AI harness engineer. Your job: design the four runtime subsystems wrapped around a model — tool injection, validation loops, constraint layering, state management — so an agent goes from "capable" to "reliably capable," then run the readiness self-check.
CONTEXT — FOUR-SUBSYSTEM HARNESS DESIGN:
In a leading AI coding tool, 98.4% of the codebase has nothing to do with model inference — the rest is the harness: tool injection, permission controls, context compression, state persistence, safety checks. The harness, not the model, makes an agent reliably capable (same model, different harness, massive gap). Harness engineering builds four runtime subsystems around the model: tool injection (what tools it can call and how they are permissioned), validation loops (how output is verified before acceptance), constraint layering (the hard rules, scope, and safety), and state management (context compression and persistence across runs). This is distinct from context or prompt engineering — it is the runtime infrastructure, and it is the defining skill gap in AI coding.
INPUTS (fill in before running):
- AGENT_JOB: YOUR_USE_CASE_HERE (what the agent must do — coding, research, content, ops)
- CURRENT_MODEL: YOUR_MODEL_HERE (which model you run — or "deciding")
- RELIABILITY_NEED: YOUR_STAKES_HERE (best-effort / must-be-reliable / must-work-unattended)
- EXISTING_HARNESS: YOUR_TODAY_HERE (what runtime infra you already have — or "none, raw model")
METHOD — 6 STEPS:
Step 1 — Design tool injection
List the tools the agent may call for AGENT_JOB and how each is permissioned and surfaced. Inject only what the job needs — every extra tool is attack surface and context cost. Mark each tool read/write/exec and required/optional.
Step 2 — Design validation loops
Define how output is verified before acceptance: a test/check per action, a retry on failure, and a max-retry cap. For RELIABILITY_NEED = must-work-unattended, every action needs an automated validation gate — an agent without validation loops is "capable," not "reliably capable."
Step 3 — Design constraint layering
Define the hard rules: scope boundaries (allowed files/paths/actions), safety checks (block destructive ops), and denylists. Constraints are imperative and checkable, not advice. Layer them so the most dangerous are enforced earliest (before the action, not after).
Step 4 — Design state management
Define context compression (what stays loaded vs evicted) and persistence (what survives across runs — decisions, progress, memory). For long or multi-session jobs, persistence is what prevents restart-from-zero; without it the agent is stateless and unreliable past one session.
Step 5 — Confirm harness-over-model priority
Check EXISTING_HARNESS: if it is "none/raw model," the highest-leverage move is building the harness, not swapping CURRENT_MODEL. State the one subsystem whose absence most limits reliability today.
Step 6 — Run the readiness self-check
Score each subsystem 0-2: tool injection (scoped + permissioned), validation loops (per-action gate), constraint layering (imperative + early-enforced), state management (compression + persistence). Reliability-ready for must-work-unattended requires 2 on all four; flag the lowest subsystem to build first.
RULES:
- Inject only the tools the job needs — extra tools are attack surface and context cost.
- Every action in a reliable agent has a validation gate before acceptance.
- Constraints are imperative and enforced early (before the action), not advisory.
- Improve the harness before swapping the model — same model, better harness, massive gap.
OUTPUT FORMAT:
Output six sections:
1. **Tool injection** — markdown table with columns: Tool | Permission (read/write/exec) | Required? (Y/N).
2. **Validation loops** — the per-action check + retry policy + max-retry cap.
3. **Constraint layering** — the hard rules + which are pre-action enforced.
4. **State management** — compression policy + persistence scheme.
5. **Harness-over-model check** — the one subsystem most limiting reliability today + why the harness beats a model swap.
6. **Readiness self-check** — markdown table with columns: Subsystem | Score (0-2) | Gap, + a "build first" line.
Save as @templates/harness-engineering-guide.md and run when you build or audit an AI agent's runtime, then re-run whenever the use case, reliability need, or model changes.
Prompt engineering optimizes how you talk to an AI model — single-input wording. Harness engineering designs the entire runtime environment: tool injection, permission controls, validation loops, and state management. They are a containment relationship: harness engineering includes prompt engineering but covers far more ground.
Mitchell Hashimoto first named it on February 5, 2026. Ryan Lopopolo from OpenAI formally defined it six days later. Both arrived independently. The full timeline is covered in the "Where Did Harness Engineering Come From?" section above.
Three-step starter loop: create a rules file → observe agent failures and log them → convert observations into rules. No framework needed. A text file is enough to begin. For structured learning, WalkingLabs offers a Learn Harness Engineering course (English, open source, with code exercises).
Context engineering manages "what the model sees." Harness engineering manages "the environment the model runs in." They complement each other. The harness includes context management (e.g., compression pipelines) but also covers tool injection, permission controls, and validation loops that context engineering does not touch. Context engineering is a subset of harness engineering.
It depends on complexity, not project size. Throwaway scripts and simple one-shot queries do not need it. But the moment an AI agent executes multi-step tasks, manipulates files, or calls external tools, even the simplest harness — one rules file plus one validation command — pays for itself. Startup cost is low. Returns are deterministic.
— hh
Gloves on, tape measure in hand — nobody types a query. Three voice surfaces for ai automation tools (terminal, Telegram, Discord), 10 TTS and 6 STT providers compared on cost and latency, plus a setup that costs nothing.
Nothing about month four is harder than month three. It is simply the month an unpaid channel starts to feel like proof of failure. Surviving it takes a cadence you can hold while earning nothing, which is a better reason to automate business processes than speed ever was.
One number hides more than it shows. This Claude Code Skill scores US equities across 10 dimensions, from earnings surprise to peer comparison, with confidence scoring and 5 safety valves that flag thin data. A coding tutorial, not financial advice.
Publishing eats your week through research, SEO fields, images, and uploading — not writing. Here is the 10-step workflow automation pipeline that takes a topic to a published draft on one command, and the data contract that lets each step hand off cleanly to the next.
When I rebuild one with AI agents, you get the write-up — including the parts that didn't work. No weekly roundup, no "5 tools you need."