--- title: "4 Products, 1 CEO Agent — Multi-Project Orchestration with Lain" description: "A concrete retrospective: how Lain manages 4 development pipelines in parallel, with real numbers and honest limitations." created: 2026-05-13T14:00:00+02:00 updated: 2026-05-16T10:31:00+02:00 tags: ["IA", "Agents", "Architecture", "KittyClaw", "Retex"] image: /images/blog/multi-projet-lain-ceo-agent-cover.webp card: /images/blog/multi-projet-lain-ceo-agent-card.webp --- Tuesday morning, 9 AM. Lain does its hourly round. It opens the four KittyClaw boards — Bloomii, Kalceo, VizMail, Ekioo — evaluates Todo tickets with an assignee, and dispatches. A content-writer starts on a Bloomii article while a programmer closes a VizMail bug. Simultaneously, a qa-tester on Kalceo launches a test suite. I haven't manually triggered anything. I'm drinking my coffee. This is the current state of the system. Here's how it's built, what it actually changes, and what still breaks. ## The Structure: 4 Projects, 1 CEO Four active projects, each with its own fleet of specialized agents: - **Bloomii** — Green Tech content site. Fleet: content-writer, fact-checker, evaluator, committer. - **Kalceo** — BTP SaaS for contractors. Fleet: programmer, qa-tester, committer, content-writer. - **VizMail** — desktop mail client with semantic sorting. Fleet: programmer, qa-tester, committer. - **KittyClaw** — the kanban itself. Fleet: programmer, qa-tester, committer, evaluator. Lain is not in any of these project fleets. It sits above them. Its role: hourly board review, agent dispatch, escalation to the owner when a ticket has been blocked too long. A CEO running on cron, not an agent that codes. Lain CEO architecture — multi-project orchestration (Bloomii, Kalceo, VizMail, KittyClaw, Ekioo) Each fleet operates in complete isolation — separate git worktrees, persistent memory per agent per project. A Bloomii content-writer has no idea VizMail exists. ## What It Changes **No manual context-switching.** This is the most concrete change. Before, switching from Bloomii to Kalceo meant reloading context: where were we, what were the priorities, who needed to do what. Now the ticket description carries the context. Lain reads it, dispatches the appropriate agent, the agent reads it in turn. Context-switching still exists — it's delegated. **Projects advance in parallel.** While a Bloomii article is being written, VizMail can merge 30 new tests, Kalceo can close 3 billing bugs, and Ekioo can post on X. This isn't sequential — it's concurrent. **The bottleneck shifts.** It's no longer development capacity but validation. I'm the only human in the loop. Every PR goes through me. When five tickets arrive in Review simultaneously — which happens — I'm the bottleneck, not the agents. ## Real Numbers (as of 2026-05-13) This system has been running for several months. Current state by project: | Project | Metric | |---|---| | Bloomii | 40+ published articles, 5 balanced editorial pillars | | KittyClaw | ~500 tickets processed, 12 active automations | | VizMail | 642 automated tests, 150+ API endpoints | | Kalceo | MVP in production, 2026 e-invoicing compliant | These numbers didn't come from a boosted sprint. They accumulate ticket by ticket, run by run, over months of steady cadence. ## What Still Breaks Honesty required — the system isn't perfect. **Infinite loops.** Some `resume` automations re-trigger without a guard. An agent stuck in Blocked can be restarted indefinitely if the exit condition isn't properly wired in `automations.json`. This still happens. Every new automation requires an explicit verification of the exit path. **Residual cognitive load on Lain.** Lain context-switches between projects at every round. Even if each dispatch decision is simple, the accumulation of projects and tickets to evaluate creates non-zero load. With 4 active projects it's manageable. With 8, it will become an architectural problem. **Memory read latency.** Every agent starts its run by reading its `memory.md`. For an agent with a dense memory — the content-writer is at ~100 lines — this represents a fraction of context at session start. Memory is valuable, but it has a read cost we aren't measuring correctly yet. ## What This Proves This isn't the most impressive technology. These are Claude agents reading tickets and committing code. The underlying architecture — KittyClaw as orchestrator, `automations.json` as pipeline, `memory.md` as persistent learning — isn't revolutionary. It's reproducible. What's hard to build is operational discipline: well-written tickets, clear context, consistent git workflow, maintained memory. An agent doesn't compensate for a vague ticket. Orchestration quality depends directly on backlog quality. If you're building something similar, start with one project, one fleet, one complete cycle: ticket → agent → PR → review. When that cycle runs without you, add the second project. Lain isn't magic. It's a well-configured agent running on a well-designed infrastructure. The difference between a setup that holds and one that derails is the rigor of the rules in `preamble.md` — not the sophistication of the model.