Corporate Brain Platform

A multi-tenant AI knowledge system that turns business data (meetings, docs, emails) into structured, searchable, AI-accessible intelligence. Built on Cloudflare Workers, D1, and Claude.

01System Overview

The full platform at a glance: what runs where and how components connect.

CLOUDFLARE EDGE VPS (67.205.175.249) EXTERNAL SERVICES corporate-brain-mcp MCP + API + OAuth limitless-sync Cron: every 15min fathom-webhook Webhook receiver brain-dashboard Vercel (Next.js) D1 Databases (SQLite per client) DB_PJ Fox RE DB_BO Blue Orchid DB_JOSH Josh RE Vectorize Indexes (embeddings per client) VECTORIZE_PJ | VECTORIZE_BO | VECTORIZE_JOSH | VECTORIZE_RUSHIL Workers AI (embedding generation) telegram-agent.py 1 instance per client claude CLI LLM reasoning brain-telegram-pj brain-telegram-bo brain-telegram-josh Self-Monitoring Layer Startup self-test (exits if broken) 6h heartbeat | 3-error alert threshold Raw Telegram alerts (bypass Claude) Telegram Fathom Limitless OneDrive Google Drive Notion MCP calls

02Three-Layer Architecture

Data stays in source systems. We store metadata and pointers. The UI layer is replaceable.

SOURCE SYSTEMS (where data lives) OneDrive / Google Drive / Outlook / Gmail / Fathom / Limitless / Notion Full original content. Never copied. Accessed on-demand via API. crawl / extract metadata BACKEND (D1 per client) Records title, summary, source_uri, tags Entities people, deals, properties, orgs Links entity-to-entity record-to-entity Memories preferences, facts, corrections Vectors semantic search embeddings sync human-readable subset UI LAYER (client-facing) Telegram Bot | Brain Dashboard (Next.js) | Notion (optional) Replaceable. brain.db is the source of truth. Swap UI without touching backend.

Source Systems

Original data stays where it is. We never duplicate entire documents, emails, or transcripts. The platform fetches content on-demand when an AI agent needs the full text.

Backend (brain.db)

Per-client D1 database storing metadata: titles, summaries, source URIs, entity links, tags, and AI-generated embeddings. This is where search and intelligence live.

UI Layer

The client talks to their brain via Telegram. There's also a Next.js dashboard on Vercel and optional Notion databases. All are swappable without touching the backend.

03Data Ingestion Flows

How data enters the system from each source type.

Limitless Lifelogs Fathom Meeting recordings OneDrive Documents Google Drive Documents limitless-sync Worker Polls API every 15 min Incremental via cursor fathom-webhook Worker Receives webhook POST On meeting completion OneDrive Connector Planned: MS Graph delta Google Drive Connector Planned: OAuth + polling Processing 1. Dedup (source_id) 2. Extract metadata 3. Generate summary 4. Auto-tag entities 5. Generate embedding 6. Link to entities 7. Store record 8. Update sync cursor D1 Database records, entities, tags, FTS Vectorize 1024-dim cosine semantic search Active flow Planned Future

04Retrieval: How Agents Query the Brain

When a client asks a question via Telegram, here's exactly what happens.

Client "What did Jane send about the Oak St closing?" Telegram Telegram Agent VPS Process Wraps message in system prompt + Claude CLI LLM Reasoning Plans MCP tool calls to answer MCP MCP Server corporate-brain-mcp search() get_entity() list_records() get_record() get_brain_status() D1 + FTS5 SQL + full-text Vectorize Semantic search Response sent back via Telegram

1. Client asks

Natural language question via Telegram chat

2. Agent receives

telegram-agent.py on VPS wraps message with system prompt, company context

3. Claude reasons

Claude CLI decides which MCP tools to call to find the answer

4. MCP executes

Queries D1 (full-text + SQL) and Vectorize (semantic), returns results to Claude

05Multi-Tenant Client Routing

One Worker, many clients. The API key determines which database you're talking to.

