THE ANATOMY OF A PRODUCTION HARNESS (COMPONENT MAP)

LOGGING AND REPORTING COMPONENTS The logger is the component that writes down what happens. Each time something notable occurs, such as a model call, a tool request, a permission decision, or an error, the logger records it along with the time. A good log lets an engineer reconstruct a run after the fact, in the way that a flight recorder lets investigators understand a flight. Without a logger, an agent that fails leaves no clues, and the team can only guess. The reporter is the component that turns the record of a run into a summary for a person. A log is detailed and meant for engineers. A report is short and meant for the user or the manager, and it says what was asked, what was done, what the result was, and whether anything went wrong. When a run ends early because of a budget limit or an error, the reporter is what produces the honest message, "Here is what I finished and here is what remains," rather than letting the run vanish silently. The two components work as a pair, rather like a ship's logbook and the captain's daily summary. Observability, the topic of Part Seven, builds on this logger, and it grows from simple written notes into traces, metrics, and dashboards. How the Components Combine: A While-Loop with a Tool Registry and a Permission Layer You have now met eight components, and it may feel like a lot. Here is the reassuring truth. At its heart, a harness is simply a while-loop with a tool registry and a permission layer, and the other components are the supporting cast that make that loop safe and dependable. Here is one pass of the loop, described in order. First, the budget tracker is checked, and if a limit has been reached, the loop stops and the reporter writes up what was done. Second, the instruction manager supplies the assembled standing rules. Third, the context builder gathers the rules, the task, the history, and anything else that is needed, and builds the model's reading material. Fourth, the model adapter translates this into the provider's format, sends it, and translates the reply back. Fifth, the harness examines the reply. If the model says it is finished, the loop ends and the reporter produces the final report. If the model asks to use a tool, the harness goes to the sixth step. Sixth, the tool registry looks up the requested tool, and the permission resolver decides whether the request may proceed. Seventh, if allowed, the tool runs and its result is captured, and if refused or awaiting approval, a message saying so is captured instead. Eighth, the result is added to the history, the budget tracker updates its totals, the logger records everything, and the loop goes around again. Notice how short the core idea is. Call the model, find out what it wants, check whether that is allowed, do it, record it, repeat. Everything else in this book is about doing each of those steps well. It is also worth noticing which components are missing from the model itself. The model has no instruction manager, no registry, no permission rules, no budget, and no log. All of that is harness, which is why the same model can behave so differently in different products, as you saw in Chapter 5. A final word of caution: a first version does not need every component in its full form. A small project can start with a simple instruction file, a simple context builder, one adapter, two or three tools, a short list of permission rules, a step limit, and a plain text log. What you should never skip is thinking about each job, because even a tiny version of every component is better than a missing one.