The Millennium Falcon has one of the fastest hyperdrives in the galaxy. On raw specs, it should outrun anything the Empire fields.
It also breaks down constantly.
The hyperdrive cuts out over Hoth. Systems short-circuit mid-flight. The ship is a collection of modifications, patches, overrides, and jury-rigged fixes that somehow, collectively, make it one of the most effective ships in the Rebel fleet. That effectiveness does not come from the hyperdrive. It comes from the navicomputer that calculates safe routes before the ship jumps, the deflector shields that absorb damage when things go wrong, Chewie in the back rerouting power and pulling manual overrides, and Han making real-time calls about when to jump, when to evade, and when to shut everything down and hide.
The AI industry spent three years obsessing over the engine. Bigger models. Longer context windows. Higher benchmark scores. Every release was treated like a breakthrough because the underlying model got smarter.
Then teams started shipping agents into production and discovered something uncomfortable: a smarter model did not automatically produce a more reliable agent. The agent still called tools in the wrong order. It still lost track of multi-step workflows. It still hallucinated function names that did not exist. The brain was brilliant. Everything around the brain was held together with tape.
The hyperdrive is the model. Everything else is the harness.
What Harness Engineering Is
The term was coined by Mitchell Hashimoto, co-founder of HashiCorp, in early 2026. The formula is: Agent = Model + Harness. The model provides reasoning. The harness provides everything else: the system prompts that set behavior, the tools the agent can call, the guardrails that prevent bad actions, the memory systems that maintain context, and the feedback loops that catch and correct errors.
This is a meaningful shift from how most teams were building AI products twelve months ago. The old approach was prompt engineering: write better instructions, hope the model follows them. Harness engineering treats the entire runtime environment as an engineered system. Not one good prompt. The infrastructure that governs agent behavior across every turn, every session, and every failure mode.
The Five Components
Look at the top coding agents side by side and they look more alike than their underlying models do. Claude Code, Cursor, Codex, Aider. Different models, similar harness architecture. The components are converging around a standard set of building blocks.
| Component | What It Does | Falcon Analog |
|---|---|---|
| Guides | Steer the agent before it acts | Navicomputer |
| Sensors | Observe and validate after the agent acts | Chewie monitoring systems |
| Tools | External capabilities the agent can invoke | Weapon systems, comms array |
| Context Management | Controls what the agent can see at any moment | Cockpit instruments |
| Guardrails | Hard limits on what the agent cannot do | Deflector shields |
Guides: The Navicomputer
Guides are feedforward controls. They steer the agent before it acts by shaping what it knows, what it prioritizes, and how it approaches a task. The goal is to increase the probability that the agent produces a good result on its first attempt.
Before the Falcon makes a hyperspace jump, the navicomputer calculates the route. Gravitational fields, asteroid belts, known hazards. All of it processed before the ship moves.
In practice, guides include three things.
System prompts that define the agent's role, constraints, and behavioral expectations. Not a paragraph of instructions. A comprehensive operating manual that covers how to handle ambiguity, what to do when a tool call fails, and what the agent is explicitly not allowed to attempt.
AGENTS.md or CLAUDE.md files that live in a project's codebase and give the agent repository-specific context: directory structure, naming conventions, testing requirements, deployment patterns. Generic system prompts tell the agent how to behave. Project files tell it how to behave here.
Constraint documents that encode business rules, compliance requirements, and domain-specific logic. If your agent writes SQL, the constraint doc specifies which tables are trusted sources and which are raw data that should never be queried directly.
The key insight: guides are not static. Every time the agent makes a mistake that a better guide would have prevented, you update the guide. The harness tightens.
Sensors: Chewie Monitoring Systems
Sensors are feedback controls. They observe the agent's output after it acts and determine whether the result is acceptable. If not, they provide signals the agent can use to self-correct.
This is Chewie's job. He is not flying the ship. He is watching gauges, listening for problems, and intervening when something goes wrong. He does not prevent every problem. He catches the ones that get past the navicomputer and fixes them before they become catastrophic.
Sensors come in two categories.
Computational sensors are cheap and fast. Linters, type checkers, unit tests, output format validators. These run on every action the agent takes, in real time, and catch structural errors immediately. Did the agent produce valid JSON? Does the code compile? Did it follow the naming convention? Binary checks with instant feedback.
Inferential sensors use another model call to evaluate the output semantically. Does this code change actually accomplish what the user asked? Is this SQL query logically correct? More expensive and non-deterministic, but they catch the errors structural validators miss. Some teams write custom linter messages that include correction instructions. The sensor does not just flag the error. It tells the agent how to fix it.
The most effective harness designs run computational sensors on every cycle and reserve inferential sensors for high-stakes actions or when structural sensors have already flagged a potential issue.
Tools: External Capabilities
Tools are the external capabilities wired into the agent. API calls, database queries, file system operations, browser automation, MCP servers. Without tools, the agent can only reason and write text. With tools, it can act on the world.
Han does not need to understand the engineering behind the quad laser cannons. He knows what they do, when to use them, and what inputs they require. The ship handles the rest. Tool definitions work the same way. The agent sees a name, a description, and a parameter schema. It decides when to invoke the tool based on context. The harness handles execution, error handling, and result formatting.
Two things matter most.
Fewer tools often outperform more tools. Every tool definition consumes input tokens on every request, whether the agent uses it or not. Vercel has reported that reducing the number of available tools improved task success rates. A bloated tool registry adds weight, complexity, and failure surface.
Tool descriptions are part of the harness, not decoration. A vague description produces vague tool usage. A precise description that covers when to use the tool, what it expects, and what to do with the result substantially improves agent decision-making.
Context Management: The Cockpit Instruments
Context management controls what the agent can see at any given moment.
The Falcon's sensors collect enormous amounts of data. The cockpit does not dump all of it onto the pilot at once. It surfaces what matters right now and suppresses the rest.
For agents, this means four things.
Context window budgeting: deciding how to allocate limited token space across system prompts, conversation history, retrieved documents, and tool definitions. Every token spent on background context is a token unavailable for the actual task.
Memory systems: short-term (conversation history), mid-term (session-level state), and long-term (persistent knowledge stores). The harness decides what to keep, what to compress, and what to offload to external storage.
Context compaction: as conversations grow long, the harness summarizes older exchanges to free up token space for new information.
Subagent isolation: in multi-agent systems, each subagent operates with its own scoped context. The orchestrator does not dump the full context of every subtask into every agent. It passes only what each agent needs.
Guardrails: Deflector Shields
Guardrails are the hard limits on what the agent cannot do, regardless of what the model generates.
The deflector shield does not steer the ship. It does not help the pilot make decisions. It absorbs damage from situations the pilot could not avoid or did not anticipate. That is the job.
In practice, guardrails include:
Permission boundaries: the agent can read files but not delete them. It can query the database but not modify schema. It can draft emails but not send them without human approval.
Cost caps: maximum spend per request, per session, or per day. Without these, a runaway agent loop can generate a five-figure API bill in hours. This is not hypothetical.
Action blocklists: explicit lists of actions the agent is never allowed to take, regardless of how convincing the reasoning chain looks. No production database writes. No credential access. No external network calls to unapproved domains.
Sandbox isolation: the agent executes code in a containerized environment where it cannot affect the host system. If the agent writes and runs broken code, the damage is contained.
Guardrails are non-negotiable for production agents. Every other part of the harness tries to prevent bad outcomes. Guardrails ensure that when prevention fails, the blast radius is contained.
The Tightening Loop
Every time the agent fails, you improve the harness so that specific failure cannot recur. You do not wait for a smarter model. You do not rewrite the prompt and hope. You build a structural fix.
| Failure | Harness Fix | Component |
|---|---|---|
| Agent calls a tool that does not exist | Add a sensor that validates tool names before execution | Sensor |
| Agent writes SQL querying raw data instead of staging models | Add a constraint doc specifying trusted sources | Guide |
| Agent enters an infinite retry loop on a failed API call | Add a max-retry limit and cost cap | Guardrail |
| Agent loses context halfway through a long task | Implement context compaction and state checkpointing | Context Management |
| Agent uses the wrong tool for a task it has done correctly before | Improve tool descriptions with explicit use-case guidance | Tool |
The loop is continuous. Ship agents. Watch them fail. Fix the harness. Ship again. The harness gets tighter with every iteration, and the agent gets more reliable without the model itself changing at all.
Why This Matters Now
Three forces are converging.
Models are commoditizing. The gap between the best and second-best model shrinks with every release cycle. When GPT-4o, Claude, and Gemini are all within spitting distance on benchmarks, the model is no longer the differentiator. The harness is.
Agents are moving from demos to production. A demo agent that works 80% of the time is impressive. A production agent that fails 20% of the time is unusable. The harness is what closes that gap. Gartner projects that 40% of enterprise applications will include task-specific AI agents by end of 2026. Those agents need harnesses, not just models.
The model upgrade treadmill is unsustainable. If your agent reliability depends on the next model release fixing your problems, you are building on sand. Models improve on their timeline, not yours. The harness lets you improve reliability on your timeline, with your specific failure data, without waiting for anyone.
Getting Started
You do not need all five components on day one.
Start with guides. Write a comprehensive system prompt and a project-level context file. This is the single highest-leverage action. A well-written guide prevents more failures than any other component and costs nothing to implement.
Add computational sensors next. Output validation, format checking, basic linting on any code the agent produces. Cheap, fast, and they catch the most common structural errors.
Set guardrails before you scale. Permission boundaries and cost caps. Do not learn this lesson the expensive way.
Layer in context management as conversations get longer. You will not need memory systems or compaction for short, single-turn interactions. You will need them the moment your agent starts handling multi-step workflows.
Add inferential sensors last. The most expensive and most complex. Add them when your agent handles high-stakes decisions where structural validation is not sufficient.
What This Looks Like in Practice: JESTR
The framework above is not theoretical. We built JESTR around it.
JESTR is a multi-agent platform that lets marketing teams query their data warehouse and submit data correction requests in plain English. No SQL. No developer involvement. A natural language question goes in, a verified answer comes back, and approved corrections commit directly to GitHub.
The harness is what makes that reliable enough to run in production.
Guides do most of the heavy lifting upfront. Before any agent touches a query, the system injects client-specific context: campaign taxonomy, fiscal calendar definitions, which BigQuery tables are authoritative sources and which are raw staging data that should never be queried directly. The SQL agent does not have to guess what “Brand” versus “Performance” means for this specific client. That context is baked in before the first token is generated.
Context management keeps each agent scoped to what it actually needs. JESTR runs a three-stage pipeline: a Haiku orchestrator that routes the request, parallel SQL and RAG workers that retrieve structured and unstructured data independently, and a Sonnet synthesizer that combines the results. Each stage receives only the context relevant to its job. The SQL worker gets BigQuery schema notes. The RAG worker runs pure vector similarity against the document library. The synthesizer gets both outputs and the original question. None of them get each other's working context.
Sensors handle validation at every stage. The SQL worker generates a query, the harness validates it is a SELECT statement before execution, and the result gets checked for structural correctness before passing to synthesis. For correction requests, the entire workflow sits behind an admin approval gate. The agent proposes a SQL diff. A human reviews it. The commit only happens after explicit approval.
Guardrails make the permissions explicit and non-negotiable. SELECT-only SQL execution. Encrypted credentials. Correction requests cannot bypass the approval gate regardless of who submits them.
Claude Haiku handles routing. Claude Sonnet handles synthesis. The models provide the reasoning. The harness determines whether that reasoning produces something trustworthy enough to act on. That distinction is the whole product.
Model access is not the differentiator anymore. Every competitor has access to the same frontier models. The differentiation is what you build around the model: how it handles failure, how it manages context, what it is and is not allowed to do, and how quickly you iterate when something breaks.
You can build that today. On your timeline. With your own failure data.
