STARTING A RUN

EXAMPLES Example 1: Turning a vague request into a goal object. A user types: "clean up my inbox." A naive agent might start deleting messages. A harness with proper intake turns the request into a structured goal. In plain terms, the goal object says the goal is to archive emails older than 90 days except those marked important, and the constraints say do not delete anything, only archive. In a data format sometimes used for such objects, it might look like this. [START OF JSON CODE] // A structured goal object: archive old emails, but never delete, only archive {"goal": "archive emails older than 90 days except those marked important", "constraints": ["do not delete, only archive"]} [END OF JSON CODE] If the harness was unsure what the user meant, it could have asked, "Should I archive or delete old messages, and what age counts as old?" By choosing the conservative interpretation, archiving rather than deleting, and by recording its interpretation, the harness protects the user. It can also show the user the interpreted goal for a quick confirmation before starting, a pattern known as echoing the goal back. Example 2: Instruction assembly at startup. A user asks a coding agent: "Add a logout button to the settings page." At startup, the harness collects three things. The standing system rules say the agent must write tests for new features and never edit files outside the project folder. The project conventions file says the team uses a particular style for naming and a particular testing tool. The user's request is the logout button task. The harness combines these into one complete initial prompt, with each part labeled: first the rules, then the conventions, then the task. The model starts its first step already knowing the team's habits, without the user needing to repeat them. This saves the user effort and makes the agent's work consistent across tasks. Example 3: Initializing budgets before the first call. A company configures every run to start with a five-dollar spending limit, a thirty-minute time limit, and read-only access to the file system. Before the model is called even once, the harness sets all three. The money counter is at zero out of five dollars. The clock starts at zero out of thirty minutes. The file permission is read-only, so even if the model decides to write a file, the harness will refuse. Suppose the model's very first output is a request to delete a folder. Because the permission was already set to read-only, the request is denied before it can do harm. If the permission had been set after the first call, that single delete might have succeeded. Example 4: Ambiguity triggers a clarifying question. A user writes: "do the thing from yesterday." The agent has no record of a specific thing from yesterday, or it has records of three different tasks. A harness that pushes ahead would be guessing, and might repeat the wrong task, perhaps sending a message twice. A well-designed intake step detects the ambiguity and asks, "I found three tasks from yesterday: a sales report, a calendar update, and an email draft. Which one would you like me to do?" The user answers in a few seconds, and the run begins with a correct, confirmed goal. The few seconds of delay save far more time than a wrong action would cost.