Cambium System Audit

Date: 2026-03-27

1. Build Status

TypeScript strict mode is enforced across all packages. No type errors. The Loom Next.js app compiles and generates 37 static pages and 30+ dynamic API routes. CI is configured in .github/workflows/verify.yml running architecture checks, typecheck, and tests.

The only observed test instability is a transient timing issue in @cambium/stigmergy (1 of 23 tests occasionally fails under parallel execution but passes consistently in isolation).

2. Test Status

All tests run against in-memory stores. No tests require a live database, LLM endpoint, or external service. Integration tests in tests/integration/ exercise multi-package flows (research pipeline, financial trading, cascading failure, product development, self-wiring orchestration) using mocks.

3. Package-by-Package Assessment

Core Infrastructure

Orchestration

Agent Lifecycle

Safety & Governance

Coordination & Observability

Apps

Codebase Size

~56,000 lines of TypeScript source across 19 packages + 1 app.

4. Database

Setup Requirements

• PostgreSQL 16 via docker-compose.yml
• Default credentials: cambium:cambium_dev@localhost:5432/cambium
• Drizzle ORM with 4 migration files in packages/db/drizzle/
• Migration command: pnpm --filter @cambium/db migrate

Schema Status

584-line schema covering all domain entities. Tables include: workflow_definitions, workflow_runs, task_executions, signals, events, agents, templates, compost_records, decisions, health_states, checkpoints, anomalies, markers, regions, providers, auth_profiles, intents, budgets, policies, audit_entries, lifecycle cycles, topics, autonomous_intents, lifecycle compost records.

Current State

The database layer is fully implemented. Every InMemory store has a corresponding Pg store. The Loom service wiring (services.ts) uses a toggle (CAMBIUM_PERSISTENCE=postgres) to switch between in-memory and Postgres-backed stores. All 21 Pg stores are imported and wired in the conditional paths.

However: no .env file or .env.example exists. The database has not been verified as runnable end-to-end (migrations applied, Loom booted against Postgres, API routes tested with real persistence).

5. Runtime Dependencies

To run in development (in-memory mode)

pnpm install
pnpm turbo dev    # Starts Loom on port 3100

No external dependencies needed. All stores default to in-memory. This works today.

To run with PostgreSQL persistence

docker compose up -d                    # Start Postgres
pnpm --filter @cambium/db migrate       # Run Drizzle migrations
CAMBIUM_PERSISTENCE=postgres pnpm turbo dev

Environment Variables

6. Gaps for Running Obadiah V2

The docs/OBADIAH_V2_PLAN.md lays out the full migration vision. Here is what is concretely missing:

6.1 No Obadiah-Specific Agent Templates or Workflows

Cambium’s Genesis system can spawn agents from templates, and Hypha can execute DAG workflows. But no Obadiah-specific templates (persona agents) or workflows (morning brief, evening wrap, task delegation) have been defined or seeded. The plan document specifies them in detail but none are implemented.

6.2 No LLM Integration Wired

The IntentDecomposer in Cortex is designed to call an LLM provider to decompose natural language intents into executable graphs. The ProviderRegistry has 5 templates (Anthropic, OpenAI, etc.). But no API keys are configured, no .env.example exists, and no live LLM call has been verified. The AuthenticatedLlmCaller exists and is tested with mocks, but has never been run against a real provider.

6.3 No Scheduled Task Execution

Obadiah needs scheduled workflows (morning brief at 6am, evening wrap at 9pm). Cambium has the LifecycleEngine for autonomic loops but no cron/scheduler for time-triggered workflow execution. The lifecycle engine runs on intervals but is designed for sense/accumulate/evaluate/act cycles, not arbitrary scheduled workflows.

6.4 No Discord Integration

Cambium has no Discord connector. Obadiah V1 uses the Claude Discord plugin directly. For V2, Cambium would need either: (a) a Discord integration in @cambium/integrations, or (b) the ability to invoke Claude with the Discord plugin as a tool available to task executors.

6.5 No File System / Git Access for Self-Improvement

Obadiah V1 reads/writes markdown files and commits to git. Cambium has a FileOutputExecutor in Hypha but no general file system or git integration for the kind of self-modification Obadiah does (editing its own CLAUDE.md, writing daily memory logs, updating changelog).

6.6 No External Data Source Integrations

The lifecycle scanner has RSS support, but Obadiah needs broader integrations: email checking, calendar reading, news aggregation, project status from GitHub, etc. These would need to be registered as tools in @cambium/integrations or implemented as custom task executors.

6.7 Postgres Persistence Not Verified End-to-End

While all Pg stores exist and are wired, the full stack has not been tested with a live Postgres database. The migration files exist but have not been verified against a fresh database with the current schema.

7. Recommended Next Steps

Tier 1: Make It Run (required for any Obadiah workflow)

1. Verify Postgres end-to-end – Stand up Postgres via docker-compose, run migrations, boot Loom with CAMBIUM_PERSISTENCE=postgres, verify basic API round-trips (create workflow, create run, list agents). Create a .env.example file.

2. Wire an LLM provider – Configure at least one provider (Anthropic Claude) with a real API key. Verify that IntentDecomposer can decompose a simple intent into a graph. This unblocks the entire Cortex pipeline.

3. Seed Obadiah agent templates – Create the 9 persona templates (Obadiah + 8 specialists) as Genesis templates, either via API or as seed data. This is the V2 plan’s Section 3.1.

Tier 2: Build the First Workflow (minimum viable Obadiah on Cambium)

4. Implement a simple Obadiah workflow – Start with one: “morning brief” as a Hypha graph (fetch news, summarize, format, deliver). This validates the full pipeline from workflow definition through execution.

5. Add a scheduler – Implement time-triggered workflow execution. Could be as simple as a setInterval in the Loom server that checks for due workflows and starts runs.

6. Add Discord as a delivery channel – Either as an integration tool (HTTP webhook to Discord) or by wiring Claude’s Discord plugin as an output executor.

Tier 3: Production Hardening (from the existing execution backlog)

7. Workspace auth context propagation (Backlog Item 6) – Several API routes still hardcode default workspace instead of reading from authenticated request context.

8. Production startup hardening (Backlog Item 8) – Make services.ts fail fast on missing critical config in production mode instead of silently falling back to in-memory.

9. OAuth hardening (Backlog Item 9) – The OAuth flow has a stub alongside the real HTTP flow, and state is not persisted for callback validation.

10. Loom E2E tests (Backlog Item 7) – No Playwright tests exist for the operator dashboard.

Summary

Cambium is a well-architected, fully-compiling, fully-tested monorepo with ~56k lines of TypeScript across 19 packages and a Next.js dashboard. All 670 tests pass. The architecture is sound: signal bus, DAG executor, agent lifecycle, governance, health monitoring, and persistence layers are all implemented and tested.

The platform is not yet runnable as an Obadiah host because it lacks: (1) live LLM provider configuration, (2) Obadiah-specific agent templates and workflows, (3) a scheduler for time-triggered execution, and (4) Discord delivery integration. The database layer is complete but has not been verified end-to-end with a live Postgres instance.

The shortest path to “Obadiah running on Cambium” is: verify Postgres, wire one LLM provider, seed persona templates, build one workflow (morning brief), and add Discord output.