Multi-tenant program management: per-user stateful programs with reactive + proactive control

[vybe]

Summary

Let an agent run a structured, stateful program for each of many users in a multi-tenant fashion — each user enrolled in their own program, progressing through stages over days/months/years. The agent advances a user's program both reactively (in conversation) and proactively (scheduled program reviews + playbook-driven updates pushed to the user's channel). Per-user program state ("user memory") lives in Trinity, not inside the agent, so it survives reset/redeploy/deletion and can move between agents.

Context

Generalizes the existing per-user memory primitive (MEM-001, #888) from a flat blob to structured, stage-aware program state. Multi-user channel access (Slack/Telegram/WhatsApp/web), verified-email identity (#311), proactive messaging, and capacity-gated dispatch already exist; this composes them into a program engine. Preferred implementation is a purpose-built native (non-Docker) runtime rather than per-agent Claude Code logic — see #1206.

Acceptance Criteria

• Data model: programs (definition: stages, per-stage skill, review cadence, advance criteria), program_enrollments (one per user per program: current_stage, status, next_review_at, state_json), program_events (append-only per-user timeline)
• Reactive path: extend the message_router injection seam to load + inject a user's program context into the execution at conversation time
• Proactive path: a due-date sweep service that finds enrollments due for review and dispatches one execution per user carrying that user's context; agent advances/nudges/escalates and messages the user on their originating channel
• Control surface: enroll_user, get_program_enrollment, update_program_state, advance_program_stage, list_enrollments (cohort), record_program_event
• Operator "Programs" view: cohort funnel (users per stage), stalled/overdue list, per-user timeline
• Identity keyed on verified email; auto-enroll on first verified contact gated by access policy
• Cost controls at scale: staggered next_review_at, capacity backpressure, model tiering (cheap routine reviews, escalate on state change)

Technical Notes

• Builds on MEM-001 per-user memory (POST /api/agents/{name}/user-memory, security: Agent writes public-link user PII to shared agent memory, leaking it to all other users #888) and channel verified-email resolution (feat: Unified channel access control — verified-email identity, per-agent allow-list, access requests (web / Telegram / Slack) #311)
• Three-layer: routers/programs.py -> services/program_service.py -> db/programs.py; schema in src/backend/db/schema.py
• Proactive sweep modeled on existing background loops (cleanup/monitoring); admit through capacity_manager
• One execution per due user (clean per-user context + per-user cost/observability), not batched
• Preferred runtime: the non-Docker native runtime researched in Research: pluggable non-Docker agent runtime (decouple agent from container) #1206 — Trinity owns identity/state/scheduling/delivery, the runtime owns judgment