agentic-harness-patterns-skill: Harness Engineering Notes Distilled from Claude Code

The gap this repository targets sits outside the model loop

The README states the premise directly: the loop of user to LLM to tool_use to execute and back fits on a napkin, and everything that makes a production agent work sits around it. The repository names that surrounding layer the harness, following Anthropic's usage, and lists what it contains in its own words: memory that persists across sessions, permissions that fail closed, context budgets that do not explode, multi-agent coordination, and extensibility that does not become a security hole. The intended reader is an engineer building or extending a coding-agent runtime, a custom agent or plugin, a multi-agent orchestration system, or any production system where an LLM calls tools in a loop. The README is explicit about what the project is not: not a Claude Code user guide, not a prompt engineering tutorial, not an agents 101 introduction, and not a model selection guide. That negative list matters more than the positive one. If your question is which model to call or how to phrase a system prompt, this repository has nothing for you. If your question is where permission checks belong in the call path, or how much of a skill listing should occupy the context window, it does.

Six layers, each framed as a problem statement rather than an API

The core artifact is a skill file at skills/agentic-harness-patterns/SKILL.md, split into six numbered chapters. Memory addresses agents that forget between sessions, and the stated insight is to separate instruction memory (human-curated) from auto-memory (agent-written) from session extraction (background-derived), because each has different trust, persistence and review needs. Skills addresses re-explaining workflows every conversation, with the claim that discovery should cost roughly one percent of the context window and that trigger language belongs at the front of a description because tails get truncated. Tools and Safety covers the tension between powerful and dangerous tools, and asserts two things worth arguing with: concurrency is per-call rather than per-tool, and the permission pipeline has side effects, tracking denials, transforming modes and updating state. Context Engineering reduces the problem to four operations: select, write, compress, isolate. Multi-agent names three topologies (Coordinator with zero inheritance, Fork with full inheritance at a single level, and Swarm as a flat peer roster) and insists the coordinator must synthesize rather than delegate understanding. Lifecycle covers hooks, background tasks and startup, with the claim that hook trust is all-or-nothing and task eviction is two-phase. Each chapter follows the same internal shape: Problem, Golden Rules, Start Here, Tradeoffs, Gotchas, and Claude Code Evidence.

The reference documents are where the mechanism-level detail lives

Eleven reference files sit under skills/agentic-harness-patterns/references/, and their filenames are more concrete than the chapter titles. The memory reference covers a four-level instruction hierarchy, four auto-memory types, and background extraction with mutual exclusion. The skill-runtime reference covers four-source discovery, a YAML frontmatter contract, budget-constrained listing, and graceful degradation. The tool-registry reference names a fail-closed builder, per-call concurrency, and a partition-sort-concatenate step whose purpose is cache stability. The permission-gate reference describes a single gate with three behaviors, strict layered evaluation, and an atomic claim for race-safe resolution. The orchestration reference covers mutual exclusion of modes, fork cache optimization, flat swarm topology, and tool filtering layers. Context engineering is split into a routing index plus three sub-patterns: select (promise memoization, three-tier progressive disclosure, manual cache invalidation), compress (truncation with recovery pointers, reactive compaction, snapshot labeling), and isolate (zero-inheritance default, single-level fork boundary, worktree-based filesystem isolation). The README states each reference follows one structure: universal problem, portable golden rules, implementation patterns with no code, gotchas, then Claude Code evidence written in natural language. The absence of code is deliberate and it is also the main constraint on how you can use this material.

Installing it as a skill, and what npx skills add actually gives you

The README gives one install path: npx skills add, and states compatibility with the open agent skills ecosystem, naming Claude Code, Codex, and 40+ other agents. The badge links to vercel-labs/skills as the ecosystem reference. There are no releases retrieved for this repository, so installation is from the default branch, master, rather than a tagged version. That has a practical consequence: nothing in the material describes a versioning scheme, a changelog, or a pinned install, so a consumer cannot tell from the README which revision of the skill text they received. The repository is bilingual, with README.md in English and README_ZH.md in Chinese, and the description marks both EN and ZH. One further document is named, docs/distillation-harness-practice.md, described as a practice log covering how Codex and Claude Code collaborated during distillation, a PCA-inspired taste injection, and what worked and did not. That log is the closest thing to a methodology statement. If you are evaluating the patterns rather than just reading them, that file is the one that tells you how the extraction was done, and it is worth reading before you treat any single pattern as settled.

Every pattern is grounded in one codebase, and the README says so

The evidence base is stated without hedging: systematic source-level analysis of the Claude Code runtime, described as a 512,000-line TypeScript codebase. The README anticipates the obvious objection and answers it in a callout: patterns are expressed as portable, runtime-agnostic design principles, and Claude Code is used as grounding evidence rather than the only possible implementation. That is a reasonable position, but it is a claim about portability, not a demonstration of it. The material does not include an example of the same pattern implemented on a different stack, and it does not include measurements. So statements like discovery costing roughly one percent of the context window, or concurrency being per-call, arrive as assertions derived from reading one runtime. A second limitation is the format itself. The references are explicitly written with no code, so you cannot copy an implementation. You get vocabulary and decision structure, and you still write the code. A third: the roadmap lists Codex CLI and Gemini CLI but the README does not say they have been analyzed yet, so today the grounding is single-source.

If you want a runnable harness, this is the wrong artifact

The honest comparison is not against another pattern catalogue. It is against frameworks that ship the harness as code. LangGraph, for instance, gives you a graph abstraction with checkpointing and persistence you can execute, at the cost of adopting its execution model and its state semantics. This repository gives you no runtime, no interfaces, and no persistence layer. What it gives instead is the set of questions a framework tends to answer for you implicitly: which memory tiers exist and who is allowed to write to each, whether the permission gate fails closed, what the context budget is spent on before a skill body loads, and whether a subagent inherits its parent's context or starts empty. Those are exactly the decisions that are expensive to reverse once a framework has made them on your behalf. The trade is real in both directions. A framework gets you to a working loop faster and constrains your design space. A pattern document leaves the design space open and gets you to a working loop no faster at all, because you still have to build the thing.

Licence, maintenance and what a fork inherits

The repository is MIT licensed, which permits reuse, modification and redistribution provided the copyright notice and permission notice are retained. That is the standard reading, not legal advice, and anyone embedding the text in a commercial product or a training corpus should confirm the terms themselves. Maintenance cost is unusual for a project of this shape. There is no build, no dependency tree, and no runtime to upgrade, so the ordinary upgrade burden does not apply. The cost that does apply is drift. The patterns are distilled from a specific Claude Code codebase at a specific point, and the source runtime changes. Nothing in the supplied material describes a process for re-verifying patterns against later versions of Claude Code, and with no releases, there is no signal separating a re-verified pattern from an untouched one. The last push recorded is 2026-04-02. If you adopt these patterns into your own design docs, the maintenance work is yours: you own the re-check against whatever runtime you actually target.

Editorial conclusion

Adopt it if you are designing the layer around the model loop (memory tiers, permission gating, context budgets, delegation topology) and you want a checklist of decisions before you write code. Skip it if you need a runnable library, API reference, or benchmark data: the repository ships prose patterns, and its evidence base is one TypeScript codebase. Before relying on it, open skills/agentic-harness-patterns/SKILL.md and confirm that the six chapter headings and the Choose Your Problem table match the layer you are actually building.

Official sources

1. Issues
2. keli-wen/agentic-harness-patterns-skill on GitHub
3. License: MIT
4. README