The AI Community Manager drafts member-facing messages and moderation actions for you to review and approve. Nothing it produces sends until you click Approve in /admin/community-manager. This page is the reference for what it does, where it runs, and how to control it.
For the trigger/condition/action rules engine (a separate system that wires events to actions like add_badge and send_dm), see the automation pages under /admin/automation.
What it does
The Community Manager (CM) watches your community for six signal types and drafts one of six artefact types in response. Every draft lands in an approval queue. You read it, you edit it if you want, you approve or reject it. Approved drafts post as DMs, forum threads, forum replies, or moderation actions. Rejected drafts never send.
Internal codename: mobieusCore. Customer-facing name: AI Community Manager.
Draft kinds
The CM ships six draft kinds. Each one has its own trigger, its own destination, and its own opt-in flag.
| Kind | Triggered by | What it produces | Posts to (target_kind) |
|---|---|---|---|
welcome |
A new member registers (user.registered event) |
A short personal welcome DM | DM to the new member (user) |
weekly_summary |
Once per ISO week (hourly schedule cron emits a dedup'd event) | A health snapshot of the past week: new joins, active threads, flagged signals | New thread in the admin-only "Community Manager Reports" forum (tenant) |
churn_reengagement |
The engagement scorer flags a member as at-risk | A re-engagement DM tailored to the member | DM to the at-risk member (user) |
meet_suggestion |
The pair matcher finds two members with shared interests + co-activity | A one-way intro DM naming the other member by username | DM to one member (user_pair, sent to the lower user id; the other member is named in the body) |
forum_reply |
The reply scanner finds an unanswered thread that fits known patterns | A drafted reply to the thread | Reply on the original thread, authored by the Support user (thread) |
moderation_assist |
A member files a report (report.created event) |
A recommended action (dismiss, warn, hide, suspend, escalate) with reasoning and any member-facing messages | Moderation action against the reported content, logged to /admin/moderation (report) |
Every draft carries a stable dedup key, so the same event firing twice never creates two drafts for the same target.
Human in the loop (HITL)
The CM cannot send anything on its own. Only one function in the whole code base can flip a draft to sent: Dispatcher::executeApproved(). That function requires:
- A draft in
pending_approvalstatus (the worker put it there after generation) - The id of the admin pressing Approve
- A valid CSRF token on the request
A static-grep test (HumanInTheLoopTest) walks the source tree on every CI run and fails the build if any other file writes cm_draft.status = 'sent'. The allowlist is one file: Dispatcher.php. If you ever add a second writer, CI breaks loudly.
This means: no generator, no worker, no cron job, no event handler can send. They can only enqueue and draft. You are the gate.
BYOK: bring your own Anthropic API key
The CM has no Mobieus-side API key. You supply your own Anthropic key at /admin/community-manager/settings. Until that key is set, the CM is closed and produces no drafts and makes no API calls.
This is enforced at the lowest layer. The Spine gate checks three things in order:
- Master flag
ai_community_manager_enabledis on - Your plan is Pro, Creator Plus, or Sovereign
- Your Anthropic API key is configured
Any one closed, the whole CM is off. The admin UI shows you which gate is closed.
You pay Anthropic directly. The CM logs token counts and computes cost in micro-USD per draft so you can see what you spent.
Tier gate
The CM is available on Creator Plus and Sovereign plans. Lower-tier plans do not have access.
Cron schedule
Five workers run on the platform host. Each fans out across active tenants. Each worker re-checks the spine per tenant, so a tenant with the CM off pays zero token cost.
| Worker | Schedule | What it does |
|---|---|---|
process-cm-queue |
Every minute | Drains pending_inference drafts. Runs the matching generator. Persists the body. Flips the draft to pending_approval so it shows up in your queue. Bounded at 10 drafts per tenant per tick. |
process-cm-schedule |
Hourly (:00) |
Emits the synthetic schedule.weekly.summary event once per ISO week per tenant. The Dispatcher subscribes and enqueues one weekly_summary draft. Idempotent across all 168 hourly ticks per week. |
process-cm-engagement |
Hourly (:15) |
Recomputes engagement scores for members active in the last 90 days. Flags at-risk members. Enqueues up to 5 new churn_reengagement drafts per tenant per hour. |
process-cm-matching |
Every 6 hours (:30) |
Recomputes pair compatibility across active members. Persists candidates to cm_suggestion. Enqueues up to 3 new meet_suggestion drafts per tenant per run. |
process-cm-reply-scan |
Every 2 hours (:45) |
Scans active forums for unanswered threads matching reply patterns. Enqueues up to 2 new forum_reply drafts per tenant per scan. |
All five log to /var/log/mobieus/cm-*.log on the platform host.
Cost tracking
Every successful generation writes one row to ai_usage_log and copies the cost onto the draft row as cost_micros (1 USD = 1,000,000 micros).
Three things are visible to you at /admin/community-manager:
- Per-draft cost: shown on every draft card with token counts (
input_tokens/output_tokens) - 30-day rolling total: shown in the stat strip at the top of the queue
- Per-generator breakdown: each draft's
featuretag (e.g.cm.welcome,cm.weekly_summary) is queryable inai_usage_log
The CM uses Anthropic's published per-token rates. Pricing per model is hard-coded in InferenceClient::MODEL_PRICING_MICROS so cost is computed locally without a round-trip to Anthropic.
Opting in and opting out
The master flag turns the whole CM on or off. Six per-kind sub-flags let you enable just the parts you want:
| Sub-flag | Controls |
|---|---|
ai_cm_welcome |
Welcome drafts on new member join |
ai_cm_summary |
Weekly admin-only health summary |
ai_cm_churn |
Churn re-engagement drafts (engagement scorer must be enabled) |
ai_cm_suggest |
Meet-suggestion intro drafts |
ai_cm_forum_reply |
Forum reply drafts |
ai_cm_moderation |
Moderation recommendations on every report |
All six default to off. Toggle them at /admin/config under the AI group. Sub-flags are independent: you can run welcomes without moderation, summaries without churn, any combination.
A sub-flag is only checked once the spine is open. Turning on ai_cm_welcome without setting your Anthropic key does nothing.
Audit trail
Every state transition on every draft writes two audit rows:
- One row in
audit_log(the platform-wide HMAC-chained, tamper-evident audit chain) - One row in
cm_audit(CM-specific structured columns: draft id, event, actor, JSON detail)
cm_audit rows reference the audit_log row id and copy its integrity hash, so if anyone tampers with cm_audit the chain proves it.
Events that are recorded:
generated— worker produced a draft bodyapproved— admin clicked Approve, no editsedited_then_approved— admin edited the body before approvingrejected— admin rejected the draftsent— Dispatcher confirmed the artefact was deliveredsend_failed— delivery failed (network, downstream error)superseded— a newer draft replaced this one before approvalretried— worker retried a failed generation
You can view the full chain at /admin/community-manager/audit.
Where to learn more
- Queue and approve drafts:
/admin/community-manager - Settings (API key, per-kind toggles):
/admin/community-manager/settings - Audit trail:
/admin/community-manager/audit - Feature flags:
/admin/config(AI group) - Trigger/condition/action rules engine (a separate system):
/admin/automation
This page documents the AI Community Manager as shipped through Phase 6 (moderation_assist, 2026-05-29).
The **AI Community Manager** drafts member-facing messages and moderation actions for you to review and approve. Nothing it produces sends until you click Approve in `/admin/community-manager`. This page is the reference for what it does, where it runs, and how to control it. For the trigger/condition/action rules engine (a separate system that wires events to actions like `add_badge` and `send_dm`), see the automation pages under `/admin/automation`. --- ## What it does The Community Manager (CM) watches your community for six signal types and drafts one of six artefact types in response. Every draft lands in an approval queue. You read it, you edit it if you want, you approve or reject it. Approved drafts post as DMs, forum threads, forum replies, or moderation actions. Rejected drafts never send. Internal codename: mobieusCore. Customer-facing name: AI Community Manager. --- ## Draft kinds The CM ships six draft kinds. Each one has its own trigger, its own destination, and its own opt-in flag. | Kind | Triggered by | What it produces | Posts to (`target_kind`) | |---|---|---|---| | `welcome` | A new member registers (`user.registered` event) | A short personal welcome DM | DM to the new member (`user`) | | `weekly_summary` | Once per ISO week (hourly schedule cron emits a dedup'd event) | A health snapshot of the past week: new joins, active threads, flagged signals | New thread in the admin-only "Community Manager Reports" forum (`tenant`) | | `churn_reengagement` | The engagement scorer flags a member as at-risk | A re-engagement DM tailored to the member | DM to the at-risk member (`user`) | | `meet_suggestion` | The pair matcher finds two members with shared interests + co-activity | A one-way intro DM naming the other member by username | DM to one member (`user_pair`, sent to the lower user id; the other member is named in the body) | | `forum_reply` | The reply scanner finds an unanswered thread that fits known patterns | A drafted reply to the thread | Reply on the original thread, authored by the Support user (`thread`) | | `moderation_assist` | A member files a report (`report.created` event) | A recommended action (dismiss, warn, hide, suspend, escalate) with reasoning and any member-facing messages | Moderation action against the reported content, logged to `/admin/moderation` (`report`) | Every draft carries a stable dedup key, so the same event firing twice never creates two drafts for the same target. --- ## Human in the loop (HITL) The CM cannot send anything on its own. Only one function in the whole code base can flip a draft to `sent`: `Dispatcher::executeApproved()`. That function requires: - A draft in `pending_approval` status (the worker put it there after generation) - The id of the admin pressing Approve - A valid CSRF token on the request A static-grep test (`HumanInTheLoopTest`) walks the source tree on every CI run and fails the build if any other file writes `cm_draft.status = 'sent'`. The allowlist is one file: `Dispatcher.php`. If you ever add a second writer, CI breaks loudly. This means: no generator, no worker, no cron job, no event handler can send. They can only enqueue and draft. You are the gate. --- ## BYOK: bring your own Anthropic API key The CM has no Mobieus-side API key. You supply your own Anthropic key at `/admin/community-manager/settings`. Until that key is set, the CM is closed and produces no drafts and makes no API calls. This is enforced at the lowest layer. The `Spine` gate checks three things in order: 1. Master flag `ai_community_manager_enabled` is on 2. Your plan is Pro, Creator Plus, or Sovereign 3. Your Anthropic API key is configured Any one closed, the whole CM is off. The admin UI shows you which gate is closed. You pay Anthropic directly. The CM logs token counts and computes cost in micro-USD per draft so you can see what you spent. --- ## Tier gate The CM is available on **Creator Plus** and **Sovereign** plans. Lower-tier plans do not have access. --- ## Cron schedule Five workers run on the platform host. Each fans out across active tenants. Each worker re-checks the spine per tenant, so a tenant with the CM off pays zero token cost. | Worker | Schedule | What it does | |---|---|---| | `process-cm-queue` | Every minute | Drains `pending_inference` drafts. Runs the matching generator. Persists the body. Flips the draft to `pending_approval` so it shows up in your queue. Bounded at 10 drafts per tenant per tick. | | `process-cm-schedule` | Hourly (`:00`) | Emits the synthetic `schedule.weekly.summary` event once per ISO week per tenant. The Dispatcher subscribes and enqueues one `weekly_summary` draft. Idempotent across all 168 hourly ticks per week. | | `process-cm-engagement` | Hourly (`:15`) | Recomputes engagement scores for members active in the last 90 days. Flags at-risk members. Enqueues up to 5 new `churn_reengagement` drafts per tenant per hour. | | `process-cm-matching` | Every 6 hours (`:30`) | Recomputes pair compatibility across active members. Persists candidates to `cm_suggestion`. Enqueues up to 3 new `meet_suggestion` drafts per tenant per run. | | `process-cm-reply-scan` | Every 2 hours (`:45`) | Scans active forums for unanswered threads matching reply patterns. Enqueues up to 2 new `forum_reply` drafts per tenant per scan. | All five log to `/var/log/mobieus/cm-*.log` on the platform host. --- ## Cost tracking Every successful generation writes one row to `ai_usage_log` and copies the cost onto the draft row as `cost_micros` (1 USD = 1,000,000 micros). Three things are visible to you at `/admin/community-manager`: - **Per-draft cost**: shown on every draft card with token counts (`input_tokens` / `output_tokens`) - **30-day rolling total**: shown in the stat strip at the top of the queue - **Per-generator breakdown**: each draft's `feature` tag (e.g. `cm.welcome`, `cm.weekly_summary`) is queryable in `ai_usage_log` The CM uses Anthropic's published per-token rates. Pricing per model is hard-coded in `InferenceClient::MODEL_PRICING_MICROS` so cost is computed locally without a round-trip to Anthropic. --- ## Opting in and opting out The master flag turns the whole CM on or off. Six per-kind sub-flags let you enable just the parts you want: | Sub-flag | Controls | |---|---| | `ai_cm_welcome` | Welcome drafts on new member join | | `ai_cm_summary` | Weekly admin-only health summary | | `ai_cm_churn` | Churn re-engagement drafts (engagement scorer must be enabled) | | `ai_cm_suggest` | Meet-suggestion intro drafts | | `ai_cm_forum_reply` | Forum reply drafts | | `ai_cm_moderation` | Moderation recommendations on every report | All six default to **off**. Toggle them at `/admin/config` under the AI group. Sub-flags are independent: you can run welcomes without moderation, summaries without churn, any combination. A sub-flag is only checked once the spine is open. Turning on `ai_cm_welcome` without setting your Anthropic key does nothing. --- ## Audit trail Every state transition on every draft writes two audit rows: - One row in `audit_log` (the platform-wide HMAC-chained, tamper-evident audit chain) - One row in `cm_audit` (CM-specific structured columns: draft id, event, actor, JSON detail) `cm_audit` rows reference the `audit_log` row id and copy its integrity hash, so if anyone tampers with `cm_audit` the chain proves it. Events that are recorded: - `generated` — worker produced a draft body - `approved` — admin clicked Approve, no edits - `edited_then_approved` — admin edited the body before approving - `rejected` — admin rejected the draft - `sent` — Dispatcher confirmed the artefact was delivered - `send_failed` — delivery failed (network, downstream error) - `superseded` — a newer draft replaced this one before approval - `retried` — worker retried a failed generation You can view the full chain at `/admin/community-manager/audit`. --- ## Where to learn more - **Queue and approve drafts**: `/admin/community-manager` - **Settings (API key, per-kind toggles)**: `/admin/community-manager/settings` - **Audit trail**: `/admin/community-manager/audit` - **Feature flags**: `/admin/config` (AI group) - **Trigger/condition/action rules engine** (a separate system): `/admin/automation` --- *This page documents the AI Community Manager as shipped through Phase 6 (moderation_assist, 2026-05-29).*