$npx -y skills add keli-wen/agentic-harness-patterns-skill --skill agentic-harness-patternsHarness patterns for coding agents — memory, permissions, context engineering, delegation, skills, hooks, bootstrap.
| 1 | # Agentic Harness Patterns |
| 2 | |
| 3 | Production AI coding agents are not just an LLM calling tools in a loop. The **harness** — memory, skills, safety, context control, delegation, and extensibility — is what separates a demo from a production system. |
| 4 | |
| 5 | **For:** Engineers building or extending coding-agent runtimes, custom agents, or advanced multi-agent workflows. |
| 6 | **Not for:** Prompt engineering, model selection, generic software architecture, or LLM API basics. |
| 7 | |
| 8 | All principles are distilled from production runtime decisions. Claude Code is used as grounding evidence, not as the only possible implementation. |
| 9 | |
| 10 | ## Choose Your Problem |
| 11 | |
| 12 | | If you want to... | Read | |
| 13 | |---|---| |
| 14 | | Make the agent remember and improve over time | [Memory](#1-memory) | |
| 15 | | Package reusable workflows and expertise | [Skills](#2-skills) | |
| 16 | | Let the agent use tools powerfully but not dangerously | [Tools and Safety](#3-tools-and-safety) | |
| 17 | | Give the agent the right context at the right cost | [Context Engineering](#4-context-engineering) | |
| 18 | | Split work across multiple agents without losing control | [Multi-agent Coordination](#5-multi-agent-coordination) | |
| 19 | | Extend behavior with hooks, background tasks, or startup logic | [Lifecycle and Extensibility](#6-lifecycle-and-extensibility) | |
| 20 | |
| 21 | **Before you start building:** Read the [Gotchas](#gotchas) — these are the non-obvious failure modes that cost the most time. |
| 22 | |
| 23 | --- |
| 24 | |
| 25 | ## 1. Memory |
| 26 | |
| 27 | **User problem:** "My agent forgets corrections and project rules between sessions." |
| 28 | |
| 29 | **Golden rule:** Separate what the agent *knows* (instruction memory) from what the agent *learns* (auto-memory) from what the agent *extracts* (session memory). Each layer has different persistence, trust, and review needs. |
| 30 | |
| 31 | **When to use:** Any agent that operates across multiple sessions or needs to accumulate project-specific knowledge over time. |
| 32 | |
| 33 | **How it works:** |
| 34 | |
| 35 | - **Instruction memory** is curated, hierarchical configuration injected into system context in priority order (org-wide → user → project → local; local wins). This is where project conventions, coding standards, and behavioral rules live. It is human-authored and stable. |
| 36 | - **Auto-memory** is agent-written persistent knowledge with a type taxonomy (user / feedback / project / reference) and a capped index. Saving is two-step: write a topic file, then update the index. The cap prevents unbounded growth — without cleanup, recent entries silently disappear. |
| 37 | - **Session extraction** runs as a background agent at session end. It directly writes to auto-memory — topic file then index — following the same two-step save invariant. A mutual-exclusion guard ensures that if the main agent already wrote memory during the turn, the extractor skips entirely. This is the autonomous learning loop. |
| 38 | - **Review and promotion** audits across all memory layers and proposes cross-layer moves (auto-memory → project conventions, personal instructions, or team memory). It never applies changes autonomously — proposals require explicit user approval. |
| 39 | |
| 40 | **Start here:** Define your memory layers (instruction, auto, extraction). Implement the two-step save invariant (topic file, then index). Add background extraction only after the core write path is stable. |
| 41 | |
| 42 | > **In Claude Code:** Use `/remember` to audit and promote auto-memory entries across layers. |
| 43 | |
| 44 | **Tradeoffs:** |
| 45 | |
| 46 | - More memory layers = richer recall but higher maintenance burden. Without periodic pruning, index caps cause silent data loss. |
| 47 | - Session extraction adds latency at session end but dramatically improves cross-session learning. |
| 48 | |
| 49 | **Go deeper:** [references/memory-persistence-pattern.md](references/memory-persistence-pattern.md) |
| 50 | |
| 51 | --- |
| 52 | |
| 53 | ## 2. Skills |
| 54 | |
| 55 | **User problem:** "I want my agent to reuse workflows and domain knowledge without re-explaining them every time." |
| 56 | |
| 57 | **Golden rule:** Skills are lazy-loaded instruction sets, not eagerly injected prompts. Discovery must be cheap (metadata only); the full body loads only on activation. |
| 58 | |
| 59 | **When to use:** Any agent that needs reusable, composable workflows activating on matching user intent. |
| 60 | |
| 61 | **How it works:** |
| 62 | |
| 63 | - **Discovery** is budget-constrained: the agent sees a compact listing of all available skills (name, description, and when-to-use hint concatenated per entry), each hard-capped at a fixed character limit, with the total capped at roughly 1% of the context window. Front-load your trigger language — tails get truncated. |
| 64 | - **Loading** is lazy: only metadata enters the always-on context. The full skill body loads only when the skill activates, k |