Harness Engineering: When Humans Steer and Agents Execute

The agent worked perfectly. Then it deleted the database.

Three weeks into production, an AI coding agent at a mid-size SaaS company ran a migration script backward. Not maliciously. Not randomly. The agent followed its instructions precisely: "clean up unused tables." The problem was not the agent's reasoning. The problem was that nothing in the system prevented the agent from interpreting "unused" as "not queried in the last 30 days," which included the billing table during a seasonal low-traffic period. No human reviewed the action before execution. No constraint existed to flag destructive operations. No harness.

product.engineer defines harness engineering as the discipline of designing the constraints, checkpoints, and control surfaces that allow AI agents to operate with meaningful autonomy while preventing catastrophic outcomes. It is the practice of building the system around the agent, ensuring that human judgment governs irreversible decisions while agent speed handles everything else.

This is the defining skill gap for the product engineer building with AI in 2026. You can have brilliant agents. You can have perfect context windows. But if you do not have a harness, you do not have a production system. You have a demo with a timer counting down to the first incident.

The term gained traction after the AI Engineer World's Fair talks (which collectively accumulated over 200,000 views across sessions on agent reliability) formalized what practitioners had been converging on independently: the most important code in an agent system is not the agent itself. It is the code that wraps, constrains, and directs the agent. The harness.

Why agents need harnesses, not just prompts

The naive approach to agent safety is instructions. "Do not delete production data." "Always ask for confirmation before destructive actions." "Never modify files outside the project directory." You write these into the system prompt and hope for the best.

Hope is not an engineering strategy.

A 2025 study from the University of Illinois (published at NeurIPS) tested instruction-following reliability across major foundation models on safety-critical directives. Even the strongest models (Claude 3.5 Sonnet, GPT-4 Turbo) violated explicit system prompt constraints 4-7% of the time in multi-step agentic tasks. That percentage sounds small until you calculate what it means at scale. An agent that processes 100 tasks per day with a 5% constraint violation rate will produce 35 violations per week. If even 10% of those violations are consequential, that is 3-4 incidents weekly in production.

Instructions are necessary. They are not sufficient.

This is the same lesson distributed systems taught us a decade ago. You do not secure a microservice by telling it "do not accept unauthorized requests." You put an authentication layer in front of it. You do not prevent race conditions by adding a comment that says "do not call this concurrently." You use a mutex. The enforcement mechanism is architectural, not verbal.

A harness is that architectural enforcement for AI agents. It operates at the system level, outside the model's reasoning process, where it cannot be reasoned around, ignored, or misinterpreted. The agent cannot talk its way past a harness the way it can talk its way past a prompt instruction.

The harness pattern: anatomy of production-grade agent control

Having spent years at AWS building systems where failure is measured in customer impact, and having coached over 12,000 engineers on shipping reliable software, the product.engineer framework for harness design formalizes the pattern into four layers, each serving a distinct function that cannot be collapsed into the others.

Layer 1: Action classification

Before an agent executes any action, the harness classifies it. Not the agent. The harness. This distinction is critical. If you ask the agent to self-classify its actions as "safe" or "dangerous," you are asking the same system that wants to take the action to evaluate whether it should. That is a conflict of interest built into the architecture.

The classification layer operates on the action itself, independent of the agent's reasoning:

• Read operations: File reads, API GETs, database queries, web fetches. Low risk. Execute immediately.
• Bounded writes: File modifications within defined scope, API calls with idempotent semantics, database updates with transaction support. Medium risk. Log and execute.
• Unbounded writes: File deletions, schema changes, production deployments, financial transactions. High risk. Require human approval.
• System modifications: Permission changes, infrastructure alterations, credential operations. Critical risk. Require explicit human authorization with audit trail.

Anthropic's Claude Code implements exactly this pattern. Every tool call is classified before execution. Read operations proceed silently. Write operations require acknowledgment. Destructive operations require explicit approval. The agent never decides its own permission level. The harness decides.

Layer 2: Scope boundaries

Scope boundaries define the operational perimeter. They answer: where can this agent operate, and where is it forbidden to go?

Linear's internal agent systems, as described by their engineering team, implement scope boundaries at the project level. An agent tasked with "fix the auth bug" has read access to the entire codebase but write access only to files that changed in the last 30 days within the auth module. It cannot modify infrastructure code. It cannot touch the billing system. It cannot push to main. These boundaries are enforced by the harness, not requested by the prompt.

Scope boundaries include:

• File system boundaries: Which directories and files the agent can read, modify, create, or delete
• Network boundaries: Which APIs the agent can call, which endpoints are allowed or blocked
• Time boundaries: How long the agent can execute before forced termination
• Resource boundaries: How much compute, memory, or API budget the agent can consume
• Blast radius limits: How many files, records, or resources a single operation can affect

