Skip to main content

Day 2 — Verticals Platform — Main Orchestrator Handoff

You are the main orchestrator agent picking up the verticals-first voice agent platform build. Day 1 (foundation) is complete and pushed. Today (Day 2) you spawn 4 parallel Sonnet subagents in worktrees, each working on an independent surface. Tomorrow (Day 3) you integrate, verify, and ship.

This document is your one-stop handoff. Read it through once, then read the artifacts it links, then spawn the 4 agents.

Your model and role​

You should run as Opus (reasoning + integration + judgment). Each of the 4 subagents you spawn should run as Sonnet (assembly + writing + clear-spec'd builds). This matches the founder's stated routing memory: "Opus for reasoning/debugging/decisions, Sonnet for assembly/writing/formatting" (memory/MEMORY.md).

Your job:

  1. Absorb context (this file + linked artifacts).
  2. Spawn 4 parallel Sonnet agents in worktrees.
  3. Babysit them as they complete (notifications arrive when each finishes).
  4. Day 3: review each PR, merge in dependency order, run verification, decide GO/NO-GO on cold-email batch.

The mission, in one paragraph​

ChurchWiseAI is shipping a verticals-first voice agent platform so that funeral homes (FuneralWiseAI), churches (ChurchWiseAI), and future verticals (vet, dental, restaurant, law, real estate) all run on the same shared infrastructure with vertical-flavored prompts/tools and a unified per-tenant Master Config. The trigger was a strategic decision to delay the FuneralWiseAI cold-email batch until live director-transfer is shipped — the competitive wedge against ASD Answering Service (~33% of US funeral homes, $150–300/mo, human pickup). Day 1 built the foundation: TenantConfig schema (Python + TS), vertical-agnostic core/transfer.py, two-track escalation taxonomy, isolated outbound SIP trunk, Master Config YAML system. Day 2 builds the four parallel surfaces (live transfer + chatbot, escalation split, vertical dashboards, Master Config UI). Day 3 verifies + ships. Cold-email batch sends end of Day 3 if all green.

Read these artifacts FIRST, in this order​

Skim them in this order before spawning anything:

  1. The locked plan — C:/Users/johnm/.claude/plans/steady-munching-penguin.md

    • The master plan. Architecture decisions, the 5-layer model, what Day 1 shipped, the 3 v1 additions from competitor research, the Day 1 saga (saga = recovery from livekit/agents#3104), and the Day 3 verification checklist. The single source of truth.

  2. The original live-transfer plan — knowledge/decisions/2026-04-28-funeralwiseai-live-transfer-plan.md

    • Why live transfer is the wedge against ASD. The "killer demo" mechanic. The 8 sub-questions (resolved during Day 2 design, parameters of the architecture).

  3. Founder priority memory — memory/feedback_robustness_over_velocity.md

    • "To me, the better the demos and the more robust the product, the conversions will be way higher so it's worth spending a few days on it to get it right." This shapes every tradeoff: demo quality + robustness > velocity. Day 3 verification is exhaustive, not symbolic.

  4. The two danger memories — DO NOT REPEAT THE NEAR-MISSES:

    • memory/feedback_lk_overwrite_flag_destroys_secrets.md — lk agent update-secrets --overwrite nukes ALL existing secrets. Almost destroyed 22 prod secrets on 2026-04-28. NEVER use --overwrite to add a single secret. Use no-flag (silently appends).
    • memory/feedback_livekit_recovery_lk_deploy_only.md — When agent stuck in "shut down due to inactivity" and won't auto-wake, lk agent restart is INSUFFICIENT. Only lk agent deploy --project cwa-voice --silent from cwa-wt-sermonwise/voice-agent-livekit/ (after git pull --ff-only origin main) recovers. Known LiveKit bug: agents#3104.

  5. Master Config canonical docs — knowledge/voice-clients/README.md

    • YAML cascade rules, sync workflow, two-track escalation taxonomy. Day 2 worktree D builds the sync command + UI on top of this.

  6. Two research reports (skim, don't deep-dive):

    • tmp/research-livekit-outbound.md — explains why our Day 1 P0 happened + the Telnyx best-practice gotchas (X-Telnyx-Username header, sip_trunk_id="" doesn't default).
    • tmp/research-competitor-live-transfer.md — Bland/Vapi/Retell/ElevenLabs/ASD analysis. The 3 v1 additions came from this report.

Day 1 state — what's already in place​

ArtifactLocationWhat it is
Foundation branchfeat/verticals-platform-day1-foundation (origin)All Day 1 commits. Day 2 worktrees fork from this.
Pydantic TenantConfigvoice-agent-livekit/core/tenant_config.pySchema, adapters from church/funeral dicts.
TS TenantConfigsrc/lib/tenant-config.tsSame shape, mirrors Python.
Vertical-agnostic transfervoice-agent-livekit/core/transfer.pyExtracted from verticals/church/transfer_tool.py. NOT YET wired in production.
DB migration: outbound columnsApplied to prod Supabase 2026-04-28 (tenant_voice_agents columns + crisis_events table)New columns: transfer_target_number, transfer_enabled, transfer_business_hours_only, business_hours, response_time_promise_text, transfer_ring_seconds, bridge_intro_template, crisis_contact_phone, crisis_resources_locale. New table: crisis_events with constraints + indexes + RLS.
Telnyx outbound credential connectionID 2948197312620398250 ("CWA Verticals Platform Outbound")Separate creds from inbound. Outbound voice profile attached.
LiveKit outbound trunkST_X3n9jxR55VrBAddress sip.telnyx.com, FROM +14697288326, isolated from protected inbound ST_Xa3Bp9aixRFP.
OUTBOUND_TRUNK_ID LiveKit secretSet on agent CA_pX3Me4NK6qK8Secret count: 23 (was 22, +1 new).
Voice clients YAML systemknowledge/voice-clients/{_schema.yaml,_defaults/{church,funeral}.yaml,README.md}Canonical Master Config schema + vertical defaults.
Cleanupvoice-agent-livekit/verticals/funeral/agents.py deletedWas orphan code from PR #238 deprecated by PR #241.
Voice agent recoveredVersion MEs6uTJzn8JZ (was PsB7z6ss3m5S)Fresh deploy from origin/main on 2026-04-28T18:25:13Z. Test call to +13658253552 confirmed agent answering correctly.

What this build delivers (Day 2 scope)​

Four parallel worktrees. Each is independent at the file level (designed to minimize merge conflicts). Each agent runs Sonnet, branches off feat/verticals-platform-day1-foundation, opens a PR back to feat/verticals-platform-day1-foundation (NOT main), does NOT merge their own PR.

WorktreeSpec fileHeadline scope
A01-WORKTREE-A-live-transfer.mdWire core/transfer.py into church Coordinator. Funeral prompt + data updates. Demo-flip UI on /s/[slug]. + 3 v1 additions: auto-greet on pickup, user-facing wait message, hard crisis-flag contract test. + OUTBOUND_TRUNK_ID hard assertion + X-Telnyx-Username header. + chatbot request_callback tool.
B02-WORKTREE-B-escalation-split.mdcore/escalation.py split. flag_safety_event tool → crisis_events writes. Notification routing split (support@ always, optional crisis_contact_phone). Contract test for 100 simulator messages. CODEOWNERS gate.
C03-WORKTREE-C-vertical-dash.mdVerticalProfile registry. funeralwiseai.com/admin/[token] middleware rewrite. Funeral tab shells. Inbox tab vertical-aware.
D04-WORKTREE-D-master-config.md/founder/[token]/voice-clients/[id] UI. pnpm sync-voice-clients script (YAML ↔ DB). Seed YAML for existing customer churches + funeral demo.

How to spawn the 4 agents​

Use the Agent tool with subagent_type: "voice-agent-engineer" for A and B (touches voice-agent code + life-safety paths), subagent_type: "general-purpose" for C and D (mostly Next.js + scripts). All four use model: "sonnet" and isolation: "worktree" and run_in_background: true.

The prompt for each is the contents of the matching spec file (01–04). Spawn all 4 in a single message with multiple Agent tool calls so they run concurrently.

Pseudo-code:

Agent({
  description: "Day 2 Worktree A — live transfer + 3 v1 additions",
  subagent_type: "voice-agent-engineer",
  model: "sonnet",
  isolation: "worktree",
  run_in_background: true,
  prompt: <contents of 01-WORKTREE-A-live-transfer.md>
})
// + 3 more in same message for B, C, D

Important: the spec files are SELF-CONTAINED. The agent has zero conversation history. Don't shorten them.

After spawning — what you do while they work​

Each subagent reports back with a PR URL + commit SHA + summary when done. Notifications arrive in your chat as they complete.

While they're working:

  • DO NOT modify the same files they're modifying. Lookup the "FILES TO TOUCH" section in each spec to know which files are claimed.
  • You CAN: review research reports, prep Day 3 verification scripts, audit knowledge docs that need updating, clean up tmp/.
  • DO NOT: spawn additional agents on the same surfaces, push code to feat/verticals-platform-day1-foundation directly, merge anyone's PR before Day 3.

Day 3 — integration + verification​

When all 4 PRs are open, follow 05-DAY3-INTEGRATION.md. Headline:

  1. Merge PRs in dependency order: B (escalation-split) → A (live-transfer) → D (master-config) → C (vertical-dash).
  2. Apply any conflict resolutions; resolve via founder if non-trivial.
  3. Run pnpm sync-voice-clients --check in CI.
  4. Founder runs the 10-item live verification (6 voice + 4 chatbot per steady-munching-penguin.md Day 3 gate).
  5. Vertical-template acceptance test (stub a vet vertical end-to-end).
  6. Decision log entry written.
  7. GO/NO-GO on cold-email batch.

Hard rules (do not violate)​

These are codified in C:/dev/CLAUDE.md and the relevant memory files. Reading them again so you don't drift:

  1. NEVER touch ST_Xa3Bp9aixRFP (the protected inbound SIP trunk). Outbound work uses the new ST_X3n9jxR55VrB.
  2. NEVER use lk agent update-secrets --overwrite to add a single secret. The flag nukes ALL existing secrets.
  3. NEVER use lk agent restart to recover a stuck agent. Use lk agent deploy --project cwa-voice --silent from cwa-wt-sermonwise/voice-agent-livekit/ after pulling origin/main.
  4. NEVER deploy the voice agent without (a) explicit founder approval AND (b) the founder being present to test live calls. Per memory/feedback_voice_agent_locked.md.
  5. NEVER write junk test data to production Supabase. There is no staging DB. Every query hits prod. Use the demo church UUID 00000000-0000-4000-a000-000000000001 for testing.
  6. NEVER force-push a branch. Multi-agent git safety: always git fetch + git pull --rebase before push.
  7. NEVER merge a worktree's own PR. Day 3 integration is the merge step, run by you (the orchestrator) under founder supervision.
  8. Crisis events NEVER attempt a SIP bridge. Crisis routing is 988/911/DV hotline + support@ + optional crisis_contact_phone SMS only. This is the founder's explicit architectural decision; live-bridging a crisis is a life-safety regression.
  9. Verify DB columns before use. mcp__plugin_supabase_supabase__execute_sql to check information_schema.columns BEFORE assuming a column exists. Per feedback_verify_db_columns.md.
  10. No code without expected-output specs. Per CLAUDE.md rule #17. Worktree D's seed YAML files are the spec for what each tenant's config must look like.

Cold-email batch — do NOT send​

The FuneralWiseAI cold-email batch is HELD until Day 3 verification is fully green. Founder owns the GO/NO-GO. Do not touch anything in the outreach pipeline (/founder/[token]/outreach-engine etc.) during Day 2.

Communication style​

You report briefly to the founder when:

  • All 4 agents are spawned (one summary message).
  • Each agent completes (one summary per agent, ≤200 words).
  • A subagent hits a blocker (escalate immediately).
  • Day 2 is fully complete and ready for Day 3 review.

Don't pile on commentary between subagent completions. The founder reads the summaries and reacts.

When you're done with this document​

  1. Confirm you've read all 6 linked artifacts.
  2. Confirm git state in your worktree (git status should be clean, on a session branch).
  3. Confirm the 4 spec files exist (01–04) and are non-empty.
  4. Spawn the 4 agents per "How to spawn the 4 agents" above.
  5. Report to founder: "All 4 Day 2 worktrees spawned (A/B/C/D). Reporting back on each completion."

You're cleared to start. Good luck.