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."

3. The Three Cross-Layer Effects (the Part That Bites)

The survey is careful that the layers aren't independent dials, and its cross-layer synthesis is where the practical wisdom lives. The cost–quality–speed trilemma: stronger sandboxes, richer context, and deeper evaluation all improve quality while costing tokens, latency, and infrastructure — so a production harness can't treat quality as a single number to maximize; it has to decide which risks justify expensive controls and which checks can run asynchronously or in a regression suite. The capability–control tradeoff: bigger tool menus, persistent memory, and permissive sandboxes broaden what an agent can do while enlarging the blast radius of a misaligned or compromised action — meaning capability and control are not separate features but one design axis spanning tool schemas, runtime permissions, identity, auditability, and human approval. And the harness coupling problem: a change to any one layer can look beneficial in isolation and degrade the whole rollout in combination — so harness changes must be tested as system changes.

That last point is the one Priyanka's post-mortems kept missing. A retry added at the lifecycle layer interacts with context (retried output re-enters the window), observability (does the trace show the retry?), and cost (each retry re-bills). ETCLOVG's value isn't only naming seven layers; it's insisting they be reasoned about together — the argument for a runtime where layers are co-designed rather than glued.

4. Structural Pillars on a Production Runtime: E, T, C, L

Walk the four structural layers against TrueFoundry's Agent Harness and each has a concrete implementation. Execution (E): when a session requires code execution or file operations, the harness can provision an isolated sandbox on demand, reuse it across turns in that session, and manage its lifecycle and cleanup (sandbox docs) — the survey's "managed sandbox" cell, with the blast-radius bound being a platform property rather than each team's bespoke container. Tooling (T): capabilities are reached through the MCP Gateway — MCP as the protocol standard the survey names, plus a registry for discovery, per-tool descriptions and selection, and session/auth management — so the tool layer is governed rather than hand-wired. Context (C): the harness's context-engineering suite — compaction, large-result offloading, code mode, sub-agent isolation — is the survey's "long-horizon context and drift mitigation" cell, the subject of our JIT context post. Lifecycle (L): the plan→act→observe loop, sub-agent orchestration, and human-in-the-loop pauses are the control flow that reads and writes state — the survey's single-agent-inner-loop-to-multi-agent-pipeline span.

5. Mapping the Control Plane: Native O and G, Connected V

Here the survey's findings are narrower than a blanket control-plane gap. Observability and Governance are comparatively thin in open source and more often appear inside commercial platforms, SDK features, or engineering writeups. Verification has stronger visible coverage, although the paper identifies a separate gap between widespread tracing and less-common offline evaluation. That makes O and G direct platform differentiators in this mapping; V is better treated as an integration surface built on the runtime's telemetry.

Observability (O) on the runtime is the per-step trace: every model call, tool call, and sandbox execution recorded with cost, tokens, and latency, exported over OpenTelemetry (our OTel post) into whatever the rest of the stack already uses. Verification (V) is an adjacent workflow rather than a native Agent Harness evaluator today. TrueFoundry provides traces, model and tool metadata, routing context, and OpenTelemetry export that can feed online or offline evaluators — the online evaluation pattern is built on that telemetry, not shipped as a built-in feature. Evaluation policies, judges, and promotion gates must be implemented in the application or a connected evaluation system — the survey's "turn traces into evaluation and regression feedback" as an integration concern. Governance (G) spans the survey's three sub-layers: model-level and system-level guardrails (input and output) at the gateway, organizational permission models via per-agent RBAC and the no-keys credential model, component hardening, and audit infrastructure — the subject of our governance and audit post. The survey lists "declarative constitutions" under G; the closest runtime analog is versioned guardrail and access-policy configuration (guardrails docs).

Execution:     provision an isolated sandbox when required
Tooling:       expose approved MCP tools through centralized identity and policy
Context:       compact or offload results when the working context grows
Lifecycle:     bound steps and pause sensitive actions for approval
Observability: record model, tool, and sandbox activity
Verification:  send traces to connected evaluators
Governance:    apply role, tool, and guardrail policies

