THE SEVEN-LAYER ETCLOVG TAXONOMY

WHAT A TAXONOMY IS AND WHY YOU NEED ONE A taxonomy is a system for sorting things into named groups. Biologists use one to sort living things into kingdoms, families, and species. A library uses one to sort books into sections so that you can find a cookbook without walking past every shelf. A taxonomy does not change the things being sorted, but it gives people a shared map. Why does harness engineering need a map? Because a real harness contains a great deal of code, and without a map every conversation turns into confusion. Imagine a team meeting where one person says, "The agent is unreliable," a second says, "We need more safety," and a third says, "Our costs are out of hand." All three may be describing the same underlying problem, or three different ones, and nobody can tell. With a taxonomy, the team can say, "The failure is in the Context layer," or "That request belongs to Governance," and everyone knows where to look and who to ask. The taxonomy used in this book is called ETCLOVG. The name is a string made of the first letters of seven words: Execution, Tooling, Context, Lifecycle, Observability, Verification, and Governance. It is one framework proposed by researchers to organize the knowledge of harness engineering. Other writers slice the field a little differently, and that is acceptable. What matters is that you hold one clear map in your head, and this book uses this one as its backbone. Parts Three through Nine each take one layer in the order listed, and later Parts build on them. You can picture the seven layers as the rooms of a house. Each room has its own purpose, but the rooms are joined by doors, and you need all of them for the house to work. Layer One: Execution Execution is the layer that drives the agent. It is the loop that repeatedly asks the model what to do next, carries out the answer, and then asks again. If you imagine the harness as a restaurant, Execution is the kitchen line where orders are actually cooked, one after another, until the meal is done. This layer also holds the rules about control flow, which means the order in which things happen and which path is taken when there is a choice. It decides when to stop, how many times to try, where to run risky code, and how to fail without making a mess. Part Three, Chapters 9 through 12, covers the Execution layer in depth. When something goes wrong at this layer, the symptoms are things like an agent that never stops, one that stops too early, or one that crashes halfway through and cannot continue. Layer Two: Tooling Tooling is the layer that gives the agent abilities. A tool is a function that the agent can ask the harness to run, such as searching the web, reading a file, or looking up an order. The model by itself can only produce text, so every action it takes in the world passes through a tool. If Execution is the kitchen line, Tooling is the equipment and ingredients stocked in the kitchen. A chef with no stove cannot cook, and a chef with a hundred confusing gadgets wastes time. This layer covers how tools are defined, listed, described, connected to outside services, and kept safe to use. Part Four, Chapters 13 through 17, covers it. When something goes wrong here, you see an agent that picks the wrong tool, passes the wrong inputs, or cannot do something it obviously needs to do. Layer Three: Context Context is the layer that manages the agent's working memory. You learned in Chapter 2 that a model can only consider a limited amount of text at once, which is called the context window. The Context layer decides what goes into that window at each step and what is trimmed, summarized, or saved elsewhere. In the restaurant picture, Context is the order ticket that the chef reads. If the ticket is missing the allergy note, the dish may harm someone, and if the ticket is a thousand pages long, the chef cannot find the instruction that matters. Part Five, Chapters 18 through 22, covers this layer. Typical symptoms of trouble here are an agent that forgets something it was told earlier, repeats work it already did, or becomes confused after a long session. Layer Four: Lifecycle Lifecycle is the layer that manages the birth, life, and end of a single run. A run is one complete attempt by the agent to do a job, from the moment it is started until it finishes or is stopped. The Lifecycle layer starts the run by loading the right settings, it allows other code to react at important moments, it enforces limits on time and money, and it closes the run neatly. In the restaurant, Lifecycle is the host who seats a party, the manager who watches the clock and the budget, and the person who clears the table afterward. Part Six, Chapters 23 through 26, covers it. When Lifecycle fails, you see runs that start with the wrong setup, runs that never end, bills that nobody expected, and messes left behind after a run is over. Layer Five: Observability Observability is the ability to see what happened inside the agent. A system is said to be observable when you can understand its internal behavior by looking at the records it produces. Those records include traces, which are step-by-step histories of a run, logs, which are written notes about events, and metrics, which are counted or measured numbers such as how long a step took. In the restaurant, Observability is the set of cameras, receipts, and timers that let the owner learn what happened on a busy night. Part Seven, Chapters 27 through 30, covers it. When Observability is weak, an agent fails and nobody can tell why, so every investigation turns into guessing. Layer Six: Verification Verification is the layer that checks whether outputs are correct. It includes evaluations, which are organized tests that measure how well the agent performs on a set of tasks, and it includes checks run on individual outputs before they are trusted. In the restaurant, Verification is the taste test before the plate leaves the kitchen, and also the regular inspection that confirms the recipes still produce good food. Part Eight, Chapters 31 through 35, covers it. When Verification is weak, wrong answers get through to users, and the team does not learn whether a change made the system better or worse. Layer Seven: Governance Governance is the layer that deals with safety, permissions, and compliance. Compliance means following the laws, regulations, and organizational rules that apply to your system. Governance decides what the agent is allowed to do, protects against attacks, isolates risky actions, and makes sure the system respects the rules of the world it operates in. In the restaurant, Governance is the health code, the lock on the cash drawer, and the rule that only the manager can approve a refund. Part Nine, Chapters 36 through 41, covers it. When Governance is weak, the dangers are serious: an agent might leak private data, be tricked by hostile text, or take an action that nobody authorized.