STARTING A RUN

INITIALIZING STATE, BUDGETS, AND PERMISSIONS Before the first model call, the harness must set up the run's starting conditions. State means the information the harness tracks about the run as it proceeds, such as the message history, the current step number, the files touched, and the results gathered. You studied state in Chapter 10. At startup, the harness creates a fresh state object, gives the run a unique identifier, and records the start time. The unique identifier, often called a run identifier, is a label that appears in every log line and every trace for this run, making it easy to find everything related to it later. Budgets are the limits on how much the run may spend. You will study them in Chapter 25. At startup, the harness sets the limits on tokens, time, and money, and starts counters at zero. Permissions define what the agent is allowed to do. For example, may it read files, write files, run commands, or send messages? May it reach the internet? Which folders can it touch? You will study permissions in depth in Chapter 37. At startup, the harness decides the permission level for this run based on the user, the task, and the environment. A safe default is least privilege, which means giving the run only the permissions it needs and nothing more. An office analogy helps. A new employee on the first day receives a badge that opens only the doors needed for the job, not the master key to the whole building. The ordering of the startup steps matters a great deal. Consider what could go wrong if the steps run in the wrong order. If the permissions are applied after the loop begins, there may be a short window in which the agent can call a tool without any restriction. If the budgets are set after the first model call, the first call is unlimited. If the logging is turned on after intake, the original request may be lost, and an investigation later will lack key facts. The safe order is as follows. First, create the run identifier and start logging, so everything that follows is recorded. Second, receive and validate the request. Third, structure the request into a goal, or ask a clarifying question and stop. Fourth, determine and apply permissions. Fifth, set budgets and start counters. Sixth, initialize state. Seventh, assemble the instructions and context. Eighth, only then, enter the loop and make the first model call. The key principle can be stated in one sentence: all the guardrails must be in place before the first action is possible. A fence built after the horse has bolted is not much use.