Skip to main content
reopt Handbook
reopt Handbook
Harness Engineering

Problem and Structure

Foundations of Harness EngineeringRepo-Readable SystemsThe Five Elements of a HarnessEngineering Mechanics

Evaluation and Interpretation

Evaluation Loop DesignExternal Case Comparison

Case Studies

Case: OpenAICase: AnthropicCase: TossCase: gstackCase: revfactory/harness

Domain Playbooks

Domain PlaybooksScenario: Frontend TeamScenario: Platform TeamScenario: Payments and Settlement TeamScenario: AI Product TeamWhy You Eventually Need Your Own Harness

Rollout and Operations

Team Harness Rollout StrategyTeam Harness Design ChecklistOperations: Entropy and Garbage Collection

Appendix

Verification ReportUpdates
Handbook›Harness Engineering
한국어English

Harness Engineering

A practical guide to harness design, evaluation, and operations based on OpenAI, Anthropic, Toss, gstack, revfactory, Agents SDK, and Managed Agents patterns

Recently Updated Chapters

  • Case: Anthropic2026-06-13

    Analyze Anthropic's long-running harness through planner/evaluator, Managed Agents, and auto approval patterns.

  • Case: gstack2026-06-13

    Read gstack as an opinionated multi-host workflow harness with specialists, power tools, QA, checkpointing, and release gates.

  • Case: OpenAI2026-06-13

    Analyze OpenAI's harness view through repo-readability, observability, sandboxing, runtime surface, and cleanup.

  • Case: revfactory/harness2026-06-13

    Read revfactory/harness as a meta-harness for generating domain-specific team architectures, agents, and skills.

  • External Case Comparison2026-06-13

    Compare OpenAI, Anthropic, Toss, gstack, and revfactory/harness by input, state, verification, and rollout.

Harness engineering is not about writing a better prompt. It is the practice of designing the work environment that lets agents operate for longer, larger, and riskier tasks.

Teams using the same model and the same IDE can see very different outcomes because their context structure, verification loop, approval boundary, documentation quality, and tool access differ.

Core Thesis

Generic harnesses are useful starting points, but performance depends on how explicitly your team externalizes domain rules, operating criteria, and runtime boundaries.

English Edition

This edition translates and localizes the Korean handbook for platform, AgentOps, and developer productivity teams standardizing AI coding agents across repositories.

Source Map

SourceQuestion this handbook takes from itSummary
OpenAI Harness EngineeringWhere does the agent work?The repository, docs, browser, logs, and cleanup loop are part of the harness
OpenAI Agents SDK / Codex updatesWhich harness primitives are becoming product surfaces?MCP, skills, AGENTS.md, sandbox, shell, apply_patch, hooks, and plugins are becoming common infrastructure
Anthropic harness / Managed Agents / auto modeHow is an agent verified, isolated, and approved?Separate planner/evaluator, session, harness, sandbox, and permission classifier boundaries
Toss harness articleHow does a harness roll out to a team?Personal habits must become executable SSOT and workflow
gstackHow does a harness become a workflow across many agent hosts?Think -> Plan -> Build -> Review -> Test -> Ship -> Reflect becomes a command surface
revfactory/harnessHow can harness design become repeatable?Domain analysis generates agent teams, skills, and validation loops

Where Harness Begins

Questions This Book Answers

  • How is harness engineering different from prompt engineering and context engineering?
  • What elements make a harness effective?
  • Why are inputs, state, verification, and permissions engineering concerns?
  • What do OpenAI, Anthropic, Toss, gstack, and revfactory each emphasize?
  • How do Agents SDK, Managed Agents, sandboxing, MCP, skills, hooks, and plugins change team design?
  • Why should teams converge toward their own harness instead of copying someone else's?
  • What order should a team use to design, roll out, and operate a harness?

Who This Is For

ReaderWhat you get
AI coding agent adoption leadA way to turn personal tricks into a team system
Codex, Claude Code, Cursor, or agentic IDE userA view beyond tool usage into work-environment design
AgentOps or platform engineerAn operating frame for evaluation, approval, observability, and docs
Team defining internal AI standardsA method for executable SSOT and common workflows

Five-Minute Diagnostic

Current painStart here
Same model, very different team outcomesfoundations -> engineering-mechanics
Lots of prompts, weak repeatabilityfive-elements -> engineering-mechanics
Review and QA catch problems too lateevaluation-loops -> case-anthropic
Copied an external harness and it does not fitcase-studies -> make-it-yours
Docs, approvals, and browser checks are disconnectedcase-openai -> checklist

Maturity Map

Recommended Paths

GoalReading path
Understand the concept quicklyfoundations -> engineering-mechanics -> five-elements
Compare external examplescase-studies -> case-openai -> case-anthropic
Apply it to a frontend teamdomain-playbooks -> scenario-frontend-team
Build platform or monorepo rulesdomain-playbooks -> scenario-platform-team
Manage payments or settlement riskdomain-playbooks -> scenario-payments-team
Operate AI product evaluation and rolloutdomain-playbooks -> scenario-ai-product-team
Roll out to a teamcase-toss -> team-rollout
Study workflow and release gatescase-gstack -> operations
Study meta-harness generationcase-revfactory -> make-it-yours

Contents

Ch1. Foundations

Define harness engineering and separate it from prompt and context engineering.

Ch2. Repo-Readable Systems

Make AGENTS.md, docs, observability, and executable SSOT part of the work environment.

Ch3. The Five Elements

Environment, roles, criteria, loops, and maintenance.

Ch4. Engineering Mechanics

Treat inputs, state, tools, evaluation, approval, sandboxing, and cleanup as system design.

Ch5. Evaluation Loops

Decide when planner, builder, evaluator, and QA should be separated.

Ch6. Case Comparison

Compare OpenAI, Anthropic, Toss, gstack, and revfactory on the same axes.

Ch7. OpenAI

Repo-readable systems, Agents SDK harnesses, sandboxing, observability, and cleanup.

Ch8. Anthropic

Load-bearing scaffolding, managed runtime, and auto approval classifier boundaries.

Ch9. Toss

Frictionless harnesses, executable SSOT, and domain HITL.

Ch10. gstack

A strong opinionated workflow across many AI coding agent hosts.

Ch11. revfactory/harness

Harness generation as a team architecture process.

Ch12. Domain Playbooks

Translate harness design into frontend, platform, payments, and AI product contexts.

Appendix. Verification Report

Source, structure, and build verification baseline.

Appendix. Updates

Track interpretation changes and source evidence.

Related Handbooks

Recommended Cross-Reads

  • /en/books/llmops-agentops: production operations for AI systems
  • /en/books/codex-advanced, /en/books/claude-code-advanced: tool-specific implementation practices
  • /ko/books/agent-orchestration-patterns: multi-agent design patterns (Korean)

Related handbooks

Agentic Documentation

A practical guide to documentation that AI agents can read, execute, verify, and govern.

Developer Unlearning

Engineering habits to drop, retain, and rebuild for the agentic coding era.

Enterprise Eve Agent Development

A practical enterprise handbook for building high-quality durable AI agents with Vercel Eve, based on Eve 0.11.4 source and the full official docs corpus.

LLMOps and AgentOps in Production

A production operating system for turning experimental AI features into reliable services

Foundations of Harness Engineering

Define harness engineering, its scope, and why system design matters more than prompt wording for long-running agents.

On this page

Source MapWhere Harness BeginsQuestions This Book AnswersWho This Is ForFive-Minute DiagnosticMaturity MapRecommended PathsContentsRelated Handbooks