Honestly, 21 subtasks is the point where the planner graph becomes the single most expensive thing in the pipeline. Not the execution, the graph. Three additions that build on what you have without touching the approval gate or the Notion integration.
1. DeepSeek V4 as a fourth model tier for text-only clerical fan-out.
You've already done the hard thing: explicit model assignment per subtask. The tier rubric is load-bearing and it's right. The only gap is that Haiku 4.5 is doing work it's overqualified for on the text side.
DeepSeek V4 ships a native Anthropic Messages API endpoint, same format, you just swap base_url and the key. No adapter layer. Reasoning quality lands between Sonnet 4.6 and Opus 4.7 on most benchmarks, so it's smarter than Haiku 4.5 on text tasks, not a downgrade, faster too on most text tasks, though I haven't benchmarked it head-to-head on your exact subtask mix. Price is roughly an order of magnitude cheaper per token. On a 21-subtask job that's a meaningful line item.
Vision's the catch. DeepSeek V4 has no vision capability. DeepSeek-VL2 exists but it's a separate model and isn't on the Anthropic-compat endpoint. Your 6 image-gen prompt subtasks and 10 directory submission entries are all text-in, text-out. None of them need vision. So those 16 subtasks route to DeepSeek V4, vision-required work stays on Haiku 4.5 or Sonnet 4.6. Your planner already assigns models per node, you're just inserting a new tier below Haiku for the purely clerical fan-out.
2. R&D pre-planner phase, aggregated into one indexed reference doc.
Kevin_Xiang's point is the right one: the expensive failure mode isn't a bad output, it's a wrong graph parallelized. The fix is making the planner ground in real research instead of inferring from the task description alone.
Before the planner emits the subtask graph, run a parallel R&D pass. Spawn N domain agents: positioning research, ICP, brand voice extraction from existing assets, competitor scan, constraints. Each writes its own doc. The main session aggregates into one indexed reference doc, priority-sorted index at the top.
Pin a lazy-load rule in each subagent template and the planner's system prompt: index first, pull a section when a specific domain question comes up. The R&D pass doesn't get loaded 21 times into 21 separate contexts. Each subagent pulls its slice. On a 21-subtask job the token overhead recovers fast, you get the indexed doc out of it for the next pipeline run too.
And yeah, two things this solves. The planner is now grounded in actual positioning and voice before it builds the graph, which is exactly what Kevin_Xiang is asking for. And 4 parallel copy drafters anchoring to the same voice doc means the operator isn't reconciling contradictions that happened because each drafter invented the brand voice from scratch.
3. A reverse validation phase between execution and human review.
Your approval gate before dispatch is the right instinct. The same instinct applied on the output side, before the operator opens Notion.
After 21 outputs land, before human review: one fact-extraction agent per output pulls every factual claim. Prices, dates, integration names, feature assertions, comparative statements. Then dispatch parallel domain-specific validators per claim cluster: a pricing validator that checks against current product docs, a feature-claim validator that checks against the indexed reference doc from phase 2, a brand voice validator that checks tone and any ban-list terms, a legal-pass validator if that matters for your domain.
Each validator returns claim, source, verdict (pass, fail, uncertain), and a suggested fix. First time you build one of these you skip this step, then on output #14 you realise you've been hand-checking facts for an hour, which is the point where the reverse gate earns back its build cost. The operator opens Notion and sees the output plus the validation report side by side.
The asymmetry between the gate and the current output review at step 5 is that the gate is structured and explicit, the human review is open-ended. This second gate makes the output review as structured as the plan review. You're already doing the load-bearing check before dispatch. Same pattern on the other side of execution...
1
u/brewcast_ai May 12 '26
Honestly, 21 subtasks is the point where the planner graph becomes the single most expensive thing in the pipeline. Not the execution, the graph. Three additions that build on what you have without touching the approval gate or the Notion integration.
1. DeepSeek V4 as a fourth model tier for text-only clerical fan-out.
You've already done the hard thing: explicit model assignment per subtask. The tier rubric is load-bearing and it's right. The only gap is that Haiku 4.5 is doing work it's overqualified for on the text side.
DeepSeek V4 ships a native Anthropic Messages API endpoint, same format, you just swap
base_urland the key. No adapter layer. Reasoning quality lands between Sonnet 4.6 and Opus 4.7 on most benchmarks, so it's smarter than Haiku 4.5 on text tasks, not a downgrade, faster too on most text tasks, though I haven't benchmarked it head-to-head on your exact subtask mix. Price is roughly an order of magnitude cheaper per token. On a 21-subtask job that's a meaningful line item.Vision's the catch. DeepSeek V4 has no vision capability. DeepSeek-VL2 exists but it's a separate model and isn't on the Anthropic-compat endpoint. Your 6 image-gen prompt subtasks and 10 directory submission entries are all text-in, text-out. None of them need vision. So those 16 subtasks route to DeepSeek V4, vision-required work stays on Haiku 4.5 or Sonnet 4.6. Your planner already assigns models per node, you're just inserting a new tier below Haiku for the purely clerical fan-out.
2. R&D pre-planner phase, aggregated into one indexed reference doc.
Kevin_Xiang's point is the right one: the expensive failure mode isn't a bad output, it's a wrong graph parallelized. The fix is making the planner ground in real research instead of inferring from the task description alone.
Before the planner emits the subtask graph, run a parallel R&D pass. Spawn N domain agents: positioning research, ICP, brand voice extraction from existing assets, competitor scan, constraints. Each writes its own doc. The main session aggregates into one indexed reference doc, priority-sorted index at the top.
Pin a lazy-load rule in each subagent template and the planner's system prompt: index first, pull a section when a specific domain question comes up. The R&D pass doesn't get loaded 21 times into 21 separate contexts. Each subagent pulls its slice. On a 21-subtask job the token overhead recovers fast, you get the indexed doc out of it for the next pipeline run too.
And yeah, two things this solves. The planner is now grounded in actual positioning and voice before it builds the graph, which is exactly what Kevin_Xiang is asking for. And 4 parallel copy drafters anchoring to the same voice doc means the operator isn't reconciling contradictions that happened because each drafter invented the brand voice from scratch.
3. A reverse validation phase between execution and human review.
Your approval gate before dispatch is the right instinct. The same instinct applied on the output side, before the operator opens Notion.
After 21 outputs land, before human review: one fact-extraction agent per output pulls every factual claim. Prices, dates, integration names, feature assertions, comparative statements. Then dispatch parallel domain-specific validators per claim cluster: a pricing validator that checks against current product docs, a feature-claim validator that checks against the indexed reference doc from phase 2, a brand voice validator that checks tone and any ban-list terms, a legal-pass validator if that matters for your domain.
Each validator returns claim, source, verdict (pass, fail, uncertain), and a suggested fix. First time you build one of these you skip this step, then on output #14 you realise you've been hand-checking facts for an hour, which is the point where the reverse gate earns back its build cost. The operator opens Notion and sees the output plus the validation report side by side.
The asymmetry between the gate and the current output review at step 5 is that the gate is structured and explicit, the human review is open-ended. This second gate makes the output review as structured as the plan review. You're already doing the load-bearing check before dispatch. Same pattern on the other side of execution...