---
created: 2026-03-12
source: Rivet
tags: [agent-archive, rivet]
---

# Multi-Bot Architecture Discussion — 2026-02-13

*Logged from morning chat. Michael wants to revisit this.*

## The Idea
Separate Clawdbot instances for each department, each specialised, reporting into shared files that Rivet (ops) monitors.

## Proposed Lineup
1. **Rivet** — Operations/coordination (existing)
2. **Builder** — Code only (Michael already set this up)
3. **Sales & Marketing** — Leads, SMS, content, outreach
4. **Legal & Finance** — Compliance, contracts, bookkeeping
5. **Chief of Staff ("Compass" or "Chief")** — Strategic analysis bot

## Chief of Staff Concept
- Reads ALL department outputs during the day
- Cross-references market data, competitor moves, trends
- By 7 PM drops Michael a brief: decisions needed, opportunities spotted, risks flagged
- Different from Rivet: Rivet runs the machine, Chief of Staff watches where the machine should go
- Named suggestion: **Compass** or **Chief**

## Architecture
- Each bot = separate Clawdbot gateway instance
- Communication via shared files (like CC-VPS-INBOX.md pattern)
- Each writes updates, Rivet reads on heartbeats
- Cheap models for routine, Opus for dirty data

## Michael's Input
- Already created Builder bot overnight
- Wants WhatsApp number + company email for Rivet
- Approved the department structure concept
- Said "log it, we'll talk again" — revisit in evening window

## Service Bots (Cross-Cutting)

### Comms Gateway
- **Purpose:** Quality gate for ALL external communications
- Every SMS, email, social post, WhatsApp message reviewed before sending
- Checks: tone, accuracy, legal compliance, brand consistency
- Prevents false claims (like the Feb 7 SMS script issue — 18 steps had false claims about voice signup)
- One bot whose job is asking "should we actually send this?"
- Could enforce guidelines: no promises we can't keep, correct pricing, proper disclaimers

### Why This Matters
- SMS false claims nearly went out to 231 leads
- External comms are the highest-risk action any bot takes
- One mistake to a real customer = reputation damage
- Centralised review = consistent brand voice across all channels

## File Reorganisation Needed
- Current: everything in /home/ccuser/rateright-growth/rivet/
- New: shared workspace accessible by all bots
- Each bot needs its own context files but shared reporting layer
- Shared files: TODO.md, updates/*.md, comms-queue/*.md
- Per-bot files: SOUL.md, HEARTBEAT.md, department-specific context

## Clawdbot Multi-Agent Technical Notes (Research Feb 13)
**Source: Clawdbot docs, production guides**

### Key Constraints
- **Never reuse agentDir across agents** — causes auth/session collisions
- **Share credentials:** Copy `auth-profiles.json` into each agent's agentDir
- **Skills:** Per-agent via workspace `skills/` folder; shared skills in `~/.clawdbot/skills`
- **Coordination:** Agents collaborate via SSH or messaging channels

### Architecture Pattern for RateRight
```
/home/ccuser/
├── rivet/                    # Rivet (Ops) - existing
│   ├── SOUL.md
│   ├── HEARTBEAT.md
│   └── shared/               # Shared workspace
│       ├── TODO.md
│       ├── updates/
│       └── comms-queue/
├── builder/                  # Builder (Code) - new
│   ├── SOUL.md
│   └── HEARTBEAT.md
├── sales/                    # Sales & Marketing - future
├── legal/                    # Legal & Finance - future
└── chief/                    # Chief of Staff - future
```

Each bot has its own `agentDir` but shares `auth-profiles.json` for common integrations (Notion, Supabase, etc.)

## Model Selection Per Bot
| Bot | Recommended Model | Why |
|-----|------------------|-----|
| Rivet (Ops) | Opus | Coordination, dirty data handling |
| Builder (Code) | Sonnet/Opus | Code quality, codebase context |
| Sales | Kimi/Sonnet | High volume, routine outreach |
| Legal/Finance | Opus | Accuracy critical, can't afford mistakes |
| Chief of Staff | Opus | Strategic thinking, cross-domain analysis |
| Comms Gateway | Opus | External-facing, highest risk |

## Shared Database Architecture (Supabase)

### Hybrid Approach — Database + Files
Michael suggested all bots connect to Supabase instead of file-based coordination.
**Answer: Hybrid.** Structured data → Supabase. Config/context → files.

### What Goes in Supabase
| Table | Purpose | Access |
|-------|---------|--------|
| `bot_tasks` | Tasks with status, priority, owner, timestamps | All bots (RLS per bot) |
| `bot_comms_queue` | Messages awaiting approval before sending | Comms Gateway + Rivet |
| `bot_handoffs` | Cross-bot task handoffs | All bots |
| `bot_audit_log` | Who did what, when | Read: all, Write: per bot |
| `leads` | Already exists in Growth Engine | Sales bot + Rivet |
| `bot_status` | Heartbeat status per bot | All bots |

### What Stays as Files
- SOUL.md, HEARTBEAT.md, AGENTS.md — bot config/personality
- Research docs, plans, specs — long-form human-readable content
- Memory files — context that bots read on startup
- MEMORY.md — curated long-term memory

### Why Hybrid
- Database: Real-time, queryable, RLS, concurrent access, no merge conflicts
- Files: Human-readable, simple, Michael can read on his phone
- Best of both: Structured data in DB, context in files

### RLS Schema
Each bot gets a `bot_id` column. Row Level Security ensures:
- Rivet sees all rows (coordinator)
- Builder sees only builder tasks
- Sales sees only sales tasks
- Cross-references via explicit sharing flags

## Decision Needed
- How many to spin up at once (recommendation: Builder + Rivet first, add others incrementally)
- Infrastructure: same VPS or separate?
- WhatsApp SIM + email setup timing
- Chief of Staff: spec it out or wait?
- Comms Gateway: build before or after sales bot?
- File reorganisation: do it now or when adding 3rd bot?
- Supabase schema: design now or when 3rd bot added?

---
*Revisit during evening window (7-8:30 PM) or next available session*