ETCLOVG: The Seven-Layer Agent Harness Taxonomy, Mapped to a Production Runtime

Agent reliability is a property of both the model and the system around it. A 2026 survey by researchers from Carnegie Mellon, Yale, Amazon, and other institutions proposes ETCLOVG — Execution, Tooling, Context, Lifecycle, Observability, Verification, and Governance — as a taxonomy for that surrounding system, or agent harness.

The authors map more than 170 open-source projects to the seven layers and identify both mature areas and operational gaps. This post summarizes the taxonomy, then maps it to TrueFoundry's Agent Harness — separating native runtime capabilities from adjacent patterns and integrations.

Priyanka, a head of platform, had a reliability problem she couldn't name. Her teams ran five production agents, and when one misbehaved the post-mortems never agreed on what to fix. One blamed the model and lobbied for an upgrade. One rewrote the prompt. One added a retry. One wanted a sandbox. Each fix was plausible, each addressed a different layer, and none of them shared a vocabulary for saying which layer had actually failed — so the meetings circled. What Priyanka needed wasn't a better model or a louder opinion; it was a map: a way to point at an agent and say "this failure lives in lifecycle, not in the model" or "we have no verification layer at all." ETCLOVG is that map, and this post is the walk through it — first the taxonomy as its authors built it, then each layer against a production runtime, distinguishing native capabilities from adjacent workflows and integrations whether it calls them by these names or not.

1. Why a Harness Taxonomy Exists at All

The survey's central claim is deflationary toward models and inflationary toward infrastructure: the rapid deployment of LLM agents revealed that execution reliability depends less on the base model than on the harness that wraps it. The evidence is partly historical. The ReAct era of 2022–23 wrapped a single model loop in a while-loop, a prompt template, and a small tool-dispatch table; AutoGPT and BabyAGI then exposed the failure modes of that thin wrapper — execution runaway, context blowout, state loss, unmonitored side effects — as infrastructure problems rather than prompt problems. The years since have been the field slowly building the missing infrastructure and, only recently, naming it.

That naming is the survey's three-phase framing, which locates harness engineering precisely. Prompt engineering (2022–24): the lever is the input text, optimized for a single call. Context engineering (2025): the question shifts to "what should the model see at each step?" — retrieval, compaction, tool-result ranking, window saturation. Harness engineering (2026–): as models grow capable enough for long-running tasks, the focus expands to the whole infrastructure wrapper. Each phase subsumes the previous — harness includes context includes prompt — and they overlap rather than replace. ETCLOVG gives that third phase the architectural boundaries the first two never needed.

2. ETCLOVG, Layer by Layer

The taxonomy splits into a structural core and a control plane. E, T, C, and L are the structural pillars — they make an agent run. O, V, and G are the control plane — they make a running agent observable, evaluable, and safe. The survey's notable move is promoting Observability and Governance to independent layers rather than folding them into lifecycle hooks, on the grounds that in production each has its own tooling ecosystem and is owned by a different team. Here are the seven, paraphrased from the survey's definitions.

E — Execution environment. Where the agent's code and actions actually run, and what bounds them: managed sandboxes, microVMs, code-specialized runtimes, computer-use and browser environments, OS-level permission models. This is the blast-radius layer — what an agent can touch when it runs a command.

T — Tool interface and protocol. How external capabilities are described, discovered, and invoked: protocol standards (MCP, A2A), tool description and selection, tool-augmented training, session management. The model only knows tools through this layer.

C — Context and memory management. What the model can see across short-term, session, and persistent horizons: long-horizon context techniques and mitigations for context drift. The subject of the prior engineering phase, now one pillar among four.

L — Lifecycle and orchestration. The control flow that reads and writes state — from the single-agent inner loop to multi-agent patterns to full issue-to-pull-request pipelines. The loop itself lives here.

O — Observability and operations. Traces, costs, failures, reliability signals — tracing platforms, agent-specific ops tools, cost tracking, unified observability. The survey's open-source map finds this layer comparatively thin in public code.

V — Verification and evaluation. Turning tasks and traces into evaluation, failure attribution, and regression feedback: benchmark grounding, controlled execution, multi-level judgement, deployment-time evaluation loops. The difference between "it ran" and "it was right."

G — Governance and security. Constraints across model, system, and organizational sub-layers: permission models, lifecycle hooks, component hardening, declarative constitutions, audit infrastructure. Also thin in open source, the survey notes, and "more often live inside commercial platforms."

‍

‍