The product engineer designing a harness thinks about blast radius the same way an SRE thinks about failure domains. If something goes wrong, how bad can it get? Then you design the boundary so the answer is "not very."

Layer 3: Checkpoint gates

Checkpoint gates are moments in the execution flow where the harness pauses the agent and presents state to a human for review. They are not confirmations ("proceed? y/n"). They are inspection points where the human sees what the agent plans to do, understands why, and can redirect, modify, or abort.

The design challenge is placement. Too many checkpoints and you lose the speed advantage of agents entirely. Too few and you are back to the "deleted the billing table" scenario. The optimal placement follows what I call the Irreversibility Principle: place checkpoints before actions that are expensive to undo.

Vercel's v0 product demonstrates this well. The agent can generate, modify, and preview code freely. Those actions are cheap to undo. But when it comes to deploying, modifying environment variables, or changing DNS records, the system inserts explicit checkpoints. The human sees the planned action, the current state, and the proposed state. Only then does execution proceed.

A comparison of checkpoint strategies:

Most production systems use category-based or milestone-based, depending on the domain's risk profile.

Layer 4: Observation and correction

The final layer is continuous observation. Not logging (though logging is part of it). Observation means the harness watches the agent's behavior over time and detects drift, anomalies, or patterns that suggest the agent has gone off track before the consequences become visible.

This is where context engineering intersects with harness engineering. The observation layer feeds information back into the agent's context, creating a correction loop. If the agent starts making repeated API calls to the same endpoint (suggesting a retry loop), the harness can inject context: "You have called this endpoint 5 times. The response has been the same each time. Consider an alternative approach." This is not a hard stop. It is a nudge. But it is a nudge from outside the agent's reasoning process, which gives it different epistemic weight.

PostHog's internal engineering tools implement observation as a real-time dashboard. Engineers can watch their AI coding agents in action, see the pattern of tool calls, and intervene before a problematic trajectory reaches execution. The observation layer makes agent behavior legible to humans in a way that raw logs never could.

The harness engineering toolkit

What does a harness actually look like in code? Let me walk through the components that every production-grade AI harness needs.

Permission systems

Every action maps to a permission. Permissions are defined outside the agent, versioned alongside the application code, and enforceable at runtime. This is not new computer science. It is RBAC (Role-Based Access Control) applied to AI agents instead of human users.

