Summary

Full open-weight ("oss") workload segmentation across Cedar's automation tasks , per the Aamir/Isabelle Slack thread and follow-up design work. services/llm/oss-tasks.ts is the single registry (23 tasks, 14 PostHog flag groups); every task listed there now has real routing, gated by isOssFlagEnabled(OSS_TASKS[task].flagGroup, userId) resolved alongside each call site's existing feature flags.

Foundation (unchanged from the original PR):

• services/llm/oss-tasks.ts , the one place a task's default/oss Understudy workload pair and PostHog flag group are declared.
• isOssFlagEnabled (posthog.ts) , the one place a flag group becomes a real PostHog key (cedar-oss-<group>).
• agent_executions.llm_calls (jsonb) , one entry per underlying LLM call (correlation id, workload, model), appended atomically via services/agent-action-queue/llm-calls.ts.

Oneoffs , event-summarization.ts, company-domain-assignment.ts (domain identification), aop-selection.ts, stage-classification.ts (services/crm/ , no per-request userId available on this backfill path, so the flag check uses a fixed 'system' identity), on-event-email-orchestrator (M1) + a new on-event-meeting-orchestrator oss variant, drafter (M2).

Orchestrator / chat / analyzer , orchestrator-agent.ts (+ createOrchestratorAgentOss, wired in execute-orchestrator.ts), chat-agent.ts (+ chatAgentOss/chatAgentOssFamilies, wired across its 5 call sites: sms/slack/imessage bot chat, chat-workflow.ts, operation-registry.ts), analyzer-agent.ts (+ createAnalyzerAgentOss, wired in execute-analyzer.ts).

Tier 3 renames (workload identity, not just a label) , conversation-field-updater→crm-updater, conversation-field-updater-haiku→crm-updater-haiku, strategist-updater→strategist, next-steps-tasks→next-steps. Code and the real Understudy workloads (renamed via CLI) both updated; new -oss workloads created for all four.

Tier 4 , automation-agent.ts gets per-pattern oss singletons (via a createAutomationAgentOss factory) for the 6 named defaults that were sharing the generic automation workload (meeting-prep, daily-agenda, pipeline-review, coach-meeting, coach-weekly, inbound-email-notifier) plus strategist's scheduled/cron path, and a custom-subagent-oss variant for the long tail of arbitrary user-authored subagents. Wired into automations.ts's runAutomationInProcess, which checks the oss flag before falling back to the older flat MODEL_EXPERIMENT_PATTERNS/automationAgentSol experiment (kept, not deleted, as the pre-oss fallback). automationAgent/automationAgentUnderstudy deliberately keep their existing automation workload name rather than renaming to custom-subagent , it's the platform's highest-volume workload, and that rename needs its own sign-off (see Open questions).

Every new static Agent singleton is registered on the root Mastra instance in mastra/index.ts.

Deliberately not in this PR

• taxonomy-field-values/taxonomy-judgments , these already have -glm/-kimi per-model Understudy workloads from an earlier, separate experiment. -oss workloads/flags exist (created, inactive/0%) but nothing is wired to them, to avoid conflicting with that existing convention.
• Renaming automation→custom-subagent , see Open questions below.
• org_id/user_id/segment_id as literal Understudy request headers on the static Agent singletons , their model is fixed at module-load time with no per-request context threading today. Metadata is captured in llm_calls instead, which is request-scoped.

Real bugs found and fixed while wiring this in

• Meeting-path telemetry mislabeling (M1): the orchestrator's logPromptCacheUsage call hardcoded workload: 'on-event-email-orchestrator' regardless of which branch ran, silently mislabeling every meeting-triggered call. Pre-existing, not introduced by this PR. Fixed by deriving the wor