Eight of my agents wrote to the wrong folder
One request became 24 agent contracts. Eight agents wrote outside their scope, all were caught before merge, and the fix was showing each agent its contract.
I asked a coordinator to plan 24 agent contracts from one request. Eight agents wrote to the wrong folder, each one guessing a path its brief never named. The coordinator caught all eight at exit before anything reached main. The fix was telling every agent its own declared paths and checks. All eight passed on the rerun.
Two days after the first two live trials of the coordinator, I ran it against a different kind of job: a content batch for my own publishing pipeline. One plain-English request, describing 24 independent file-level tasks. Two existing posts reworked, four moved into a publishing queue, sixteen new platform posts derived from four long-form articles. The paper behind this series is at DOI 10.5281/zenodo.22670722, licensed CC BY 4.0, and this run is section 5.3 of it.
Twenty four contracts, eight breaches
The planner turned that one sentence into 24 contracts inside three minutes, as six parallel planner calls of four tasks each. Every contract was scoped to one or two declared paths in one repository. Nothing was refused before launch. Fourteen contracts came back fulfilled on the first pass. Eight came back refused at exit for writing outside their declared scope. Two more were refused for a failed check, a separate problem with the checks themselves and not the subject of this post.
All eight scope breaches had the same shape. Each agent was supposed to create a new file at the queue path its own contract had declared. Each one wrote to the repository’s conventional drafts folder instead. The brief the planner gave each agent said “create the new file” and stopped there, without naming where. The actual path lived only in the claim, the record the coordinator holds to check the agent’s work against, not in anything the agent itself could read. So each agent filled the gap the only way it could, from the repository’s own conventions, confidently and wrong.
The fulfilment check caught every one of them. That check runs at exit: it compares what a session actually wrote against the paths it was granted, and anything outside that scope is recorded as a breach. All eight were recorded that way, and none of the eight files reached the repository’s main line. That is the part of the design working exactly as built. The declared scope made the wrong write visible instead of letting it merge quietly next to the correct ones in the same run.
Caught, but at the expensive end
It is also the expensive way to catch a mistake. A collision refused before an agent spawns costs nothing beyond the claim check itself, because the losing process never starts. A breach caught at exit still costs the whole run: the tokens, the wall time, the write itself, all spent before the coordinator can say no. Eight wasted runs out of twenty four is a third of the batch. Every one of them was avoidable before it started, not just detectable after it finished.
Enforced, never disclosed
The actual cause was simpler than a planning bug. Scope was enforced the whole time. It was never disclosed. The coordinator held the declared paths and the exit checks for every contract, but an agent’s instructions were only ever the planner’s plain-English brief. Enforcing a boundary you never show the agent holding it turns the coordinator into a trap that catches the agent it never warned.
The fix was one change: append each agent’s own declared paths and its own exit checks to its instructions. Then the agent can read the same contract the coordinator is going to grade it against. Nothing else about the eight tasks changed, not the planner’s brief, not the model, not the repository. The eight breached contracts ran again with that one addition. All eight were fulfilled.
I did not need a smarter planner or a stricter check. I needed to stop assuming that enforcing a rule and telling someone the rule exists are the same thing.
Written by Sagar Thakkar, AI systems architect specialising in large-scale data processing, cost-optimised cloud-native systems, and reliable production infrastructure. More at sagarthakkar.com.