2. The Nine Components
These nine components appear across Claude Code, Anthropic SDK, OpenAI Agents SDK, LangGraph, AWS Bedrock AgentCore, and Factory.ai Missions. No single tool implements all nine in exactly the same way, but the structure is consistent enough to use as an evaluation checklist when assessing a harness against a new tool or framework.
2.1 While-Loop Engine
The main loop: perceive (read context, tool outputs, latest user instruction), plan (call LLM with assembled prompt), act (execute tools). This is the heartbeat. Anthropic SDK, OpenAI Agents SDK, and LangGraph implement it differently (Anthropic is streaming-first, LangGraph is graph-based), but all three have this loop as the core abstraction.
Where problems emerge: loops that don't cap iterations, loops that don't handle LLM refusals or ambiguous tool calls, loops that let the context grow without summarization until they hit the window limit and abort.
Three loop horizons
A useful practitioner model separates three feedback horizons. The terms are not a formal standard, but they expose where a correction should become durable.
| Horizon | Boundary | Typical controls | Where it usually lives |
|---|---|---|---|
| Inner loop | One agent run | Tool results, targeted tests, skills, local checks | Runtime plus repository harness |
| Outer loop | Task or pull request | Agentic QA, full test suites, deeper review, independent verifiers | Repository harness plus CI |
| Meta loop | Across many runs | Failure mining, recurring review analysis, harness search, rule and verifier updates | Team process, optimizer, or meta-harness |
The AI Native DevCon interview on harness engineering describes the inner loop as fast feedback while the agent works, the outer loop as slower checks around the pull-request boundary, and the meta loop as continuous improvement across failures. This model turns repeated human correction into a maintenance signal. A review comment that recurs should become a test, rule, skill, hook, or verifier at the earliest loop that can catch it.
Build one bounded loop before adding autonomous layers. In a 2026 context-engineering interview, Dex Horthy describes a lights-off software factory that removed human testing and review, accumulated failures, and was shut down. That is a practitioner retrospective, not a controlled study, but it identifies a concrete failure mode: autonomy expanded faster than verification and recovery.
The meta loop can now be automated. Meta-Harness searches harness code using prior source, scores, and execution traces. Agentic Harness Engineering represents editable components as files and couples every change to a prediction that the next evaluation can falsify. Automation does not remove the need for held-out tests or budgets. It makes those boundaries more important.
2.2 Context Management
What goes into the prompt on each loop iteration: conversation history, tool outputs, retrieved memory, current task state, rules from CLAUDE.md. The challenge is that context is finite and expensive. Strategies:
- Compaction / summarization: replace earlier turns with a compressed summary. Claude Code compacts automatically near its context threshold and also exposes
/compactfor an explicit compaction.PreCompactandPostCompacthooks let teams inspect or react to that boundary. - Sliding window: keep the last N turns verbatim, summarize everything before.
- Retrieval-augmented context: retrieve relevant chunks from long-term storage rather than carrying everything in the window.
The ACE pipeline (see context-engineering.md §6) is the Config-Persistence layer above context management: it governs what rules and skills are loaded across sessions.
Agentic Context Engineering treats context as an evolving playbook rather than a repeatedly rewritten summary. The paper reports gains of 10.6% on agent benchmarks and 8.6% on finance tasks through incremental generation, reflection, and curation. Cite those as method results, not proof that adding more context is better. The operational principle is smaller: preserve useful detail, attach feedback to an inspectable artifact, and test the evolved context against held-out tasks.
Context beyond the repository
Repository files are only one source of truth. Product decisions may live in Linear, interface constraints in Figma, component behavior in Storybook, and operational history in incident systems. Marc Sloan's 2026 talk on product and design constraints argues that this external context must become accessible to the agent without silently drifting away from its source.
| Access pattern | Strength | Failure mode |
|---|---|---|
| Live tool or MCP access | Fresh data and direct attribution | Availability, permission, and prompt-injection risk |
| Versioned repository snapshot | Reproducible and reviewable with the code | Snapshot can become stale |
| Synchronization bridge | Combines freshness with a local artifact | Sync failures can create two conflicting truths |
Record the source, retrieval time, and freshness expectation for external context. If an agent cannot tell whether a design decision is current, the context builder has moved uncertainty into the prompt instead of resolving it.
2.3 Tool Registry
The catalog of available tools: name, schema, description, permissions, cost estimate. A static tool registry loads all tool schemas on every call. A dynamic registry ("tool search on demand") loads only what the current task plausibly needs.
Anthropic's internal data (cited in the Fowler article, source: practitioner post) cites a 37% reduction in token usage from dynamic tool dispatch versus static loading. This number is not independently replicated, but the directional claim is credible: giving the model 40 tool schemas when it needs 4 adds noise and cost.
For sensitive MCP (Model Context Protocol) tools, put authentication and authorization at the execution boundary. An identity-aware gateway is one production pattern, but it is not a default property of MCP or Claude Code. The required control depends on the tool's data, side effects, and deployment model. See MCP Servers Ecosystem and Security Hardening.
2.4 Sub-Agent Management
Delegation to specialized sub-agents with their own context windows and task scope. The orchestrator spawns a worker, provides a bounded task description, and receives a structured result. The worker does not share the orchestrator's full context; it receives only what it needs.
Factory.ai Missions formalizes this: an orchestrator agent decomposes requirements, delegates implementation to workers, and routes completed work to adversarial validator agents. On a documented Slack clone project, independent validators caught 81 problems before any code was merged, generating 34% of the implementation work as "fix features."
Claude Code subagents inherit the parent session's permission mode by default. That is runtime behavior, not proof of least privilege. Narrow each agent with tools, disallowedTools, and permissionMode, and use isolation: worktree when parallel writers must not share a checkout. See Tools Reference, Agent Teams, and the worktree isolation definition.
2.5 Native Tools and Loadable Skills
Claude Code exposes native tools for file access, search, shell execution, web access, delegation, and other runtime operations. Skills are different: they are loadable instruction and resource modules invoked through the Skill tool. A skill can include scripts and deterministic checks, but the skill itself is not inherently deterministic because the model still interprets its instructions and chooses actions.
Test deterministic scripts and validators with ordinary assertions. Test the model-mediated part of a skill with behavioral tasks, expected boundaries, and human or calibrated evaluator review. The Tools Reference documents the runtime tool surface; the skills examples show the separate packaging model.
2.6 Session Persistence
State that survives context resets and session interruptions. Not the same as long-term memory (which is a higher-level concept). Persistence at the harness level means: the agent can reconstruct its current task state from externalized artifacts rather than from the in-context conversation history.
Factory.ai Missions uses a shared artifact layer (validation contracts, feature lists, skill definitions) to survive the context limits of multi-day missions. E2B and Northflank provide this at the infrastructure level via persistent sandbox state. Anthropic Claude Managed Agents provide it as a product feature with checkpointing.
2.7 Dynamic Prompt Assembly
The step that turns the current state (task description + relevant context + tool definitions + memory + rules) into the actual prompt sent to the LLM. This is not standardized across frameworks. LangChain, LangGraph, and the Anthropic SDK each have different abstractions.
The places where assembly goes wrong: rule injection that conflicts with the user instruction, tool schemas that overlap in ways that confuse the model's selection, memory retrieval that surfaces outdated context. Harnesses that make assembly visible (logging the final assembled prompt, not just the response) are dramatically easier to debug.
Ryan Lopopolo's 2026 harness-engineering talk frames the repository as an environment that must make the team's standard of good work legible and surface the right context just in time. The operational test is simple: if the same review feedback appears twice, decide whether it belongs in a formatter, linter, test, architecture decision record, skill, or verifier. Prompt text is only one possible control.
2.8 Lifecycle Hooks
Injection points that fire at defined runtime events. Claude Code does not expose generic pre-LLM and post-LLM hooks. Its event model includes instruction loading, permission requests, tool use, compaction, subagent and teammate lifecycle, worktree changes, session lifecycle, and failure events. The exact list and blocking semantics live in Hooks Events Reference.
Hooks are where you insert observability instrumentation, permission validation, rate limiting, output sanitization, and audit logging. Only events with documented blocking semantics can stop an action. Async hooks are appropriate for telemetry that does not need to interrupt the loop.
2.9 Permission Enforcement
Every consequential action needs an enforcement boundary before execution. Depending on risk, that boundary can combine explicit approval, permission rules, sandboxing, network policy, scoped credentials, and post-execution verification. Human review remains useful for high-impact decisions, but repeated approval prompts are not a complete isolation strategy.
Two useful structural mechanisms are:
Sandbox isolation: the agent runs in an environment where destructive actions are physically impossible, not just disallowed by policy but literally impossible given the network, filesystem, and process constraints. Kubernetes agent-sandbox, E2B microVMs, and Northflank BYOC runners implement this at the hardware level.
Identity gateway: sensitive tool calls are authenticated at call time with a scoped session credential rather than a broad static API key. Strata Maverics and Microsoft Entra Agent ID implement this pattern with OAuth OBO (On-Behalf-Of) flows that scope permissions to the current task context.
Claude Code now supplies additional primitives for this layer: sandbox.network.strictAllowlist denies non-allowlisted sandbox traffic without prompting, worktree isolation separates concurrent edits, and --restricted removes command and code execution plus WebFetch unless explicitly restored. These controls reduce exposure, but they do not establish that every MCP integration uses per-session identity or that every action is sandboxed.
A 2026 interview with Claude Code creator Boris Cherny describes the permission system as a layered combination of classifiers, static analysis, pattern allowlists, conservative defaults, and a human decision when the system is unsure. This is useful design rationale from a product creator. Current behavior still needs to be checked against official documentation and the Claude Code release history.
Claude Code implementation checkpoint
The nine-component model is product-independent. The table below maps it to Claude Code behavior through v2.1.250 without turning this page into a second release log.
| Harness concern | Current Claude Code mechanisms | Release evidence |
|---|---|---|
| Context and state | Automatic and explicit compaction; PreCompact and PostCompact hooks; automatic memory | v2.1.247, v2.1.105, v2.1.76, v2.1.59 |
| Tool and prompt assembly | Deferred tool loading, alwaysLoad MCP option, InstructionsLoaded hook | v2.1.121, v2.1.69 |
| Delegation | Background subagents, inherited permission mode, concurrency and nesting limits, conversation forking, prompt-cache inheritance | v2.1.198, v2.1.212, v2.1.217, v2.1.219, v2.1.232 |
| Isolation and policy | Worktree isolation and later hardening, strict network allowlist, --restricted launch mode | v2.1.49, v2.1.50, v2.1.222, v2.1.219, v2.1.248 |
| Recovery and coordination | Cross-session messaging, per-agent cache TTL, subagent model fallback | v2.1.224, v2.1.248, v2.1.247 |
| Inspection and control | Permission, tool, compaction, instruction, failure, agent, teammate, and worktree hook events | v2.1.69 to v2.1.219 |
Use the human-readable release history for interpretation and claude-code-releases.yaml for version-level lookup. reference.yaml provides stable topic routes into this page and the surrounding guide.