APPENDIX B: THE COMPONENT REFERENCE

INTRODUCTION TO THIS APPENDIX Chapter 8 introduced the parts that make up a production harness, and later chapters added detail. This appendix gathers them in one place so you can look up any single part quickly. For each component you will find its purpose, what goes in, what comes out, what it is responsible for, a small made-up example, and a common mistake. All examples are invented and use the fictional Resume Review Agent from the Practice Lab. Remember the order in which the components act during one pass through the loop: the instruction manager and context builder prepare what the model sees, the model adapter talks to the model, the permission resolver and tool registry control the tools, the budget tracker watches the limits, and the logger and reporter record what happened. Component 1: The Instruction Manager Purpose: it assembles the agent's standing rules into one set of instructions the model receives every time. Inputs: global rules that apply everywhere, project rules that apply to one job, and facts such as today's date. Outputs: one assembled system prompt, placed at the start of the context. Responsibilities: merge the rule sources in a fixed order, make sure stricter rules are not overridden by looser ones, and keep a record of which rule blocks were used. Example input: a global rule reading "Always be polite and cite your sources" and a project rule reading "Never read files outside the resumes folder". Example output: a single system prompt that lists both rules, followed by a line giving today's date. Common mistake: letting text from a resume or web page be mixed into the standing rules, which gives outside content the same authority as the developer. Component 2: The Context Builder Purpose: it decides exactly what the model sees at each step. Inputs: the conversation so far, the current task, available files, earlier tool results, and the progress notes. Outputs: a context package that fits inside the token budget. Responsibilities: choose which past messages to keep, trigger compaction when the transcript grows past a threshold, put the most important rules near the start and the end, and mark outside material as untrusted. Example input: twelve earlier messages, one new resume, and a progress notes file. Example output: the five most recent messages, a short summary of the older ones, the new resume, and the notes, all in a set order. Common mistake: dumping the whole raw history into every call, which wastes tokens and invites context rot. Component 3: The Model Adapter Purpose: it translates between the harness and a specific model provider. Inputs: the context package, the list of tools, and settings such as temperature. Outputs: the model's reply in one common internal format, no matter which provider produced it. Responsibilities: format requests the way the provider expects, read the reply, report token counts, and turn provider errors into clear, uniform error messages. Example input: a list of messages with a system message and a user message, plus the model name. Example output: an internal reply object that says either "final answer" with text, or "tool request" with a tool name and arguments, plus the number of tokens used. Common mistake: spreading provider-specific details through the whole harness, which makes it painful to switch providers later. Component 4: The Tool Registry Purpose: it is the catalog of every tool the agent can use. Inputs: tool definitions that give a name, a description, an input schema, an output schema, a required permission, a version, and a handler. Outputs: the list of tool descriptions shown to the model, and the matching handler when a tool is requested. Responsibilities: reject calls to unknown tools, check inputs against the schema, send the call to the right handler, and mark old tools as deprecated. Example input: the entry for read_file with the description "Reads the contents of one resume file" and the permission level read. Example output: when the model asks for read_file with a path, the registry validates the path format and returns the file's text from the handler. Common mistake: leaving out the permission and version fields, so nothing can later be locked down or retired safely. Component 5: The Permission Resolver Purpose: it decides whether the agent may do what it just asked to do. Inputs: the requested tool call, the tool's permission level, the current allow-list and deny-list, and any saved approvals. Outputs: one of three decisions, namely allow, deny, or ask a human. Responsibilities: apply least privilege, block paths outside permitted folders, require approval for risky actions, and write every decision to the log. Example input: a request to write a report that would overwrite an existing report file. Example output: the decision "ask a human", along with a short message explaining what will be overwritten. Common mistake: checking permissions inside each tool separately, which leaves gaps whenever a new tool is added. Component 6: The Budget Tracker Purpose: it keeps the agent from using more time, money, or text than allowed. Inputs: the limits for steps, tokens, money, and clock time, plus a running count of what has been used. Outputs: a signal saying whether to continue, to warn, or to stop. Responsibilities: update the counts after every model call and tool call, warn when a limit is close, and trigger a clean stop with a partial report when a limit is reached. Example input: a limit of ten steps per resume and a count showing that nine have been used. Example output: a warning that one step remains, then a stop signal if the tenth step does not finish the job. Common mistake: counting only tokens and forgetting step counts and clock time, so a loop that makes cheap calls runs forever. Component 7: The Logger Purpose: it records what happened so people can understand and review a run afterward. Inputs: events from every other component, such as model calls, tool calls, permission decisions, and errors. Outputs: structured log entries and trace spans written to a file or a log store. Responsibilities: record inputs, outputs, timing, and errors in a consistent format, keep secrets out of the logs, and link related events through a shared trace identifier. Example input: a tool call event for read_file that took forty milliseconds and succeeded. Example output: a log line holding the trace identifier, the span name, the start and end times, a status of success, and the file name read. Common mistake: writing free-form sentences instead of structured entries, which makes searching and charting nearly impossible. Component 8: The Reporter Purpose: it turns the results of a run into something a person can read. Inputs: the final results, the success or failure status, the budget usage, and any warnings. Outputs: a human-readable report, or a structured failure report if the run did not finish. Responsibilities: state clearly what was done, what was not done, and why, and hand the results back to the user or to the next agent. Example input: results showing twenty-four resumes matched and one skipped because its file was empty. Example output: a short report that lists the twenty-four matches and states plainly that the empty file was skipped and why. Common mistake: hiding partial failure behind a cheerful summary that reports only the successes.