RadOS System Architect

Multi-Perspective Blueprint -- v3.0 -- 2026-03-19
RadOS is a single-operator agentic operating system. Chris Radicle runs 6 ventures through one Glide app, 18 slash commands, 21 data tables, and 4 external services -- all coordinated by Claude as the execution engine.

This blueprint explains what each piece does, how the pieces connect, and why the architecture works this way. Switch between Blueprint (written guide), Graph (interactive map), and Relations (data flow matrix) using the tabs above.
Ventures
6 ventures
Ventures are the businesses Chris operates. Each venture has different maturity, revenue status, and seasonal cycles. RadQode is the only venture generating revenue today -- all others are pre-revenue or seasonal. The architecture is built so a single operator can run all 6 without context-switching overhead: Glide holds the data, Claude holds the intelligence, and slash commands automate the repetitive work.
How ventures connect to the system
Ventures link to Projects, Pipeline, and Invoices tables in Glide
Each venture has dedicated ICPs and campaign strategies in _Marketing/
The /snapshot command reads all ventures weekly to assess cross-venture momentum
Lead data is tagged by venture, allowing per-venture pipeline analysis
Slash Commands
18 commands
Slash commands are the operational verbs of RadOS. Each command encapsulates a complete workflow -- reading context, making decisions, writing outputs. Commands have three permission tiers: Autonomous (runs without asking), Advisory (prepares output for Chris to approve), and Alert (surfaces urgent information). This permission model prevents Claude from making irreversible decisions while still enabling high-frequency automation.
Command architecture patterns
Daily commands (/briefing, /email-monitor, /session-close) form the session lifecycle
Weekly commands (/task-review, /follow-up, /content-ideas, /opportunity-scan) drive growth cadence
Marketing pipeline (/research-leads > /lead-ingest > /outreach-draft > /follow-up > /lead-qualify) is a sequential chain
All table-writing commands use cache-first reads + batched writes to stay within the Glide API 10K ops/month quota
/campaign-launch is a meta-command that orchestrates research, ingest, and outreach in sequence
Glide Tables
21 tables
Glide is the single source of truth for all structured data. The 21 tables replace what would normally require 5+ SaaS products (CRM, invoicing, project management, content calendar, habit tracking). The Leads table is the most complex with 25+ source columns and 9 computed columns -- and the most API-intensive. The cache-first protocol in _Cache/ reduces API calls by ~80%.
Data architecture principles
Core operational tables (Tasks, Leads, Contacts, Pipeline, Reports) are the most actively read/written
Reference tables (Choices, Connections, Users) are static -- rarely modified, frequently read
Personal tables (Health, Learning, Habits) support the "body as highest-leverage asset" philosophy
The Finance table replaces QuickBooks -- unified business + personal tracking
Leads > Contacts > Pipeline is the promotion chain managed by /lead-qualify
External Services
5 services
External services are the bridges between RadOS and the outside world. The architecture minimizes external dependencies -- only 5 services, each with a specific role. Gmail is the communication layer. Make.com is a thin scheduler. Claude API powers AI features inside Glide. Glide API is the data bridge. Cloudflare is the infrastructure layer -- hosting rados.pages.dev, DNS for all 7 venture domains, and email routing (chris@[domain] + hello@[domain] to Gmail). Every API call is expensive, so _Cache/ absorbs most read traffic.
Integration patterns
Gmail MCP: read-only access via Claude Code. Search, read threads, surface signals. No sending via API.
Make.com: runs one scenario -- 4am Gmail scan that triggers /email-monitor. Minimal logic, maximum reliability.
Claude API: called by Glide Custom API Actions for in-app AI (auto-suggestions, smart columns). Separate from Claude Code.
Glide API: queryTables (read) + mutateTables (write). Cache-first protocol wraps every read. Batched writes bundle mutations.
OS Layer
7 directories
The OS Layer is the file system that gives Claude persistent context between sessions. Without these directories, every session would start from zero. Each directory serves a specific memory function: _Identity/ is who Chris is, _Marketing/ is the strategy layer, _Briefings/ is the daily archive, _Operations/ holds SOPs, _Cache/ is the API buffer, _Connections/ maps all integrations, and _Tasks/ tracks active work.
How the OS Layer enables agentic behavior
_Cache/ is the most critical runtime directory. Without cache, every command would burn 3-5 API calls.
_Marketing/ contains per-venture ICPs that make outreach personalized instead of generic.
_Briefings/ creates an audit trail. Any session can look back at what happened on any day.
_Connections/ holds Glide column keys, API configs -- the wiring that makes data flow work.

CONNECTIONS
85%

Data Relations

How Commands, Tables, and Services Interact

Command-Table Matrix

Each cell shows how a slash command interacts with a Glide table. This matrix reveals which commands are data-heavy, which tables are most accessed, and where the system's critical paths run.
Read
Write
Read + Write
Cache-first

Data Flow Chains

These are the primary multi-step workflows that move data through the system. Each chain shows the sequence of components involved and explains why the data flows this way.