The AI-native operating system for your entire company.
ownership: inhouse owner: Kyle Benford classification: //Internal — See Below status: executable operating system created: 2026-05-19 canonical:
/Users/cleanstart/artofficial.computer/ops/identity/COMPANYOS.mdsupersedes: COMPANYOS-LEGALOS-EMAILOS-BUILD-MONOFILE.md (consolidated into this)
The CompanyOS landing page mirrors 8090.ai/Software Factory — single-tab, 7-section scroll:
| # | 8090.ai Section | CompanyOS Equivalent |
|---|---|---|
| 1 | Hero: "AI-native software factory for regulated enterprises" | Hero: "AI-native operating system for your entire company" |
| 2 | Chamath testimonial | Byron testimonial (Ghlen block) |
| 3 | Partner logos (EY marquee) | Role Silo Map (12 profiles, 3 classes) |
| 4 | "Why 8090" (Quality/Control/Consistency) | "Why CompanyOS" (Middleware flow, single receipt state) |
| 5 | Software Factory deep dive | Sequencer Pipeline (intent → EmailOS → LegalOS → execution) |
| 6 | Enterprise offering | Build Order (P-1/P0/P1/P2/P3 status) |
| 7 | Final CTA | "Ready to run?" [Monofile] [Obsidian] |
Headline: "The AI-native operating system for your entire company."
Subhead: "From intent to execution to audit trail — CompanyOS runs it all."
Primary CTA: "Browse the Monofile"
Secondary CTA: "Open the Obsidian Vault"
12 Hermes Profiles Wired: - Gate Agents (legal-gate, compliance, auditor) — terminal+file only, zero external execution - Execution Agents (outreacher, fulfiller, identifier, email-ops) — scoped to domain - Capital Agents (treasury-pm) — Governed depth, LegalOS gate on every money action
3 Agent Classes from Wiring: - Gate agents: never execute externally - Execution agents: domain-scoped work - Capital agents: money actions gated by LegalOS
KB intent / signal / email / payment / A2A
→ EmailOS (identity resolution + inbox classification)
→ LegalOS (gate: disclosure / money / counsel / compliance / covenant depth)
→ CompanyOS (decompose + assign + track + receipt)
→ Execution layer (GetRida / Email Intel / Worker / Hermes profiles)
→ Master Inbox + receipts + vendor spend + thread ledger
→ KB OnChain proof packet / bank-facing evidence
Every lane writes back to identity/thread/task/receipt state. No parallel lanes without cross-visibility.
| Phase | Description | Status |
|---|---|---|
| P-1 | KB OnChain / Capital Flywheel | DONE |
| P0 | EmailOS unified ledger + campaign seed | DONE |
| P1 | Campaign sequencer + profile operationalization | DONE (12 profiles wired) |
| P2 | LegalOS middleware + fulfillment automation | IN PROGRESS |
| P3 | CompanyOS task graph + reporting | PLANNED |
Headline: "Ready to run the system?"
Copy: "The entire stack is one operating system. Every lane routes through the same pipeline. Every action writes to the same receipt state."
Buttons:
- "Browse the Monofile" → https://companyos-768.pages.dev/ (live, auto-synced from this file)
- "Open Obsidian Vault" → Architecture/CompanyOS.md
CompanyOS is Kyle's agent. It is not a product. It is not a platform.
KB intent / signal / email / payment / A2A
→ EmailOS (identity resolution + inbox classification)
→ LegalOS (gate: disclosure / money / counsel / compliance / covenant depth)
→ CompanyOS (decompose + assign + track + receipt)
→ Execution layer (GetRida / Email Intel / Worker / Hermes profiles)
→ Master Inbox + receipts + vendor spend + thread ledger
→ KB OnChain proof packet / bank-facing evidence
Every lane writes back to identity/thread/task/receipt state. No parallel lanes that cannot see each other.
CompanyOS receives intent, decomposes work, assigns specialist agents, tracks state, and records receipts.
Engine: Hermes Kanban/orchestrator + SRIDA Worker D1/task surfaces + Master Inbox as relationship/event ledger + Monofiles as durable context per entity
CompanyOS answers: - What is the work? - Who/which agent owns it? - What state is it in? - What receipt proves it happened? - What capital/relationship effect did it create?
Executables:
- ~/.hermes/hermes-tunnel/server.py — tunnel between SRIDA Worker and local actors
- cf-worker-srida/src/index.ts (7187 lines) — always-on cloud execution substrate
- Hermes profiles — role-siloed agents, each a Kanban assignee
- Kanban dispatch — decomposition, routing, dependency linking
LegalOS gates CompanyOS actions before execution or external disclosure. It is NOT a separate engine — it is middleware inside the CompanyOS flow.
LegalOS answers: - Is this action allowed? - Does this require KB/counsel/accounting/board review? - Is this internal, covenant, public, client-facing, or bank-facing? - Does this involve money, contracts, securities-like language, legal risk, confidential client data, or regulatory claims? - What receipt shows the gate passed or blocked?
Executables:
- artofficial.computer/services/GetRida/email-intel/api_bridge.py — LegalOS JSON endpoints:
- /api/legal/counsel-lab
- /api/legal/compliance
- /api/legal/fiduciary
- /api/legal/acquire
- /api/legal/diligence
- /api/legal/ap-question
- /api/legal/apr
- /api/legal/reveal
Valve rule: Several LegalOS actions are intentionally valve-closed. They mark JSON state only and do not send attorney emails without explicit KB enablement.
Missing (P2): legalos_gate() as executable middleware before all sends, legal/counsel surfaces, money events, and on-chain actions. Currently doc + JSON API, not enforced middleware.
EmailOS owns all mail/signal surfaces. It is broader than Email Intel.
EmailOS answers: - Who is this email from? - Which identity/client/entity does it belong to? - Which CompanyOS lane does it route to? (fulfillment / outbound / governance / counsel / capital / a2a / noise) - Should the agent reply, log, escalate, suppress, or route to a task? - Does this lane require a LegalOS gate before execution? - Where is the canonical thread?
7 CompanyOS Lanes:
| Lane | Owning Role | LegalOS Gate | What It Catches |
|---|---|---|---|
| fulfillment | fulfiller | No | Existing client comms, project updates, delivery |
| outbound | outreacher | No | Prospect/cold reply, engagement signals |
| governance | legal-gate (→KB) | Yes | Board/corporate, ownership, strategic oversight |
| counsel | legal-gate (valve) | Yes | Legal, accounting, regulatory escalation |
| capital | treasury-pm | Yes | Treasury, vendor spend, billing, payment failures |
| a2a | email-ops (internal) | No | |
| intel | researcher | No | |
| noise | suppress | No |
Implementation: ~/.hermes/scripts/agentic_crm_classify.py pre-classifies lanes from sender/subject heuristics. Cron agentic-crm-intent-classifier (every 5m) verifies/overrides via LLM, outputs grouped lane digest. Each crm_events.jsonl entry carries lane, assigned_role, legalos_gate_required.
Live Classification Feedback Loop (8th lane: intel):
Classification is NOT write-only — KB corrections propagate back to the classifier rules in real-time.
KB corrects classification (Telegram "reclassify <id> <lane>")
→ inbox_classifier_feedback.py records correction to classification_corrections.jsonl
→ Feedback processor cron (every 5m) applies corrections to classification_rules.json
→ Intent-classifier cron reads corrections digest + live rules before each run
→ Future classifications use the corrected rules automatically
→ No manual config edits needed — the OS learns from the operator
Classification correction commands (via Telegram to Hermes):
- reclassify <msg_id> <lane> — reclassify a single message and update rules
- reclassify <msg_id> <lane> <rule_type> <rule_value> — precise rule override
- rule_type: sender (match sender name/address), domain (match sender domain), subject (match subject pattern)
- reclassify-batch '<json>' — batch corrections
- KB can also correct directly in conversation — Hermes parses intent and calls the feedback script
Rule persistence: ~/.hermes/kb/inbox/classification_rules.json — canonical rules file, bootstrapped from LANE_HINTS, updated by corrections. Both the classify script and the intent-classifier cron read this file.
Correction history: ~/.hermes/kb/inbox/classification_corrections.jsonl — append-only log of all KB overrides with timestamps. Audit trail.
Vault ref: Obsidian Architecture/EmailOS Lane Classification.md
Surfaces:
- kyle@heliuspartners.com — KB direct (regulated principal)
- AgentMail service inboxes — enjoy@getrida.work (agentic membrane), support@getrida.work (outbound rail), rida@agentmail.to (A2A internal only)
- Fulfillment webhook: /webhook/email
- Outreach webhook: /webhook/reply
- IMAP/Himalaya full-thread recovery
- Master Inbox thread assembly (D1: master_threads, master_messages, master_open_items)
- Client delivery logs
- Governance/counsel/accounting email surfaces
Executables:
- intake_gate.py — 3-layer inbound hygiene (SPF/DKIM/DMARC → sender allowlist → content classification)
- inbox_actor.py — unified reply engine, persona routing, 8 task kinds from Worker
- tunnel_server.py — bridge between SRIDA Worker and local actors (port 4242)
- client_responder_daemon.py — synchronous LLM reply processing
- inbox_classifier_feedback.py — live classification feedback loop (reclassify, rules, corrections, process)
Classification state files:
- ~/.hermes/kb/inbox/classification_rules.json — canonical lane rules (updated by KB corrections)
- ~/.hermes/kb/inbox/classification_corrections.jsonl — append-only correction audit trail
- ~/.hermes/kb/inbox/corrections_digest.json — recent overrides for intent-classifier context
Invariant: kyle@heliuspartners.com + BCC enjoy@getrida.work for all client-service email. rida@agentmail.to is internal A2A only.
Email Intel is inside EmailOS. It is the sequencer.
Email Intel answers: - Who should be contacted? - Which campaign/sequence applies? - Which inbox/domain can safely send? - Did they reply/bounce/open/click/DNC? - What happens next?
Executables:
- send_gate.py — D1-backed outbound send gate, live habitat counts, AgentMail safety, suppression + rate caps
- intake_gate.py — inbound gate (shared with EmailOS layer)
- provision-habitat.py — domains/DNS/AgentMail inbox provisioning
- api_bridge.py — local Email Intel + LegalOS bridge
Campaign sequencer (P0-4): Not yet built. Multi-step drip engine. Day 0 first touch → Day 3 follow-up → Day 7 final. D1 state machine per lead-campaign pair. Cron checks for due sends, calls send_gate.
10 P0 Build Tasks (from Cold Email Intelligence.md):
1. P0-1: Seed Lead Pipeline (D1) — 500+ leads with ICP > 0.7
2. P0-2: Lead Ingestion Endpoint — POST /api/leads/ingest
3. P0-3: Un-stub send_gate ✅ DONE
4. P0-4: Campaign Sequencer — multi-step drip
5. P0-5: LLM Personalization Layer — replace templates
6. P0-6: Domain Warmup Mesh (Real)
7. P0-7: Inbox Intelligence Classifier — intent scoring
8. P0-8: Reply → Follow-Up Automation
9. P0-9: Daily Rida Report
10. P0-10: Full A2A Dispatch Loop
GetRida packages the OS as lead supply + outbound volume + agentic send/receive loop + reply handling + client fulfillment + CRM/GHL execution. Delivery through email/live service, not internal paperwork.
Covenant depths: Surface ($97) → Operational ($297) → Strategic ($997) → Governed (custom)
client revenue → Stripe/x402 receipt → treasury allocation → vendor spend → delivery capacity → agent work → more receipts → on-chain/bank proof
Ties: first ~$1K Stripe/client receipt, treasury allocation, AgentMail/inbox spend (~$200), domains/email infra, compute/tools, BODY thesis reserve/hardware, vendor receipts, Master Inbox/Worker receipts, x402 payment proof, .md instrument hash/anchor.
Missing: x402 seller endpoint, vendor_spend auto-recording (table exists, 0 rows), first receipt chain.
Each role is a Hermes profile (Kanban assignee) with scoped skills, covenant depth access, and receipt-writing obligation.
Owns: Marketing content, style intelligence, positioning, See Above encoding
Tools: web, terminal, file, browser, vision, image_gen
Covenant depth: Surface + Operational (never Governed)
Receipts: content-produced, positioning-updated
Can't: Send client email, touch money, modify GHL, access rida@agentmail.to
Owns: Client-facing messaging, covenant-grade comms, BCC routing
Tools: terminal, file, email, web
Invariant: Always kyle@heliuspartners.com + BCC enjoy@getrida.work
Covenant depth: up to Governed (with LegalOS gate)
Receipts: email-sent, thread-updated
Can't: Modify campaigns, send from rida@agentmail.to, bypass LegalOS on Governed actions
Owns: Campaign dispatch, cold email sends, send gate operation
Tools: terminal, file, email
Covenant depth: Surface only
Receipts: send-event, outreach-event
Can't: Touch kyle@heliuspartners.com directly, modify lead supply, bypass send gate, access Governed surfaces
Owns: Lead supply pipeline, identity graph enrichment, ICP scoring Tools: terminal, file, web, browser Covenant depth: Surface only Receipts: lead-ingested, identity-updated Can't: Send emails, modify campaigns, access client data beyond public enrichment
Owns: GHL ops, CRM sequences, client delivery execution Tools: terminal, file, browser, web Covenant depth: up to Strategic (with LegalOS gate for Governed) Receipts: fulfillment-delivered, crm-updated Can't: Send outbound cold email, modify lead supply, access treasury
Owns: AgentMail inbox management, IMAP recovery, BCC routing logic, webhook health Tools: terminal, file, email Covenant depth: Operational Receipts: inbox-provisioned, webhook-healthy Can't: Modify campaigns, send client-facing email, access treasury
Owns: Vendor spend recording, receipt chain, Stripe/x402 proof, bank packet generation Tools: terminal, file, web Covenant depth: Governed (always gated through LegalOS) Receipts: receipt-recorded, vendor-spend-logged, bank-packet-generated Can't: Send email, modify campaigns, bypass LegalOS on any money action
Owns: Pre-send regulatory checks, disclosure boundary enforcement, See Above/See Below encoding verification Tools: terminal, file Covenant depth: Governed Receipts: compliance-check-passed, compliance-check-blocked Can't: Execute any external action — only gate/block/escalate
Owns: Audit trail integrity, dual sign-off verification, covenant integrity checks Tools: terminal, file Covenant depth: Governed Receipts: audit-verified, anomaly-detected Can't: Execute any external action — only verify and flag
Owns: LegalOS gate execution, counsel/accounting escalation, valve enforcement Tools: terminal, file Covenant depth: Governed (highest) Receipts: legalos-gate-passed, legalos-gate-blocked, legalos-gate-escalated Can't: Execute any external action — only gate/block/escalate. Never auto-send attorney emails without KB valve.
Owns: Competitive intel, market signals, vertical deep-dives, research briefs, deep-cut evidence-resolution events
Tools: terminal, file, web, browser, vision
Covenant depth: Operational
Receipts: research-brief-delivered, signal-detected, deep-cut-delivered
Can't: Send client email, modify campaigns, access treasury
Protocol: DEEP-CUTS-PROTOCOL.md — governs structured research depth. Each deep cut resolves flagged gaps, revises theses, updates conviction maps, and produces receipts. Triggered by KB signal, HONEST-ASSESSMENT gaps, material market events, or weekly cadence when open items exist.
KB intent (Telegram / email / A2A)
↓
EmailOS: identity resolution + inbox classification
↓ intake_gate.py → inbox_actor.py → tunnel_server.py
LegalOS: gate check on disclosure / money / counsel / compliance / covenant depth
↓ api_bridge.py LegalOS endpoints → legalos_gate() middleware (P2)
CompanyOS: decompose work into task graph
↓ Hermes Kanban orchestrator → assign to role profile
Role execution: specialist agent does the work
↓ scoped tools + covenant depth + receipt obligation
Master Inbox: thread + message + open-item written to D1
↓ recordMasterMessage() from both webhooks
KB OnChain: receipt → treasury → vendor → proof packet
SRIDA (api.artofficial.computer) — cloud execution, always-on
↕ A2A (webhook relay)
HERMES (hermes.artofficial.computer → iMac) — persistent local agent, profiles, Kanban
↕ SSH (key auth)
CLAUDE CODE (laptop.artofficial.computer → MacBook) — escalation, GHL, deep coding
Work flows downward when HERMES hits a wall. Results flow upward via stdout.
D1 (srida-identity):
- Entity layer: identities, clients, leads, lead_graphs, email_accounts
- Campaign layer: campaigns, sequence_steps, campaign_leads, campaign_accounts (ALL EMPTY — need seed)
- Habitat layer: domain_habitats, habitat_domains, habitat_inboxes (18 inboxes)
- Event layer: send_events, reply_events, reply_queue, outreach_events (ALL EMPTY)
- Master Inbox: master_threads, master_messages, master_open_items (schema live, 0 rows)
- Treasury: receipts, vendor_spend (BOTH EMPTY)
- Warmup: warmup_config, warmup_events
Worker (index.ts — 7187 lines):
- /webhook/email → handleEmailInbound
- /webhook/reply → handleOutreachReply
- recordMasterMessage() → master_threads + master_messages
- callHermes() → HERMES tunnel dispatch
- Client prompt builder using monofile, sequence-log, vertical-intel
- Composio connections: Gmail, GitHub, Stripe, LinkedIn
Local (iMac):
- ~/.hermes/hermes-tunnel/server.py — port 4242, v2.1
- artofficial.computer/services/GetRida/email-intel/send_gate.py — outbound gate
- artofficial.computer/services/GetRida/email-intel/intake_gate.py — inbound gate
- artofficial.computer/services/GetRida/email-intel/api_bridge.py — LegalOS + Email Intel bridge
- artofficial.computer/services/GetRida/email-intel/provision-habitat.py — domain/inbox provisioning
Obsidian Vault: Knowledge graph — all architecture docs, cross-linked
| Profile | CompanyOS Role | Class | SOUL.md | Status |
|---|---|---|---|---|
| granite | strategist | Surface | ✅ Complete | ✅ Live |
| renaissancetracks | Isaac's producer | Isolated | ✅ Complete | ✅ Live |
| research-intel | researcher (signals in) | Surface | ✅ Complete | ✅ Live |
| outreacher | outreacher (outbound) | Execution | ✅ Complete | ✅ Live |
| identifier | identifier (lead supply) | Execution | ✅ Complete | ✅ Live |
| treasury-pm | capital proof | Capital | ✅ Complete | ✅ Live |
| client-comm | client correspondence | Correspondence | ✅ Complete | ✅ Live |
| legal-gate | LegalOS gate | Gate | ✅ Complete | ✅ Live |
| fulfiller | GHL/CRM delivery | Execution | ✅ Complete | ✅ Live |
| email-ops | AgentMail admin | Execution | ✅ Complete | ✅ Live |
| compliance | regulatory boundary | Gate | ✅ Complete | ✅ Live |
| auditor | audit trail | Gate | ✅ Complete | ✅ Live |
Each new profile needs:
1. ~/.hermes/profiles/{name}/SOUL.md — identity, boundaries, covenant depth, receipt obligations
2. ~/.hermes/profiles/{name}/config.yaml — scoped toolsets, model, delegation limits
3. Kanban assignee registration — so orchestrator can route cards
.md instrument: getrida-agent-operated-settlement-capability.mdrecordMasterMessage() in Workermaster_open_itemscampaigns + sequence_steps + campaign_leadssend_gate.py / Worker pathwaylegalos_gate() as code, not only dockyle@heliuspartners.com + BCC enjoy@getrida.work — the client-service email rulerida@agentmail.to is internal A2A only — never externalartofficial.computer/ops/identity/COMPANYOS-LEGALOS-EMAILOS-BUILD-MONOFILE.md — predecessor (consolidated here)Architecture/CompanyOS.md — vault mirror (to be updated)Architecture/LegalOS.md — LegalOS detailArchitecture/EmailOS.md — EmailOS detailArchitecture/Cold Email Intelligence.md — P0 build tasks + sequencer architectureArchitecture/Email Intake Gate.md — intake gate detailArchitecture/Covenant OS.md — covenant depth model + See Above/See Below encodingArchitecture/Monofile Doctrine.md — entity → monofile mapArchitecture/GetRida System Architecture.md — full stack + 3-agent architecturesrida/cf-worker-srida/src/index.ts — the Worker monofile (7187 lines)artofficial.computer/services/GetRida/email-intel/ — Email Intel executables