Quick conclusion
At the end of part two, I said the log would tell me if the check ever stopped running, and that I would rather learn that from a missing line than from a published article.
Nine days later, the log has not moved. Not because the check failed. Because nobody handed it anything to check.
I approved one model for one job, built a gate to catch it if that job went wrong, and rolled the gate out to a second site I run. Then I gave the gate two chances to prove itself. One job got finished without it. The other has not been started at all.
This is not the ending I planned for this series. It is the one I got.
The gate I built
Part two ended with a pass condition and a promise: reorganize research notes with a cheap model, but only if every output goes through a check that compares what came out against what went in.
Building that into a habit took one day. I wrote the rule down, wrote a short script that runs the comparison and logs the result, and pointed both at the same target: a model that had already proven it could take research notes and shuffle them into place without inventing anything or dropping the parts marked “not confirmed yet.”
I also had to close a gap I had not thought about until I was mid-build. The rule lived in one place. My second site is edited by two different AI agents, and only one of them had read the rule. If the other one received a delegated file and had no idea a gate existed, the gate would not fail. It would simply be skipped, silently, by an agent that was never told to look for it. So the same afternoon, I wrote the rule into both agents’ instructions, not just one. A rule that only one editor has read is exactly the kind of rule I stopped trusting when I started building gates instead of writing more rules in the first place.
That felt like the responsible way to ship a safety check. In hindsight, it was also the last thing that happened quickly.
Where I put it to work
I set up two pieces of writing on the second site specifically to test delegation. Both were framed, from the start, as the place where the gate would get its first real run outside a benchmark.
The first was finished four days later. It went through research, a draft, a fact-check pass, and publication, on schedule.
The second is still sitting at the very first stage. Nothing past the folder setup exists yet.
Neither one used delegation.
What happened to the two test cases
The first case is the more interesting failure, because it was not a failure of the gate. It was a failure of my premise.
The job kept turning out to be things I did better myself. It needed a hunt through a vendor’s own technical documentation to check a claim about how a trading platform reports time, and the documentation itself turned out to contain the answer, worded carefully enough that reading it directly was faster than describing it to a contractor and checking the result afterward. Later in the same piece, a fact-check caught a sentence that had reversed a technical detail. The gate I built cannot catch that kind of error. It only catches a contractor changing material I already have. It does nothing for material I have to go find.
So I never created the file the gate was built to inspect. There was no delegated draft, because there was no point in the process where handing the work off would have been faster than doing it.
The second case is a plainer story: I ran out of runway before I ran out of intention. It was scheduled for a stretch of days when I knew I would have less time available, set up in advance specifically so a contractor model could carry some of the load. The setup step happened. The research step, delegated or otherwise, did not happen yet.
What the log said instead
The log I mentioned in part two has four rows in it. All four are from the day I built it, testing the model before I approved it. Nine days and one finished article later, the count is still four.
A log that is not growing looks identical whether the check is broken or simply idle. From the outside, silence reads the same either way. The only way I know it is the second one is that I know what I did.
The log kept the one promise I asked of it. If a delegation had happened and skipped the check, that would have shown up as a gap I could point to. Instead it shows the plainer thing: the check has nothing to report because nothing was sent through the door it was guarding.
Why “the material was wrong” is not the whole answer
It would be tidy to end here and say the lesson is that fact-heavy writing does not delegate. I do not think that is the complete answer, and I want to be honest about the part I cannot fully explain.
By the time a piece of research is organized enough to safely hand to a contractor, most of the reading is already done. The gate compares input to output, which means it needs a finished “input” to exist first. Producing that input is close to doing the job. What is left afterward is closer to formatting than to research, and formatting was already the thing part two showed the approved model was good at, not the part that used to take time.
That is a structural explanation, and I think it is a real one. But it does not rule out a simpler one sitting next to it: writing the checklist and getting comfortable enough to use it were two different steps, and I have only done the first.
I do not know the split between those two reasons yet. I am not going to pretend I do.
What I actually got for a day of work
Not nothing. If a contractor’s output had come back with an invented number or a missing warning, I would have caught it, because the mechanism exists and both agents on the second site now know it is there. That is worth having on file even if it has sat unused.
What I did not get is any evidence that delegation saves time on this kind of writing. Two opportunities, framed as tests from the start, and neither one produced a data point.
The honest way to put it: the safety net worked, in the sense that it has never had to catch anything, because nothing has fallen.
FAQ
Does this mean the delegation approved in part two was a mistake?
No. That approval still stands, for the same narrow job: reorganizing research notes, with every output checked. It has just not come up again since the day I set it up.
Why not force a test, so the series has a real result?
Because that is exactly the failure mode this series has been about since part one: shaping the input to get the answer I want, instead of reporting the one I got. If I manufacture a delegation just to fill a data point, I am back to grading the wrong thing.
Was building the gate on the same day as writing the rule into two agents’ instructions overkill?
I do not think so. A gate that only one of two editors knows about is not a gate, it is a trap for whichever one reads the instructions less recently. It cost an afternoon. Finding out about the gap later would have cost more.
What happens to the unfinished piece?
It stays unfinished until there is time for it, delegated or not. Publishing on a deadline the process cannot support was never the point.
Next steps
Three parts in, and each one landed somewhere I had not planned when I wrote the outline. Part one was supposed to be a model comparison and became a lesson about what I had asked for. Part two was supposed to close with a clean pass and closed with a self-correction I made mid-experiment. Part three was supposed to report a quarter’s worth of real-world delegation and instead reports that the quarter has not really started.
I am not writing a part four to force a different ending. The log stays where it is, growing or not, and the approval from part two stays in effect for whenever a job actually fits it. If that happens, it will show up as a line in a file that has had exactly four for nine days. I will let that line speak when it exists, instead of writing around its absence now.
That closes this series. Three tests, three surprises, and the last one is that building the safeguard turned out to be easier than finding a reason to need it.