agent_permissions:
  codebase_reader:
    allow:
      - file.read:**
      - git.log
      - git.diff
    deny:
      - file.write:**
      - git.push
      - git.commit
  
  codebase_writer:
    allow:
      - file.read:**
      - file.write:src/**
      - git.commit
    deny:
      - file.write:infrastructure/**
      - file.write:.env*
      - git.push:main
      - git.force_push

The permission system is the harness's immune system. It defines what is possible regardless of what the agent decides to attempt.

Execution sandboxes

The agent runs in a sandbox. Its actions affect a controlled environment, not production directly. Changes accumulate in the sandbox until a human reviews and promotes them.

Stripe's approach (referenced in their engineering blog) runs all AI-generated code changes in an isolated environment that mirrors production but has no access to real customer data. The agent can write, test, and iterate freely within the sandbox. When the changes are ready, a human reviews the diff, runs it against production-representative test suites, and only then merges.

This is not a new idea either. It is how we have deployed code for decades: staging environments, canary deployments, feature flags. The harness applies the same principle to agent-generated work.

Kill switches

Every agent system needs a kill switch. Not "please stop when convenient." An immediate, hard stop that terminates execution, rolls back any in-progress changes, and returns the system to a known good state.

This sounds obvious. In practice, many agent systems lack clean termination paths. The agent is mid-way through a multi-step operation. You hit stop. But the first three steps already executed, and the remaining steps were the ones that would have cleaned up after the first three. Now you have a partial operation with inconsistent state.

Production harnesses implement transactional semantics: either all steps complete, or the entire operation is rolled back to the pre-execution state. This requires the harness to maintain a checkpoint log of state before each action, enabling reliable rollback at any point in the execution sequence.

When the harness is too tight: the over-constraint problem

There is a failure mode on the opposite end. Harnesses that are so restrictive they eliminate the value of the agent entirely. The agent can read files but not modify them. It can suggest code but not write it. It can plan but not execute. At that point, you have built a very expensive autocomplete system.

The art of harness engineering is calibration. You want the agent operating at maximum useful autonomy within minimum acceptable risk. This is a product decision, not just a technical one, which is why the product engineer is uniquely positioned to get it right. You understand the user's needs. You understand the business risk. You understand the technical constraints. You can calibrate the harness where a pure infrastructure engineer would default to maximum restriction and a pure product manager would default to maximum autonomy.

The calibration framework I use when advising teams:

1. Start restrictive. New agents begin with read-only permissions and mandatory checkpoints on every write.
2. Measure violation rate. Track how often the agent attempts actions outside its permission boundary.
3. Expand where violations are safe. If the agent repeatedly tries to do something and that action would have been fine, expand the permission.
4. Tighten where errors are costly. If the agent occasionally produces problematic outputs in a category, add a checkpoint gate.
5. Iterate on cadence. Review harness configuration weekly for the first month, then monthly.

This is not unlike progressive disclosure in UX design. The agent earns trust through demonstrated reliability, and the harness adjusts accordingly.

The AI harness in multi-agent systems

Harness engineering becomes exponentially more important in multi-agent architectures. When multiple agents coordinate on a task, the blast radius of a misconfigured harness multiplies. Agent A produces output that Agent B consumes. If Agent A's harness allows it to produce malformed output, Agent B may process it incorrectly, and Agent C may act on that incorrect processing.

The harness pattern for multi-agent systems adds an inter-agent contract layer. Each agent's output is validated by the harness against a schema before it can be consumed by the next agent. This is exactly how API contracts work between microservices. The harness is the API gateway of the agent world.

Factory AI's production system (which processes thousands of coding tasks daily) implements inter-agent harnesses as typed interfaces. The Drafter agent's output must conform to a structured diff format. If it produces anything else, the harness rejects it before the Reviewer agent ever sees it. The Reviewer's output must conform to a structured feedback format. If it produces free-form text, the harness rejects it before the Integrator consumes it.

This inter-agent validation catches a class of errors that per-agent harnesses miss. It is not enough for each agent to be individually constrained. The interfaces between them must be constrained too.

Harness engineering vs. traditional testing

A natural question: is this not just testing? If I have good tests, do I need a harness?

No. Testing verifies the agent produced correct output after execution. A harness prevents incorrect execution from occurring. These are complementary, not substitutable.

You need both. Tests validate the agent's reasoning quality. The harness ensures the agent's actions stay within acceptable boundaries regardless of reasoning quality. A well-tested agent in a well-designed harness is the production standard. Either alone is insufficient.

Real-world harness patterns from production

Let me share patterns I have seen work across teams I have coached and systems I have built. These are not hypothetical. They are running in production today.

The "draft, diff, deploy" pattern

Used by teams at Shopify and similar commerce platforms. The agent drafts changes in a scratch branch. The harness generates a human-readable diff showing exactly what changed and why. A human reviews the diff (checkpoint gate). Only after approval does the harness deploy the changes through the normal CI/CD pipeline.

This pattern works because it preserves the existing deployment safety mechanisms. The harness does not replace your CI/CD. It feeds into it. The agent accelerates the creation of changes. The harness ensures those changes pass through the same quality gates as human-authored code.

The "budget and burn" pattern

Used for agents with API access (search agents, data enrichment agents, customer support agents). The harness assigns a budget: number of API calls, tokens consumed, or wall-clock time. The agent executes freely within the budget. When the budget is exhausted, execution terminates and results are presented as-is.

This prevents runaway costs and runaway execution. A 2025 incident at a well-funded startup (reported in an Hacker News postmortem) involved an AI agent that consumed $14,000 in API credits in four hours by recursively calling a search API to "gather more context" for an ambiguous query. A budget harness with a $50 cap would have limited the damage to $50.

The "shadow mode" pattern

Used for high-stakes domains (financial services, healthcare, legal). The agent runs in parallel with a human operator. The agent produces its outputs. The human produces their outputs independently. The harness compares them. Discrepancies are logged and analyzed.

Over time, as the agent's outputs converge with human judgment, the harness can shift from shadow mode to suggestion mode (agent suggests, human approves) to autonomous mode (agent executes, human reviews asynchronously). This graduated autonomy is how you build trust in high-stakes systems without accepting high-stakes risk during the trust-building phase.

The product engineer's advantage in harness design

The reason harness engineering belongs to the product engineer and not to a specialized "AI safety team" is that harness design is fundamentally a product decision. Every harness configuration represents a tradeoff between speed and safety, between autonomy and control, between capability and risk.

Those tradeoffs cannot be evaluated in isolation from the product context. A harness that is perfectly calibrated for a code generation tool is catastrophically wrong for a medical diagnosis assistant. A harness that is appropriate for an internal developer tool is insufficient for a customer-facing agent handling financial transactions.

The product engineer understands:

• What the user needs the agent to accomplish (determines minimum capability)
• What failure looks like from the user's perspective (determines risk tolerance)
• What the business can absorb in terms of incidents (determines safety margins)
• What competitors demand in terms of speed (determines autonomy level)

Nobody else at the table holds all four of those perspectives simultaneously. This is why harness engineering is a product engineering discipline, not a pure infrastructure concern.

Building your first AI harness: a practical sequence

If you are starting from zero, here is the sequence I recommend based on having shipped agent systems at AWS and coached teams through their first production deployments.

1. Enumerate all agent actions. List every tool call, API request, file operation, and side effect your agent can produce. Be exhaustive. If you miss an action, it runs unharness'd.

2. Classify by reversibility. For each action, answer: if this goes wrong, how hard is it to fix? Read operations are always reversible (they change nothing). File writes are usually reversible (git reset). Database schema changes are hard to reverse. Emails sent to customers are irreversible.

3. Assign control levels. Based on reversibility: auto-execute (reversible), log-and-execute (moderately reversible), checkpoint (hard to reverse), block (irreversible without human).

4. Implement the permission layer. Code the allow/deny rules. This is your first line of defense and the most important to get right.

5. Add observation. Instrument the harness to emit structured events for every action taken. You will need this data to calibrate checkpoints later.

6. Deploy in shadow mode. Run the harness alongside your existing process. Do not give the agent real execution power yet. Observe. Learn. Calibrate.

7. Graduate to production. Once shadow mode demonstrates acceptable behavior patterns (typically 2-4 weeks), enable real execution with all checkpoint gates active.

This sequence is deliberately slow. When the downside of moving fast is a production incident, moving slowly is the faster path to value.

The future of the AI harness

Harness engineering is young. The patterns are stabilizing, but the tooling is still primitive. Today, most teams build custom harnesses from scratch. By 2027, I expect harness frameworks to be as common as web frameworks. You will not build a production agent system without one, just as you would not build a production web app without a framework.

The teams that master harness engineering now will have a compound advantage. Every week of operating a production harness generates calibration data. That data makes the harness more precise: fewer unnecessary checkpoints, tighter boundaries that still allow maximum useful autonomy, better anomaly detection from richer behavioral baselines.

Notion's AI team described this effect in a 2025 engineering blog post: after six months of harness operation, their checkpoint approval rate exceeded 97%, meaning humans approved 97% of gated actions without modification. The harness had learned (through calibration, not ML) exactly which actions genuinely needed human review and which were being gated unnecessarily. Their agent velocity increased 3x without any reduction in safety, purely from harness calibration.

That 3x improvement is available to every team willing to invest in the harness early.

Key takeaways

• Harness engineering builds architectural constraints outside the model's reasoning so agents cannot circumvent safety rules.
• Even top models violate explicit system prompt constraints 4-7% of the time in multi-step tasks, making prompt-only safety insufficient.
• The four harness layers are action classification, scope boundaries, checkpoint gates, and continuous observation.
• Start restrictive, then expand permissions based on observed behavior; target an 85-95% checkpoint approval rate.
• Harness design is a product decision because it balances speed, safety, autonomy, and user needs simultaneously.

FAQ

What is harness engineering in AI systems?

Harness engineering is the practice of designing constraints, checkpoints, and control surfaces that wrap AI agents, allowing them to operate with useful autonomy while preventing dangerous or irreversible actions. The harness operates at the system level, outside the model's reasoning process, providing enforcement that cannot be circumvented by the agent's own decision-making.

How is an AI harness different from prompt engineering?

Prompt engineering tells the agent what to do through instructions in its context window. A harness enforces what the agent can do through architectural constraints outside the model's control. Prompts can be misinterpreted or ignored (4-7% failure rate in multi-step tasks). Harness constraints cannot be reasoned around because they operate at the execution layer, not the reasoning layer.

Do I need a harness if my agent is only used internally?

Yes. Internal agents can still cause significant damage: deleting production data, consuming excessive API credits, modifying infrastructure configuration, or leaking sensitive information across team boundaries. The harness should be calibrated differently for internal vs. external agents (internal harnesses can be less restrictive), but eliminating the harness entirely for internal use is a common mistake that leads to incidents.

What is the relationship between harness engineering and context engineering?

Context engineering determines what information the agent reasons with. Harness engineering determines what actions the agent can take regardless of its reasoning. They are complementary disciplines. Context engineering improves the quality of the agent's decisions. Harness engineering limits the consequences of bad decisions. Production systems need both.

How restrictive should a production harness be?

Start more restrictive than you think necessary, then calibrate based on observed behavior. The key metric is your checkpoint approval rate: if humans approve more than 95% of gated actions without modification, your harness is probably too restrictive and should be loosened. If the approval rate drops below 80%, your harness may be too permissive. Target 85-95% approval rate for optimal balance between speed and safety.

Related reading

• What Is a Product Engineer? - The foundational role definition for engineers who own outcomes, not just outputs
• Agentic Engineering: Working With AI, Not Just Using It - How product engineers design systems for human-agent collaboration
• Context Engineering: The Skill That Replaced Prompt Engineering - The discipline of structuring information environments for AI agents
• The Multi-Agent Architecture That Actually Ships - Production patterns for coordinated agent systems
• How to Become a Product Engineer - The career path for engineers who want to own the full stack and the full outcome