Summary

• Traced two production incidents (Aspire/Zach, Adapt/Jacob) to a sequential on-event dispatch chain , crm-updater → strategist → next-steps → inbound-email-notifier, each a separate LLM sub-agent call run one after another. In the traced Adapt run this took 3m16s end to end, slower than the rep's own 2m47s reply, so the notifier's Slack alert landed after he'd already handled it himself.
• None of {drafter, strategist, inbound-email-notifier} depends on either of the other two's output. The AI SDK's tool executor already runs every tool call returned in one model turn concurrently (Promise.all), so this is a prompt change, not new infrastructure: crm-updater still runs first alone (it can trigger a stage transition), next-steps still runs last alone (it needs to see what drafter/strategist produced), and the three independent subagents now dispatch together as simultaneous tool calls in between. This is a fixed, hardcoded exception for exactly these three names, not a general "batch anything independent" heuristic the model has to judge on its own.

Validation

New eval harness (apps/server/.claude/skills/playbook-instruction-eval/parallel-dispatch-eval.ts), run against claude-sonnet-5, 8 trials per variant, reconstructing the real prior prompt via anchor-based extraction (not retyped) so the baseline comparison is faithful:

Worth noting: the baseline already batches tool calls unpredictably 6/8 of the time (mostly next-steps + inbound-email-notifier together) , just never in a sanctioned or tested combination. This change replaces that unintentional behavior with a deliberate, validated one, not just a latency fix.

Also refreshed fixtures/on-event-orchestrator-instructions.md, which had drifted from the live orchestrator file (still referenced a retired run-post-event-executor tool call from before the drafter-dispatch refactor) and would have silently invalidated any eval run against it.

Test plan

• pnpm --filter @zero/server run types clean on the changed file
• New eval: 8/8 trials show the correct parallel batch with zero unsafe inclusions, vs 0/8 on baseline
• Deploy to staging and watch a live email-triggered execution's tool-call trace to confirm the batch actually lands in prod (not just in the eval harness)

Follow-up (separate PR, in progress)

• Backfill migration to reorder strategist/next-steps to the tail of each account's <trigger type="any"> playbook text, so the documents themselves describe this order (not required for correctness , this prompt change already overrides text order for these names , but requested so the docs stop describing a sequence that isn't what happens)
• Live-thread re-validation gate (the stale-context/duplicate-draft half of the same investigation)

🤖 Generated with Claude Code

https://claude.ai/code/session_01WDwXHeMTJKLmcSjj1msiuS

Greptile Summary

This PR changes the event orchestrator prompt so CRM updates complete first, drafter/strategist/notifier calls run concurrently, and next-steps runs afterward. It also adds a model-based evaluation and refreshed prompt fixture.

• Reduces notification latency by batching three nominally independent subagents.
• Preserves CRM stage-transition handling before the batch and next-step reconciliation afterward.
• Introduces a reachable duplicate-draft race when both drafting-capable siblings run concurrently.
• The evaluation needs stricter required-agent assertions and a reliable connection to the production prompt.

Confidence Score: 4/5

The PR is not safe to merge until concurrent drafting is arbitrated atomically and the explicit type-assertion rule violation is resolved.

The parallel batch can make the drafter and notifier pass the e