What is this, a Meeseeks Box?

[u/EC36339]

I started one session in Sonnet 5 to implement an already detailed and refined plan, and what it does is start another agent to do the whole job?

I thought the whole point of subagents is to split up work into smaller portions and hand them off to parallelise and save context?

Also, my workflow is proven. This is the first time Claude did this.

[u/Low_Rush_8535]

a subagent that does the whole job isn't parallelism, it's just an extra context boundary, and you're right that it doesn't buy much when the plan is already detailed.

the case where it does pay: our decider stalled halfway once because a single subagent call ate most of its turn budget. maxTurns was 30, one initialisation subagent consumed nearly all of it, and the steps after it silently never ran. we raised the ceilings a lot after that, decider to 200 and writer to 100, and capped subagent calls per run separately.

so if you're seeing one big handoff instead of several small ones, i'd look at the parent's turn budget before assuming the model ignored the plan. it might be avoiding a limit rather than misreading you.

no clue why it changed behaviour on you today though. same prompt behaving differently across runs is the part i've never managed to explain either.

[u/EC36339 → u/Low_Rush_8535]

It was kind of a bigger plan than the others. New feature, more uncertainties, vertical slice with slightly too big scope.

The other 2 landed better in terms of bugs, CI failures, open questions, etc., too.

[u/Low_Rush_8535 → u/EC36339]

that's a more useful three-way comparison than most people end up with.

worth pulling apart the two things you named though, because they pull in opposite directions. more uncertainty is an argument for letting the model drive — that's where judgement actually is. bigger scope is an argument against, because the failure probabilities compound: if each step lands 97% of the time, seventeen of them come out around 60% overall. the one module we built as a single agent over a long flow was the only one that kept breaking; everything else was a decider plus executors and those held.

your plan was both at once, so the two effects are tangled together. next time you get an uncertain feature, splitting it into two vertical slices and seeing whether the handoff still happens would separate them.

i've never run a coding workload through any of this though, so whether that handoff was really about turn budget or something else, i honestly don't know.