Everything Agents

Lesson 2 of 14 · 7 min

The six components: E, T, C, S, L, V

Every harness implements six runtime functions: Execution loop, Tool registry, Context manager, State store, Lifecycle hooks, and Evaluation interface. Six failure modes map one-to-one.

The cleanest formal definition of a harness comes from Meng et al.'s 2026 survey of 22 production agent systems. They define a harness as the six-tuple:

H = (E, T, C, S, L, V)

Each letter is a runtime function. Each one corresponds to a specific failure mode you've probably hit if you've used any agent for more than ten minutes.

Harness anatomy: six components around the modelThe model sits in the center. The execution loop E wraps everything. Context manager C and state store S sit above the model: what the model sees and what survives between turns. Tool registry T sits to the right: the surface that touches the world. Lifecycle hooks L and the evaluation interface V sit below: interception and standardized trajectory capture.E: execution loopmodelLLMC: context managerwhat the model seescompaction · retrieval · orderingS: state storewhat survives the turnfiles · git · long-term memoryT: toolstouches the worldbash · edit · grep · MCPL: lifecycle hooksintercept every callauth · audit · policyV: evaluationstructured trajectoriesfor downstream judges

What each one does

Explore the six components

Click any letter. Each one has a function, a failure mode, and a place where it lives in Claude Code.

E

Execution loop

Observe → think → act → commit. Termination, error recovery.

Function
Sequences turns. Decides when to stop. Recovers from tool errors instead of crashing or looping forever. Without E there is no multi-step execution at all.
Failure mode
Execution runaway: loops that never terminate, no error-recovery arc.
Where it lives in Claude Code
The Claude Code agent loop itself. The bit you don't see: the code that hands the model output back to a tool dispatcher, catches errors, and decides whether to keep going.
In the surveyed 22 systems
All real harnesses. Necessary by definition.

Source: Meng et al., An Open and Critical Survey of Agent Harnesses, 2026 (§2.2).

How to read the six

Two of these are necessary by definition: a system without E has no multi-step execution, and a system without T can't touch the world. The survey calls these "any system that qualifies as a harness."

Two of them are heavily implemented across the field: C (context managers got a whole engineering era named after them in 2025) and S (every production system has some notion of what survives a turn, even if just "the conversation history").

The interesting part is the other two. L and V, lifecycle hooks and the evaluation interface, are the most systematically under-implemented components across the surveyed 22 systems. (source: 2604.agent-harnesses-survey.pdf §2.2)

That gap matters because:

  • Without L, an agent can send emails or run shell commands and no central code records that it happened. Audit, policy, and rate-limiting get bolted on per-tool instead of once.
  • Without V, you can read the logs but you can't score them. Comparing two harnesses means re-running both. Automated harness optimization (lesson 12) is impossible.

The failure modes map one-to-one

This is the most useful frame in the whole topic. Every component has a principal failure mode. If you can name which mode you're seeing, you know which component is at fault.

Six components, six failure modesA 2 by 3 grid pairing each of the six harness components with its principal failure mode. Execution loop with execution runaway, tool registry with tool misuse, context manager with context blowout, state store with state loss, lifecycle hooks with unmonitored side effects, and evaluation interface with unobservable behavior.Eexecution loopcomponentfailure modeexecution runawayTtool registrycomponentfailure modetool misuseCcontext managercomponentfailure modecontext blowoutSstate storecomponentfailure modestate lossLlifecycle hookscomponentfailure modeunmonitored side effectsVevaluationcomponentfailure modeunobservable behavior

We'll spend a whole lesson on these in lesson 8, with the actual fixes. For now, what matters is the structure: when something goes wrong with an agent, the question to ask first is which of the six.

What this is not

The six-tuple is a description of runtime functions, not a software architecture. A real harness might implement E and T as one while loop with a switch statement, or it might split them into three separate processes communicating over IPC. The components are roles, not files.

Two other formalizations cut the same space differently:

  • AHE's seven NexAU components (system prompt, tool description, tool implementation, middleware, skill, sub-agent config, long-term memory) are an implementation taxonomy at finer granularity. Tools/middleware ≈ T/E, skills + memory ≈ C/S, sub-agent config extends E. (source: 2604.auto-evolution-coding-agents.pdf)
  • Natural-language harnesses describe contracts, roles, stages, adapters, state semantics, and a failure taxonomy. Closer to a spec language than to a component taxonomy. We'll meet this in lesson 11.
  • Externalization (Zhou et al.) cuts orthogonally: memory externalizes state across time, skills externalize procedural expertise, protocols externalize interaction structure, and the harness coordinates all three. Memory ≈ S, skills ≈ part of C and T, protocols ≈ T's typed contracts. The point isn't a different taxonomy; it's a different question, namely what burden does each component move out of the model? (source: 2604.externalization-llm-agents.pdf, §1 and §6)

The six-tuple is the most parsimonious frame, which is why we use it throughout this topic.

Quick check

Which two components are systematically under-implemented across surveyed harnesses?