6. The Coupling Problem Is the Real Argument for a Platform

It would be easy to read section 4 and 5 as a checklist — seven boxes, tick each. The survey's own cross-layer synthesis argues against exactly that reading, and it's the strongest reason to care where the layers live. Because the layers are coupled, a harness assembled from seven independently-chosen best-of-breed tools inherits the coupling problem at every seam: the sandbox that doesn't emit traces the observability tool understands; the verifier that can't see the governance layer's approval events; the context compaction that silently drops the data the evaluation layer needed to score the run. The survey's prescription — test harness changes as system changes — is hard to honor when the system is a harness assembled from independently selected components — creating integration boundaries at which state, identity, telemetry, and policy semantics can diverge.

This is also the survey's framework-to-platform shift, stated as architecture. It explicitly names a move from agent frameworks (which package local abstractions: agents, tools, memory, loops) to agent platforms (which add durable workspaces, identity, observability, evaluation, governance, and human handoff across many runs and many users). A platform isn't merely a framework with more features; it's the unit at which the seven layers can be co-designed and changed together. That doesn't make "buy a platform" the universally correct answer — a research lab studying loop designs should own its loop, and any team should own the thin edges that are its differentiation — but it does explain why the coupling problem and the framework-to-platform shift point the same direction for most production deployments.

7. Using ETCLOVG as a Diagnostic

The taxonomy's most immediate value isn't architectural; it's diagnostic, and it's what Priyanka actually needed. A follow-up paper already uses ETCLOVG exactly this way — as a vocabulary for connecting runtime evidence to the harness mechanism that needs repair, driving fixes from trace-grounded failure diagnoses rather than guesses. The practice is to take a failing trajectory and ask which layer owns the failure. Agent ran a destructive command unsandboxed → E. Chose the wrong tool from an ambiguous description → T. Degraded over a long run as the window filled → C. Looped on a failure or stopped early → L. The failure was invisible until a customer reported it → O. It "succeeded" but produced a wrong result nobody caught → V. It did something it should never have been permitted to do → G.

Run Priyanka's circling post-mortem through that and the meeting stops circling: the engineer who blamed the model and the one who added a retry were both reaching for L-layer fixes, while the actual failure — an action taken with no record and no check — was an O and V gap. A model upgrade alone would therefore be unlikely to address the underlying system behavior. ETCLOVG turned an argument about opinions into a question about layers, which is the entire point of a taxonomy: not to be correct in the abstract, but to make the next decision legible. End-to-end runtime traces provide much of the evidence the diagnostic needs; connected evaluators can add V-layer outcome scores and regression signals — a runtime plus its integrations and traces every run gives the diagnostic its evidence; the taxonomy gives the evidence its categories.

8. What the Taxonomy Says About the Future (and Its Limits)

The survey closes on open problems, and two are worth carrying because they temper any "we've solved the harness" triumphalism. First, adaptive simplification: every wrapper encodes an assumption about what the model can't do reliably alone, and as models improve, some interventions stay load-bearing while others become pure overhead — so a good harness needs to ablate and simplify itself under joint quality, latency, cost, and risk constraints. The seven layers are not seven things to maximize; some of today's scaffolding is tomorrow's dead weight, and a mature platform should help you find out which. Second, standard handoffs: the survey argues a handoff should transfer not just a text summary but intent, constraints, permissions, artifacts, provenance, budget state, risk level, and trace history — a richer contract than any current protocol carries, and an honest admission that the multi-agent and human-in-the-loop story is unfinished.

The limits matter for honesty's sake. ETCLOVG is a 2026 survey's proposal, not a standard; its layer boundaries are a useful cut, not the only one, and the authors are explicit that the phases overlap and the project coding is interpretive. Its real contribution is the one Priyanka used: a shared, production-grounded vocabulary for saying precisely which part of the infrastructure around the model is doing the work, or failing to. Map a runtime against it to find the empty cells — and the survey's own ecosystem finding is that Observability and Governance are the comparatively thin cells; Verification coverage exists but often stops at tracing, short of deployment-time evaluation — which in this mapping remains an application-layer workflow on the runtime's telemetry.

