STARTING A RUN

TASK INTAKE Task intake means receiving and structuring the user's request. It is the front door of the harness. Human requests are usually messy. They are short, vague, full of unstated assumptions, and sometimes contradictory. A person says, "clean up my inbox," and has in mind a long list of things they would like and things they would hate. The model might guess, but a guess about something as sensitive as email could lead to deleted messages. So the harness performs intake, which has several jobs. The first job is to receive the request along with its context: who asked, through which channel, at what time, and with what attachments. The second job is to validate it. Validation means checking that the request is well-formed and allowed. Is it empty? Is it in a language the agent supports? Is the user permitted to ask for this? Does it refer to something that does not exist, such as "the document from yesterday" when no such document is found? The third job is to structure it. Structuring means converting the free-form request into a clear, organized object that the rest of the harness can work with. Such an object is often called a goal object or task specification. It typically contains a statement of the goal, a list of constraints, the inputs available, the expected form of the output, and any deadlines or priorities. The fourth job is to decide whether to proceed or to ask for clarification. If the request is clear enough, the run proceeds. If it is ambiguous in a way that matters, the right action is to ask the user a question before doing anything. Clarifying costs the user a few seconds. Guessing wrong might cost hours or cause damage. A good rule of thumb is that the more irreversible or costly the possible action, the lower the tolerance for ambiguity. Reading a file on a wrong guess is harmless. Deleting files on a wrong guess is not. Structured intake is often performed by a small, cheap model call or by simple code with rules, and it is itself a good place to log what the user asked, exactly as received, for later debugging and auditing. Auditing means reviewing records after the fact to check that things were done properly.