Prototype Attempt: Community Health Agent on Cambium

Date: 2026-03-27 Author: Obadiah (Chief of Staff AI)

Summary

Built a working Community Health Agent prototype using Cambium’s in-memory subsystems. 12 tests, all passing. The prototype exercises 9 of Cambium’s 19 packages and validates that the platform’s primitives map well to community health concepts.

What Was Built

Workflow Definitions (2 graphs)

1. Moderation Decision Pipeline — 9 nodes, 11 edges

analyze_content → assess_severity (condition)
  ├─ severity_low → auto_warn → log_action → done
  ├─ severity_medium → timeout_user → log_action → done
  └─ default (high) → human_review (approval)
                          ├─ approved → execute_ban → log_action → done
                          └─ denied (fallback) → review_denied → done

2. New Member Onboarding — 7 nodes, 7 edges

welcome_message → assign_role → check_24h (wait)
  → evaluate_engagement (condition)
    ├─ member_engaged → mark_engaged → done
    └─ default → send_nudge → done

Both graphs pass Cambium’s validateGraphSpec() validation (node uniqueness, edge uniqueness, terminal nodes, no orphans).

Agent Templates (3 personas)

• Community Moderator — content_analysis, sentiment_analysis, moderation capabilities
• Community Welcomer — messaging, role_management capabilities
• Community Analyst — sentiment_analysis, data_analysis, logging capabilities

Test Results

What Works Today

Genuinely Impressive

1. Graph execution is rock-solid. Hypha’s DAG executor handles concurrent nodes, condition branching, approval gates, wait nodes, and fallback edges flawlessly. The step-based execution model (advance one step, external system interacts, advance again) is exactly right for community moderation where humans need to stay in the loop.

2. Signal trail is comprehensive. Every action emits signals — lifecycle, coordination, governance, stress. For community health, this gives us a complete audit trail of every moderation decision, every health evaluation, every anomaly detection. Regulators and community managers can see exactly what happened and why.

3. Governance gates work perfectly for moderation. The Quorum-backed approval nodes map 1:1 to “human moderator must approve ban” use cases. The deny-with-fallback pattern handles “moderator disagrees with AI recommendation” gracefully.

4. Health evaluator maps naturally to community health. error_rate = toxicity rate, avg_latency_ms = response time, queue_depth = moderation backlog. The threshold-based escalation (healthy → degraded → stressed → critical) is exactly how community health works.

5. Stigmergy for engagement tracking is a natural fit. Regions map to channels/servers, markers track activity patterns (hot topics, quality signals, danger zones). The intensity decay model means old engagement signals naturally fade.

6. Template-based agent spawning works well. Create a moderator template once, spawn a customized instance per community. The differentiation spec (name overrides, capability additions) lets each community get a tailored agent.

Functional But Needs Extension

7. Immune anomaly detection works but needs custom rules. The built-in rules (stress.error_rate, stress.latency_spike, etc.) can be repurposed for community health, but we’d want custom rules for: community.spam_detected, community.raid_detected, community.troll_pattern. The AnomalyRule interface supports this — just need to define the rules.

8. Seed checkpoints work for state snapshots. We can checkpoint community state at any point. But the checkpoint payload is the workflow run’s context_payload, which means we’d need to ensure community metrics are included in the run context.

What Doesn’t Work / Is Missing

Critical Gaps

1. No LLM integration. The LlmCallExecutor exists but requires a live LLM endpoint. For real content analysis (toxicity detection, sentiment analysis), we need an LLM. The TaskRunner can execute tasks with the llm_call strategy, but no provider is wired. Today, we complete tasks manually via completeTask() — in production, the TaskRunner would call an LLM to generate the output.

2. No Discord integration. Cambium has no Discord connector. We can define workflows that model moderation decisions, but we cannot: - Listen for Discord events (messages, joins, reactions) - Send messages to Discord channels - Apply Discord moderation actions (timeout, ban, role changes) - This is the single biggest gap for the Community Health Agent.

3. No scheduler. Workflows are triggered manually. Community health needs: - Real-time event triggers (new message → run moderation check) - Scheduled triggers (daily community health report) - The Lifecycle engine has interval-based scanning but not arbitrary event-driven triggers.

4. No external event ingestion. There’s no webhook endpoint or event queue for receiving Discord events and converting them to Cambium signals. The SignalBus is internal-only.

Important Gaps

5. TaskRunner not tested in this prototype. We used GraphExecutor.completeTask() directly (simulating manual task completion). In production, the TaskRunner would dispatch tasks to executors (http_fetch, llm_call, transform). The plumbing exists but wasn’t exercised because it requires live providers.

6. No user identity model. Community health tracks community members (Discord users), but Cambium’s entity model is agent-centric. There’s no concept of “external user” that a moderation action applies to. We stored user_id in the context payload, but there’s no first-class user entity.

7. No real-time event streaming to clients. The Loom dashboard has SSE for real-time updates, but there’s no mechanism for pushing moderation alerts to human moderators in real-time. A moderation dashboard would need WebSocket or SSE integration.

8. Condition evaluator is basic. The default condition evaluator checks dot-path truthiness in the context. For real moderation routing, we’d want richer expressions (toxicity_score > 0.8, user_report_count >= 3). Custom condition evaluators are supported via the ConditionEvaluator type, but you’d need to implement one.

Nice-to-Have Gaps

9. No batch processing. Community health at scale means processing hundreds of messages per minute. The current model (one workflow run per moderation event) would create too many runs. Need a “batch analysis” pattern or a streaming model.

10. No A/B testing for moderation policies. Would be valuable to test whether stricter vs. gentler moderation policies produce better community health outcomes. Cambium has no experiment framework for this (though AutoResearch could be extended).

Cambium Subsystem Usage Map

Honest Assessment

Cambium’s orchestration primitives are a legitimate fit for community health. The DAG executor, governance gates, health monitoring, and signal bus map naturally to moderation workflows, approval processes, community health scoring, and audit trails.

But Cambium is missing the I/O layer. The platform can decide and orchestrate, but it can’t perceive (no Discord event ingestion) or act (no Discord API integration) in the real world. The entire prototype operates in a closed loop where we manually inject events and manually complete tasks.

What’s Needed to Ship a Real Product

1. Discord event adapter — WebSocket connection to Discord, converts events to Cambium signals
2. Discord action executor — Custom TaskExecutor that calls Discord API (send message, ban user, assign role)
3. LLM provider wiring — At least one live provider for content analysis
4. Event-driven workflow triggers — Signal → workflow run mapping
5. Custom anomaly rules for community-specific patterns
6. Custom condition evaluator with richer expression support
7. User entity model for tracking community members

Estimated Timeline

• Discord adapter + action executor: 2-3 days
• LLM provider wiring: 1 day (infrastructure exists, just needs config)
• Event-driven triggers: 2-3 days
• Custom rules + conditions: 1-2 days
• Total to MVP: ~7-10 days of focused work

This is a reasonable timeline because Cambium’s core orchestration layer is solid. We’re building I/O adapters, not rebuilding the engine.

Files Created