Summary

Strategist runs on the same event cadence as crm-updater and next-steps but costs ~4x more per run (avg 9.0 tool calls vs. crm-updater's 2.16 and next-steps' 3.22, measured against 3 days of production execution logs), because it falls through to the generic automation-agent path instead of having a dedicated dispatch tool like its two siblings. Separately, production logs showed statusOverview and nextSteps , two core CRM fields with no ownership concept , being independently overwritten by all three agents on the same triggering events, discarding real work.

This bundles four changes:

1. Prompt-cache telemetry , logPromptCacheUsage() added to crm-updater's and next-steps' existing generate() calls. Zero per-subagent cache-hit visibility existed anywhere before this (the one existing call site only covers the top-level orchestrator).
2. Dedicated strategist dispatch tool (strategist-updates.ts) , mirrors crm-updater's conversation-field-updates.ts: structural pre-LLM guards (missing context, disabled frontmatter), a new deterministic noise-skip (Cedar's own delivery-failure alert emails, bare calendar RSVPs , gated on the email's actual body/snippet rather than classification presence, so an unclassified-but-real reply never false-skips), context hydration replacing four forced read tool calls, 3-layer Anthropic prompt-cache breakpoints, maxSteps 50→15, and its own tool allowlist (STRATEGIST_TOOLS).
3. Relevance-gate prompt instruction , a new step 0 in strategist's prompt: judge from the hydrated triggering event alone whether it's capable of moving the deal before doing any reads; biased conservatively toward proceeding when ambiguous ("clearly nothing," not "probably nothing").
4. Core field ownership , extends the existing (previously custom-fields-only) ownership mechanism to statusOverview (→ crm-updater) and nextSteps (→ next-steps), matching each field's plurality writer in production and each agent's stated job. Wires agentId propagation through every caller of the shared ownership-check path , including the compose-send flow (handleExecuteFromClientSend.ts), which a first review pass had missed and would otherwise have been silently locked out of statusOverview once ownership is stamped. Includes a backfill script (rollout-core-field-ownership.ts) since seed-time stamping alone only protects accounts created going forward , the accounts actually racing today need it run explicitly.

Review

Ran both thermo-review and /review against this diff. Findings and resolutions:

• /review: found the handleExecuteFromClientSend.ts missing-agentId regression (fixed), a false-skip risk in the RSVP noise guard where emailClassification's async timing could catch a real reply mid-flight (fixed , now gated on the email's snippet instead, which is set synchronously at ingest), and a stale comment (fixed).
• thermo-review: no blocking findings. Flagged the missing backfill path (fixed , see above) and that both the new and an existing precedent ownership-stamper resolve subagents by user-editable display name rather than filename, so a renamed agent silently never gets ownership stamped , this is inherited from the existing stampStrategistOwnership precedent, not introduced here, so left as a known follow-up rather than expanding this PR's scope.

Open questions for reviewers

• statusOverview → crm-updater was a deliberate choice against the raw production frequency (strategist is actually the plurality writer, 45.4% vs. crm-updater's 40.6%) , flagging in case anyone wants to weigh in before merge.
• maxSteps: 15 , production median was 9, but observed max was 33. If the high end represents legitimate complex-deal work rather than runaway loops, this could start truncating real output. Can't be settled by static review; worth watching on canary.

Test plan

• pnpm --filter @zero/server run types , 0 errors
• pnpm deps:check ,