cbrain_pj_live_2026 cbrain_bo_live_2026 cbrain_josh_live_2026 pbrain_rushil_live_2026 resolveClient() API key lookup Returns: { db, vectorize, clientId } Complete isolation. No cross-client leaks. DB_PJ D1: corporate- brain-pj VECTORIZE_PJ Embeddings DB_BO D1: corporate- brain-blueorchid DB_JOSH D1: corporate- brain-josh Each client has its own D1 + Vectorize. Zero overlap.

06Telegram Agent Architecture

Each client gets a dedicated Telegram bot backed by Claude + MCP tools.

systemd Services (one per client) brain-telegram-pj active brain-telegram-bo active brain-telegram-josh pending setup Restart=always RestartSec=10 telegram-agent.py Telegram Polling getUpdates loop Claude CLI Call --allowed-tools MCP Config Points to Worker System Prompt Company context Self-Monitoring Layer _self_test() on startup: exits if CLI/MCP broken _heartbeat() every 6h: sends alive signal _track_error(): alerts after 3 consecutive fails _send_alert(): raw Telegram API (bypasses Claude) Environment Config clients/*.env D1_API_URL D1_API_KEY LIMITLESS_API_KEY TELEGRAM_BOT_TOKEN TELEGRAM_CHAT_ID ALERT_CHAT_ID POLL_INTERVAL MAX_BATCH_SIZE CLAUDE_TIMEOUT LOG_FILE

07Repository Map

The seoul repo structure. Know where everything lives.

seoul/ corporate-brain-mcp/ -- THE core: MCP server, API, OAuth, client routing src/index.ts -- 2000+ lines. All MCP tools, resolveClient(), OAuth flows schema.sql -- Full D1 schema (entities, records, tags, FTS, memories, collections) wrangler.toml -- D1 + Vectorize bindings per client brain-processor/ -- VPS agent code telegram-agent.py -- Telegram bot + Claude CLI + self-monitoring clients/ pj.env -- PJ's config (tokens, API keys, chat IDs) blueorchid.env -- Blue Orchid's config josh.env -- Josh's config (new, pending tokens) brain-telegram-pj.service -- systemd unit for PJ brain-telegram-bo.service -- systemd unit for Blue Orchid brain-telegram-josh.service -- systemd unit for Josh (new) limitless-sync/ -- Cloudflare Worker: polls Limitless API worker.js -- Cron-triggered, iterates CLIENT_IDS wrangler.toml -- CLIENT_IDS="PJ,BO,JOSH", D1 bindings fathom-webhook/ -- Cloudflare Worker: receives Fathom webhooks worker.js -- Routes by webhook secret to correct D1 wrangler.toml -- D1 bindings per client brain-dashboard/ -- Next.js dashboard (Vercel) app/ -- Pages: entities, records, connections, status lib/api.ts -- API client for corporate-brain-mcp docs/ -- Documentation architecture-visual.html -- This page .context/ -- Project context, architecture docs, plans corporate-brain-architecture.md -- Full architecture reference (READ THIS FIRST)
File Purpose Where
index.ts All MCP tools, OAuth flows, client routing, query logic. The brain of the brain. Cloudflare
schema.sql D1 database schema. Applied to every new client DB. Cloudflare
telegram-agent.py Telegram bot, Claude CLI integration, self-monitoring. One instance per client on VPS. VPS
clients/*.env Per-client config: API keys, bot tokens, chat IDs, polling settings. VPS
limitless-sync/worker.js Polls Limitless API every 15 min. Iterates CLIENT_IDS, writes to per-client D1. Cloudflare
fathom-webhook/worker.js Receives Fathom webhook POSTs, routes by secret to correct client D1. Cloudflare

08Client Provisioning Checklist

Adding a new client to the platform. Each step is isolated; existing clients are never affected.

1

Create D1 Database

npx wrangler d1 create corporate-brain-<client>
Creates an isolated SQLite database on Cloudflare's edge. Save the database_id.

2

Apply Schema

npx wrangler d1 execute <db> --remote --file=schema.sql
Creates all tables, indexes, FTS, triggers. Seeds 8 entity types (Person, Organization, Project, etc.).

3

Create Vectorize Index

npx wrangler vectorize create corporate-brain-<client>-vectors --dimensions=1024 --metric=cosine
For semantic/embedding search. Cosine similarity, 1024 dimensions (Workers AI model).

4

Add Bindings to wrangler.toml

Add DB_<CLIENT> and VECTORIZE_<CLIENT> bindings to all three workers:
corporate-brain-mcp, limitless-sync, fathom-webhook. Update CLIENT_IDS in limitless-sync.

5

Add to resolveClient()

In index.ts, add API key mapping: "cbrain_<client>_live_2026": { dbKey, vecKey, clientId }
Also add DB_<CLIENT> and VECTORIZE_<CLIENT> to the Env interface.

6

Deploy Workers

npx wrangler deploy from each worker directory.
Verify via health endpoint: curl https://corporate-brain-mcp.../health?key=cbrain_<client>_live_2026

7

Create Telegram Bot

Message @BotFather on Telegram. Create bot, save token. Have client message the bot to get their chat_id.

8

Create VPS Config

Create clients/<client>.env with API key, Limitless key, Telegram tokens, alert chat ID.
Create brain-telegram-<client>.service systemd unit file.

9

Deploy to VPS

scp env file and service file to VPS. systemctl enable --now brain-telegram-<client>
Check logs: journalctl -u brain-telegram-<client> -f. Self-test should pass on startup.

10

Set Sync Secrets

echo "<key>" | npx wrangler secret put LIMITLESS_KEY_<CLIENT>
Also set Fathom webhook secret if applicable. These are stored encrypted in Cloudflare.

09Execution Layer: Departments and Agents

The brain stores and retrieves data. The execution layer acts on it. This is how you go from a knowledge base to an autonomous operating system.

EXECUTION BRAIN SOURCES EXECUTION LAYER (Departments + Agents) Autonomous Claude agents that read from and write to the brain on schedules or triggers Intelligence Dept Intake Processor New records come in. Classify, tag, link. Deep Analyst Cross-reference data. Find patterns. Gap Detector What's missing? Generate questions. Entity Resolver Dedup people/orgs. Merge aliases. Operations Dept Daily Briefing Morning summary of new activity. Health Monitor Check sync status. Alert on failures. Follow-Up Tracker Surface overdue action items. Status Reporter Weekly rollup of brain health + KPIs. Proactive Dept Deal Watcher Monitor deals for stale activity. Opportunity Finder Surface leads from meeting transcripts. Doc Expiry Alert Lease/agreement expiration warnings. Relationship Pulse Who haven't you talked to in 30d? read + write via MCP read + write via MCP read + write via MCP BRAIN LAYER (Storage + Retrieval) MCP Server Query tools + API D1 (SQLite) Records, entities, FTS Vectorize Semantic search Memories Facts, preferences Collections Agent output feeds Telegram Bot Dashboard Sync workers Ingestion SOURCE SYSTEMS OneDrive Google Drive Outlook Gmail Fathom Limitless Notion KEY INSIGHT: Departments don't touch source systems directly. They only interact with the brain via MCP tools. This means adding a new department never requires new connectors, schemas, or infrastructure. Just a new agent config + prompt + schedule.

How a Department Works

Agent Config name "daily-briefing" schedule "0 9 * * *" department "operations" target "daily-brief" prompt "Summarize all new records..." is_active true trigger Agent Execution 1. Load system prompt 2. Connect to MCP 3. Execute prompt 4. Write output to collection 5. Log run to agent_runs Brain (via MCP) search, create entity, update record, add memory Collection Output Items added to target collection (dashboard feed) Delivery Telegram msg Dashboard item Notification queue

Department Examples

Intelligence

Purpose: Make raw data smarter. Process new records, extract entities, detect duplicates, find knowledge gaps.

Agents:

Intake Processor (on new record)
Deep Analyst (nightly cross-reference)
Gap Detector (weekly question generation)
Entity Resolver (dedup on demand)

Triggers: Record creation, scheduled, manual

Operations

Purpose: Keep the system and the client informed. Briefings, health checks, status reports, follow-up tracking.

Agents:

Daily Briefing (9 AM summary)
Health Monitor (every 6h check)
Follow-Up Tracker (daily scan)
Weekly Reporter (Friday rollup)

Triggers: Cron schedules

Proactive

Purpose: Surface opportunities and risks the client hasn't asked about. This is where the brain becomes an advisor.

Agents:

Deal Watcher (stale deal alerts)
Opportunity Finder (lead extraction)
Doc Expiry Alert (lease/contract dates)
Relationship Pulse (contact decay)

Triggers: Nightly analysis, event-driven

Already in the Schema

The D1 schema already has tables to support the execution layer. These aren't hypothetical; they're deployed.

Table Purpose How Departments Use It
agent_configs Named agent definitions with department, schedule, prompt template, target collection Defines what agents exist, when they run, and what they write to
agent_runs Audit log of every agent execution: status, duration, items created, errors Tracks execution history. "Did the daily briefing run? How long did it take?"
collections Flexible containers with JSON schema and display config Each department writes to a collection (e.g., "daily-briefs", "deal-alerts")
items Entries within a collection, with structured data and status Individual outputs: a briefing, an alert, a recommendation
notifications Outbound message queue (channel, message, sent flag) Agents queue Telegram messages here. Delivery system flushes them.
questions Knowledge gap questions with priority and status Gap Detector writes here. Telegram agent surfaces pending questions to client.
memories Persistent facts, preferences, corrections, decisions Agents learn from client corrections. Future runs use stored context.

How Gravemind Does It (the reference architecture)

Gravemind (Manas's System) 9 departments, 20+ agents, VPS + Cloudflare hybrid Intelligence Operations Content People VA Coordination Engineering Opportunity Research Meta / Self-Improve Vault (R2) + Notion + Telegram + Slack Cron schedules, event triggers, inbox routing Mature: self-monitoring, inter-agent comms, learning loops inspires Corporate Brain (Client Systems) 3 departments, configurable per client, D1 + MCP Intelligence Operations Proactive Same pattern, scoped for business clients: Configurable agent_configs per client Collections as output feeds agent_runs for full audit trail Notifications queue for delivery Memories for learning over time Growing: add departments as clients need more automation

Evolution Path: From Knowledge Base to Autonomous System

1

Phase 1: Knowledge Base (current)

Data flows in via connectors (Limitless, Fathom). Client asks questions via Telegram. Claude searches the brain and answers. Purely reactive.

2

Phase 2: Scheduled Intelligence

Add cron-triggered agents: daily briefing, follow-up tracking, weekly status reports. The brain starts talking first, not just answering. Uses agent_configs + collections tables.

3

Phase 3: Proactive Monitoring

Event-driven agents: "This deal hasn't had activity in 2 weeks." "Jane mentioned a competing offer in yesterday's call." "Your lease with Oak Street expires in 90 days." The brain becomes an advisor.

4

Phase 4: Inter-Agent Collaboration

Agents read each other's outputs. The Intake Processor's entity extraction feeds the Gap Detector. The Deal Watcher's alerts feed the Follow-Up Tracker. Emergent intelligence from composable agents.

5

Phase 5: Self-Improving System

The brain learns from corrections (memories table). Agents improve their prompts based on what worked. Client feedback refines entity matching confidence. The system gets smarter the more you use it.

10Current Client Status

Active clients and their infrastructure state.

Client D1 Database Telegram Bot Limitless Sync Fathom Webhook Status
PJ (Fox RE) corporate-brain-pj live live live active
Blue Orchid corporate-brain-blueorchid live live live active
Rushil Patel brain-rushil live no key n/a active
Josh Brimhall corporate-brain-josh pending pending key pending provisioned
Blue Orchid Society // Corporate Brain Platform // Architecture Reference
Last updated: April 2026