diff --git a/activity-definitions/daily-statehub-wsjf-triage.md b/activity-definitions/daily-statehub-wsjf-triage.md
index 7171cb3..d0f85d2 100644
--- a/activity-definitions/daily-statehub-wsjf-triage.md
+++ b/activity-definitions/daily-statehub-wsjf-triage.md
@@ -90,7 +90,12 @@ human-readable report.
 id: daily-triage-report
 trusted_fields:
   - context.daily_triage_digest
-model: gpt-5.2
+model: custodian-triage-balanced
+temperature: 0.2
+max_tokens: 1400
+max_depth: 2
+model_params:
+  reasoning_effort: medium
 prompt: |
   Produce the Daily State Hub WSJF triage report from this curated digest.
 
@@ -150,6 +155,25 @@ Daily triage may recommend but must not execute:
 - security posture changes without an explicit approval path
 - canon promotion
 
+## LLM Backend And Depth
+
+The model backend for this activity is `llm-connect`. activity-core passes the
+instruction's `model`, `temperature`, `max_tokens`, `max_depth`, and
+`model_params` values through the llm-connect HTTP boundary; provider choice,
+API keys, model routing, and local-vs-remote backend policy stay behind that
+boundary.
+
+This definition starts with a balanced daily-triage profile:
+
+- `model: custodian-triage-balanced`
+- `max_depth: 2`
+- `model_params.reasoning_effort: medium`
+
+Tune these values from observed report quality during the three-run calibration
+in `CUST-WP-0044`. Especially critical cases, such as very high gain combined
+with high effort, may later use a deeper llm-connect profile or deterministic
+pre-scoring without changing the scheduling substrate.
+
 ## Notes
 
 This file lives in `the-custodian/activity-definitions/` because the
diff --git a/workplans/CUST-WP-0045-activity-core-daily-triage-runner.md b/workplans/CUST-WP-0045-activity-core-daily-triage-runner.md
index 758b5e3..1e9436b 100644
--- a/workplans/CUST-WP-0045-activity-core-daily-triage-runner.md
+++ b/workplans/CUST-WP-0045-activity-core-daily-triage-runner.md
@@ -4,7 +4,7 @@ type: workplan
 title: "Activity-Core Daily Triage Runner Cutover"
 domain: custodian
 repo: the-custodian
-status: blocked
+status: active
 owner: custodian
 topic_slug: custodian
 planning_priority: high
@@ -237,13 +237,10 @@ paused Temporal schedule while disabled.
 
 ```task
 id: CUST-WP-0045-T06
-status: blocked
+status: in_progress
 priority: high
 depends_on: [CUST-WP-0045-T05]
 state_hub_task_id: "545162d7-0198-4519-a30b-06e88c6db915"
-blocking_reason: "Needs an approved non-external LLM path for private State Hub digest data, or explicit operator approval for the external llm-connect backend."
-needs_human: true
-intervention_note: "Real cutover needs an approved non-external LLM path for private State Hub digest data, or explicit human approval for the external llm-connect backend after review."
 ```
 
 Run the cutover safely.
@@ -372,12 +369,30 @@ no State Hub digest data left the workstation:
   `memory/working/daily-triage-2026-05-19-2164cb88.md`
 - State Hub progress event: `e42c0ada-8111-4d88-9791-821252cd04a2`
 
-The real Claude-backed llm-connect trigger was not run. The execution wrapper
-blocked it because private State Hub workstream/task digest data would be sent
-to an external LLM provider. Therefore the Codex app automation remains the
-only enabled runner, the ActivityDefinition remains `enabled: false`, and T06
-is blocked until there is either an approved local/private LLM backend or an
-explicit operator decision to allow that external data flow.
+The real Claude-backed llm-connect trigger was not run in that pass. The
+execution wrapper blocked it because private State Hub workstream/task digest
+data would be sent to an external LLM provider. The operator then clarified that
+`llm-connect` is the intended backend boundary for LLM providers and depth
+tuning. Follow-up implementation keeps that boundary explicit: activity-core
+passes model/depth configuration through llm-connect, provider routing remains
+inside llm-connect, and the ActivityDefinition declares a balanced
+`custodian-triage-balanced` profile for calibration.
+
+The llm-connect depth path is now reusable instead of daily-triage-specific:
+
+- activity-core `InstructionDef` accepts `temperature`, `max_tokens`,
+  `max_depth`, and `model_params`
+- activity-core sends those values to llm-connect as `RunConfig`
+- llm-connect server mode now preserves the full `RunConfig` via
+  `RunConfig.from_dict`
+- the daily triage ActivityDefinition starts with
+  `model: custodian-triage-balanced`, `max_depth: 2`, and
+  `model_params.reasoning_effort: medium`
+
+Remaining T06 work is now operational cutover: run the real llm-connect backend
+selected by the operator, verify real report quality, pause Codex automation,
+set the ActivityDefinition to `enabled: true`, sync schedules, and check the
+next 07:20 run.
 
 Verification:
 
@@ -396,6 +411,15 @@ Verification:
 - activity-core full suite after T06 fixes:
   `uv run pytest -q`:
   110 passed, 1 skipped
+- activity-core llm-connect depth pass-through full suite:
+  `uv run pytest -q`:
+  114 passed, 1 skipped
+- llm-connect focused server validation:
+  `uv run pytest tests/test_server.py -q`:
+  10 passed
+- llm-connect full suite:
+  `PYTHONPATH=. uv run pytest -q`:
+  173 passed
 
 ## Acceptance Criteria