9. Frequently Asked Questions

Is ETCLOVG an industry standard? No — it's a taxonomy proposed in "Agent Harness Engineering: A Survey" (Li et al., 2026, under review for TMLR), already being picked up as shared vocabulary by follow-up work on trace-grounded harness repair. Treat it as a well-grounded analytical lens, not a spec to certify against. Its value is in making harness concerns legible and comparable, which is real whether or not it ever becomes canonical.

How is this different from the harness/scaffold distinction you wrote about before? Complementary. The harness-vs-scaffold split separates the execution machinery from the content the model works from; ETCLOVG zooms into the machinery and resolves it into seven layers. You can hold both: scaffold is roughly the survey's prompt/context concerns, and the harness is the E·T·C·L·O·V·G stack that runs it. ETCLOVG is the higher-resolution view of "the harness" we'd named more coarsely.

Why are Observability and Governance promoted to their own layers? Because in production they have distinct tooling and distinct owners — the survey points to dedicated observability stacks and separate security/governance ownership — and folding them into lifecycle hooks hides exactly the layers that determine whether you can operate an agent safely. The promotion is also empirical: the survey's ecosystem map finds these two layers the thinnest in open source, which is itself a finding worth designing around.

Do I need all seven layers for every agent? No, and the survey's cost–quality–speed trilemma is the reason — every control costs something, and the right depth per layer depends on the agent's risk and value. A low-stakes internal helper needs far less V and G than an agent that can mutate production. The taxonomy's use here is to make the omissions deliberate: choose which layers are thin on purpose, rather than discovering the gap during an incident.

If I adopt a managed runtime, am I locked into its version of these layers? You adopt its implementations of E, T, C, L, O, and much of G, the way you adopt any runtime's semantics. V remains partly application-owned unless you connect an evaluation system to the runtime's traces and metadata. The portable parts are the scaffold (instructions, tool definitions, skills) and the evaluation criteria — keep those clean and versioned and most of your investment moves with you. The coupling the survey warns about is precisely the thing you're paying the platform to handle.

Priyanka's next post-mortem used the map. The trajectory exposed an observability blind spot and a missing verification check; the team added a per-step trace and connected a deployment-time evaluator. In this scenario, those changes address the available system evidence more directly than a model upgrade alone would. That is what a useful taxonomy buys: not the end of hard problems, but a clearer account of which layer owns each one. ETCLOVG names the seven and insists that teams reason about their interactions, while the ecosystem map identifies O and G as the clearest open-source gaps and treats V as a workflow that still has to be implemented or integrated.

References

• Li, J., Xiao, X., Zhang, Y., Liu, C., et al. — "Agent Harness Engineering: A Survey" (2026, under review) — source of the ETCLOVG taxonomy, the three-phase framing, the cross-layer synthesis, and the open-source ecosystem map. Project page · OpenReview PDF. Paraphrased with credit.
• HarnessFix (arXiv:2606.06324, 2026) — follow-up work on trace-grounded harness repair; uses ETCLOVG-style layer attribution as a diagnostic vocabulary for connecting runtime evidence to harness mechanisms.
• TrueFoundry Agent Harness — on-demand sandbox (E), MCP tooling (T), context suite (C), orchestration loop (L), and traces (O) as documented capabilities, with governance (G) largely native and verification (V) as a connected workflow on the runtime’s telemetry.
• Harness vs. scaffold, JIT context, and online evaluation — the per-layer deep dives this overview connects.
• AI governance and audit and OpenTelemetry at the gateway — the G and O layers in depth.

Northwind and Priyanka are an illustrative composite, not a specific organization or incident. The ETCLOVG taxonomy, three-phase framing, cross-layer effects, ecosystem-map findings, and open problems are paraphrased from "Agent Harness Engineering: A Survey" (Li et al., 2026), with credit; layer definitions follow the survey's project page. The taxonomy is a research proposal under review, not an industry standard. The layer-mapping pseudocode is illustrative and is not literal TrueFoundry product configuration. TrueFoundry capabilities reflect public documentation at the time of writing; verify against current docs.

‍