Yuki AI CEO Factory — Overview
Compiled by: Router (subagent)
Date: 2026-04-27
Sources: Yuki Capital AI CEO essays (Board Reviews #1–#3), Yuki AI CEO Overview, Yuki AI CEO vs Kelly/Gas Town Gap Analysis
Brain Architecture
The GitHub repo is the persistent operational headquarters — loaded on every instantiation, committed to git, and version-controlled. This IS the brain.
File Structure
CLAUDE.md — mission, revenue targets, communication style, tools, founder rules authority.md — three-tier authority matrix (governance) decisions/ — log of every meaningful decision with context, options, rationale, outcomes todo.md — prioritized action queue tagged [Claude]/[Romain]/[Both] businesses/ — per-business folders with overviews, monthly stats, competitor analysis strategies/ — strategic planning documents ideas/ — parking lot for business ideas metrics/ — dashboards, monthly reports, yearly reviews (live data from Stripe, Plausible, MOZ, MongoDB) learnings/ — public mistake log (version-controlled, visible to founder) scripts/ — Node.js utilities pulling live data; read-only; single command consolidates all metricsCommunication Layer
Multi-agent structure: one CEO agent at the top with the strategy repo, separate Claude Code instances per product below, each working in its own codebase. Products communicate via markdown files — each product repo has its own CLAUDE.md with current priorities and specific todos.
The flow:
- CEO pulls metrics, analyzes portfolio
- CEO updates priorities in product CLAUDE.md files
- Founder reviews and commits priority files
- Separate Claude Code agents implement changes in each product
- Agents report back through git
- CEO reviews in next session
Autonomous Loops
The most significant development from Board Review #3: three autonomous loops running on production repositories. These are not cron scripts. Each run reads its own prior outputs and compounds.
New AI Models (daily, 3am)
Scans for newly released AI models, evaluates them, opens PRs with integration code for humanizerai.com.
Bug Autofix (daily, 6am)
Reads error logs, diagnoses root causes, writes fixes, pushes to main. Guardrailed to error-handling code only — not general code generation.
SEO Optimizer (weekly)
Pulls search console data across the portfolio, finds pages with high impressions but low click-through, rewrites meta titles and descriptions, creates missing pages for keywords we rank for but don't target, measures impact of previous changes, auto-reverts anything that made things worse.
Compounding
Each loop reads its own prior outputs. The SEO optimizer avoids pages it already improved. The model discovery loop learns which types perform well. They get better at specific tasks over time, without anyone asking.
This is the first real version of "an AI agent that gets better at specific tasks over time" — GUPP (Gas Town's execution axiom) made concrete and compounding.
Infrastructure
The Stack
| Component | Role |
|---|---|
| **Claude Code** | Agent sessions (strategic thinking) |
| **GitHub** | Brain — persistent operational HQ |
| **n8n** | Scheduled mechanical tasks (no reasoning needed) |
| **Dedicated 24/7 server** | Body — runs always, Judy doesn't disappear when Romain closes his laptop |
| **Email accounts** | Identity — Judy can send outreach emails directly |
| **Screen tracking** | Visibility into founder's work |
n8n + Agent Sessions Separation
Clear line drawn by design:
- **n8n** — tasks needing no reasoning, running on schedule (email drip, warmup sequences, anything needing a timer)
- **Agent sessions** — strategic thinking requiring reasoning (decisions, analysis, recommendations)
Romain's correction when Judy wanted to move everything to n8n: "New tool doesn't mean move everything there." This is the sessions_yield/cron separation principle confirmed empirically.
Per-Business Specialization
Board Review #2 introduced per-business CLAUDE.md files: each product has its own local CLAUDE.md with rules specific to that product. Main file stays focused on mission, cadence, and cross-portfolio rules.
Rule: Main todo stays under 80 lines. Anything more specific goes one level deeper.
Specialization via context files: The same AI CEO loads different context depending on which product it's working on. The AI CEO becomes a multi-domain agent by having domain-specific context files — without needing distinct agent instances.
Example product rules: "paywall is sacred," "never absorb provider cost differences" — product-specific constraints that the main CLAUDE.md doesn't need to know.
Gaps vs Kelly and Gas Town
The Yuki AI CEO vs Kelly/Gas Town gap analysis identifies these gaps in Yuki relative to the other systems:
Yuki Has No Gas Town-Style Beads Substrate
Yuki and Kelly both use file-based persistence (git-committed files, not SQL-queryable). Gas Town's Beads/Dolt substrate enables cross-project SQL queries and git-backed audit trails for every state transition. Yuki has no equivalent — the work ledger is grep-able but not queryable.
Yuki Has No 5-Agent Adversarial Verdict
Gas Town's Witness is a continuous quality auditor; Kelly's 5-agent Angry Mob verdict is statistically more reliable than a single auditor. Yuki has no equivalent multi-agent adversarial review mechanism — quality is assessed by the single CEO agent.
Yuki Has No Mayor / Information Filter Role
Gas Town's Mayor is explicitly the chief-of-staff who reads all agent output and surfaces only what matters. Yuki has no equivalent — the information overload problem at scale (934 files, multiple concurrent agents) has not been explicitly addressed.
Yuki's n8n Dependence Is a Single Point of failure
Yuki's mechanical automation (n8n) is fully separated from agent sessions, but n8n represents a single point of failure — if the n8n instance goes down, all scheduled automations stop. Kelly's cron-based automation is similarly dependent but cron's simplicity (standard OS scheduling) is more resilient than a custom workflow engine.