What I expected, and what happened
A dependency graph of tasks, each one on its own branch, several agents working at once, everything converging back to the main line. Managing a team, essentially. The appeal was obvious and the analogy to real project work seemed sound.
It produced what splitting a connected problem across five inexperienced people with nobody leading them would produce. Work came back marked as complete that turned out to be a stub, a simulation, or a debug path proving the code ran without proving the feature worked. Nothing in the setup made any single run accountable for the outcome, because no single run owned it.
Scope drifted. Files grew. Two tasks touching entirely different files still found a way to disagree about the same piece of shared data.
Where the fault actually sat
Mostly with me. The goals were too broad. "Make this work" is not a task, and it does not become one by being written into a nicer file or handed to a better model.
A smaller model on a tightly defined job has been fine. The same model on an open-ended one produces whatever most cheaply resembles completion, which is what a vague goal selects for.
What I do instead
One capable model, one conversation, for anything where the parts connect. It costs more per token and noticeably less per finished thing.
Fanning out still earns its place for work that is independent and mechanically checkable. Writing a hundred content records against a schema. A review pass run against code that came out of a different session. Neither needs the reasoning that produced the plan.
When work does come back from more than one place, the joins are the thing to test. Each run was checked against its own task. None of them covered whether the pieces meet.
A status file can be maintained, checks can be run and a conflict can be flagged without me. Choosing the destination, accepting a trade-off and deciding whether the result is good enough have stayed with me, and I have not found a version of this where handing those over went well.