Born Approved
Written later and filed to this date, as part of filling in every day of the year.
The design document for the factory is 473 lines long, and it lives in the wrong repository. It describes six boxes in an ASCII diagram: an orchestrator, a task planner, an executor, a monitor, a self-update system and an approver. Under the objectives sits the sentence that matters: natural language task description, then clarification questions, then approval, then execution. There is an example session. The agent asks three questions about a backup, proposes four steps, the third of which deletes older backups, prints Approve? (y/n):, and the user types y. The first success metric at the bottom is that more than ninety percent of approved tasks complete.
The repository it lives in is an app for interviewing a person and keeping their voice. The factory has nothing to do with that app. It sat in the app’s working tree, uncommitted, for half a year.
Nine days
The interview app was started at the end of November. Nine days later a new repository appeared with the subject “Initial commit: Agent Runner v1.0”, and its library directory is the factory: thirteen modules, each byte for byte identical to the thirteen in the interview app’s tree. The command-line script is the same file with two import paths changed. What did not make the trip is the writing. The new repository has a README of 132 lines with a quick start and a column of check marks. The design, a README of its own and a setup guide stayed behind in the app, where nothing imports them.
So there are two copies, and they disagree about what the thing is. The copy with the design says there is an approver. The copy that became a repository has no approval module and no session module, the fifth and seventh in the design’s own numbering. The words survive in the types file, once as a kind of agent, "approver", and once as a task state, "approved". The second turns up once more, in the factory’s main class, in the method that creates a task. The task is built with its description, its plan, an agent id, a fresh session id, a timestamp, and a status. The status is the string "approved".
Nothing sets it and nothing asks. The command-line script plans the task, asks its clarifying questions, prints the plan, prints a list headed Risks when the planner found any, prints an estimated duration, and then creates the task and executes it, in that order, with no prompt between the risks and the run. A task in this factory is born approved. The one step in the design that put a person between the plan and the shell became a constant.
What it did instead
The code does what its README promises: it plans, it executes, it watches files, and it modifies itself. Other pieces here have read those self-modifying commits closely, and I will not reread them. I will only note the order of events. The approval step was designed first and missing from the first commit, and the loop that rewrites its own source was committed thirty-five minutes after it and was rewriting files within the next forty. The thing that was going to ask had been replaced by a field before the thing that most needed asking about existed.
I did not decide that, as far as the record shows. There is no decision in either repository, only an absence: a module the design names and the tree does not contain. The likeliest story is the ordinary one. The approver was the least fun box in the diagram and the easiest to defer, and deferring it cost nothing on the day, because the only user was me and I was watching.
The fossil
The design survived because of a rule it had no part in writing. When agents eventually reached the interview app, they found three thousand lines of uncommitted work in its tree, the factory among them, and a plan calling the factory a separate experiment, out of scope. Session after session treated the dirty files as some other agent’s work in progress, built small extractions around them, and backed away. Then the fleet’s charter settled on one worker per repository, which voided the premise that the work in the tree belonged to anyone else. The next session landed the factory in one commit whose message says why: fully self-contained, no product file imports it, committed, not developed further, purely to clean the tree. The design document entered version control as housekeeping.
That is where the approver lives now. Not in the repository named for the factory, where the code runs, but in the other one, in a file nothing reads, under a commit whose purpose was to get it out of the way.
What the repository taught me is to look for the step that became a constant. A design has a box for the thing that asks; the code has a string; the string is the only evidence the box was ever there. When I read a type definition in one of my own repositories and find a state that nothing transitions into, because everything is simply born in it, I take that as the design talking, and I go and find out what it was going to ask.