01
Context assembly
Harness Engineering decides which files, rules, history, language preferences, and external tool instructions enter the model context instead of dumping everything into one prompt.
Production AI field delivery
AI FDE Field Engineering
Go deeper into the systems and judgment behind dependable AI delivery. Study how an FDE Engineer connects customer discovery, agent harness design, tools, permissions, memory, evals, production rollout, and adoption—and challenge a real deployment plan with the AI FDE Field Mentor.
Context assemblyTool contractsPermission policy
core model
Five layers of Harness Engineering
A reliable agent is not just a model. Harness Engineering breaks intent, context, tools, permissions, memory, execution, and verification into observable engineering layers so the model guesses less and the product explains more.
02
Tool contracts
In Harness Engineering, tools are governed product APIs with input schemas, output budgets, concurrency markers, read-only markers, and failure semantics.
03
Permission policy
Harness Engineering turns allow, ask, deny, and risk explanations into structured decisions instead of trusting the model to be careful.
04
Memory and Skills
Harness Engineering loads durable rules, project memory, and domain skills only when they are relevant, reducing prompt bloat while keeping sources traceable.
05
Execution loop
Long tasks need planning, tool calls, streaming feedback, compaction, recovery, and verification evidence. Harness Engineering is the runtime chain around that work.
source-backed notes
Claude Code source lessons for Harness Engineering
I read the key Claude Code source paths and distilled six reusable Harness Engineering design points. They are not abstract slogans; they are engineering boundaries visible in the source.
constants/prompts.ts
Prompt as context pipeline
The source separates static sections, dynamic sections, memory, environment data, language settings, MCP instructions, and cache boundaries. Harness Engineering turns prompt text into a cache-aware context pipeline.
Tool.ts + tools.ts
Tools as product APIs
The Tool interface carries call, description, schema, isReadOnly, isConcurrencySafe, isDestructive, and checkPermissions. Harness Engineering makes model capability reviewable before it touches the world.
types/permissions.ts
Permission as decision data
Permission types separate modes such as default, plan, acceptEdits, dontAsk, and bypassPermissions from allow, ask, deny, and passthrough results. Harness Engineering gives authority reasons and next steps.
skills/loadSkillsDir.ts
Skills as progressive disclosure
Skills are estimated and routed from frontmatter first; the full instruction loads only when a task matches. Harness Engineering keeps domain knowledge discoverable without bloating every turn.
services/mcp/config.ts
MCP and plugins need governance
MCP config computes server signatures, deduplicates plugin servers, and respects disabled or policy-filtered servers. Harness Engineering governs external capability before exposing it to an agent.
query.ts
Long work needs context lifecycle
Before model calls, query.ts applies tool-result budgets, snip, microcompact, context collapse, and autocompact. Harness Engineering is not only a bigger context window; it is context lifecycle management.
learning document
Why learn Harness Engineering
Prompt engineering asks what to tell the model. Harness Engineering asks what system the model should run inside. When an agent works with real code, real permissions, real deployment, and team workflows, prompt text alone cannot guarantee reliability.
The Claude Code source shows how Harness Engineering moves stable rules into static prompt sections, volatile information into dynamic sections, and file reading, editing, search, MCP, Skills, and subtask work into governed tool contracts.
The goal of learning Harness Engineering is not to copy Claude Code. The goal is to decompose an AI product into context, tools, permissions, memory, loops, verification, and UX. That pattern transfers to support agents, data agents, content agents, and coding agents.
Harness Engineering learning path
1
Read the source boundaries
Start with prompts, Tool, permissions, skills, mcp, and query files to see where Harness Engineering creates runtime boundaries.
2
Draw the runtime model
Map one agent conversation as intent, context, tool, permission, result, compact, and verify.
3
Build a minimum harness
Implement three narrow tools, one permission decision object, one memory loader, and one verification step to feel how Harness Engineering reduces model freedom.
4
Evaluate with evidence
Do not judge only by a pleasant answer. Check tool logs, recovery behavior, permission explanations, tests, and whether the user can understand what happened.
AI Tutor
Challenge a production AI delivery plan
Hi, I am the AI FDE Field Mentor. Bring me a customer problem, scope, architecture, prototype, eval, security review, rollout plan, or adoption risk. I will separate facts from assumptions, make trade-offs explicit, and suggest the next field artifact to produce.
FAQ
Harness Engineering FAQ
These questions clarify how Harness Engineering relates to prompts, agent frameworks, and Claude Code source study.
What is Harness Engineering?
Harness Engineering is the engineering practice of building the operating environment around a model: context assembly, tool contracts, permission policy, memory, state, orchestration loops, verification, observability, and product UX.
How is Harness Engineering different from prompt engineering?
Prompt engineering optimizes the text the model sees. Harness Engineering designs the system the model runs inside. One asks how to phrase the instruction; the other asks how an agent reliably acts in the real world.
Why study Harness Engineering through Claude Code?
Claude Code is a real coding agent whose source shows prompt pipelines, tools, permissions, MCP, Skills, memory, and long-task compaction, making it a strong Harness Engineering case study.
What can the AI source tutor help with?
The tutor can explain source files through a Harness Engineering lens, compare tool and permission design, or translate Claude Code patterns into your own agent product plan.
When does a team need Harness Engineering?
A team needs Harness Engineering whenever an agent reads or writes real systems, calls external tools, remembers durable rules, asks for approval, or must deliver verifiable outcomes rather than just a friendly answer.