Skip to content

The System

I don't just build AI apps — I built an AI system that builds them.

A fleet of AI agents, coordinated by a central command center that's the single source of truth. Plan, build, QA-test, and ship — end to end — with mechanical guarantees against drift and races.

Command CenterSINGLE SOURCE OF TRUTHOrchestratorASSIGNS + SEQUENCESREADS / WRITES STATEAGENT / 01PlanningAGENT / 02Build · app AAGENT / 03Build · app BAGENT / 04VerificationSHIPPEDAbsorbySHIPPEDSoundpetalSHIPPEDGlyphSHIPPEDAdvisor OSSHIPPEDSkill ForgeSHIPPEDFluiditBUILD LOOP · PLAN → BUILD → VERIFY → SHIP → REGISTER

What to watch: each dot is one agent carrying a task around the loop — out from the command center, through its lane, and back again. Colour is the agent's role: planning, build and verification. The two build lanes run in parallel on different apps; verification is always a different model in a separate session.

Counts, reconciled: 6 apps shown in the fleet · 15 projects under orchestration · 4 live on their own production domain. The rest run on preview hosts or are internal to the system.

By the numbers

Real numbers, from the source of truth.

Every figure below is pulled from the command center — the same Umbrella hub the fleet reads and writes every session — or queried directly against the live app databases. A point-in-time snapshot as of 24 July 2026, not estimates. Each tile names its own source.

15

Projects under orchestration

Umbrella registry — tracked, active projects

1,536

Tasks carried to done through the build loop

Umbrella task ledger — every one planned, built, and closed in-system

123

Independent cross-model verifications passed

Each one a different model, in a separate session, auditing the deployed artifact

96

Publishes to production

Umbrella publish ledger — shipped, not staged

632

RLS policies enforced · 0 anonymous grants

Live-queried across 4 databases: Indra 520 · Soundpetal 103 · DebateMyBot 9 · Botan deny-by-default

4

Live on their own production domain

soundpetal.com · absorby.ai · benbuilds.ai · glyph.audreymadeit.com

51

Operating-protocol sections

Versioned, multi-model-reviewed protocol (§1–§54; §35 reserved, §51/§53 unratified)

$10

Total monthly fleet infrastructure cost

Umbrella cost rollup — one managed Postgres

Usage & revenue — instrumentation in progress

This system tracks real outcomes, not vanity metrics. Product analytics (GA4) and the payment rail are being switched on now. No usage or revenue figures will appear here until they represent real sessions and real settled payments — measured, not estimated.

01 / SOURCE OF TRUTH

Single source of truth

A central command center (an MCP-native hub on Supabase) holds all state: every project, task, decision, and build event. Agents read it at the start of every session and write it back as they work, so state never drifts.

02 / SWIM-LANE LOCKING

Swim-lane locking

Each app has one serial build lane. A mechanical lock registry (per-app leases with commit reconciliation) guarantees two agents never touch the same app at once — no races, no orphan commits.

03 / CHAINED HANDOFFS

Chained handoffs

When an agent session nears its limit, it flushes a zero-drift resume pointer and hands off; the next session resumes exactly where the last one left off, and the operating protocol itself compounds with every handoff.

04 / CROSS-MODEL VERIFICATION

Cross-model verification

Different models play different roles. One model builds; a different model, in a separate session, verifies — because a session can't audit its own incentives. Nothing is trusted on self-report; every claim is checked against the live app, the live database, and the network.

05 / SELF-IMPROVING PROTOCOL

A self-improving protocol

The fleet runs on a formal, versioned operating protocol (40+ sections and growing) covering topology, model selection, verification, testing, and launch gates. It's revised through multi-model consensus and gets sharper every cycle.

06 / REACHABILITY & QA CANON

Reachability & QA canon

A standing rule: no orphaned features. Every shipped feature must be reachable from navigation on a cold start — enforced by automated checks, agent click-throughs, and human passes.

Build loop

One loop. Every project. Every week.

  1. STEP 01

    Idea

    Captured to the command center as a tracked project.

  2. STEP 02

    Planning / Spec

    A planning agent turns intent into a build plan.

  3. STEP 03

    Build lane

    Serial per-app lane with lease + reconciliation.

  4. STEP 04

    Independent verification

    A different model, in a fresh session, audits.

  5. STEP 05

    Ship

    Publish-as-you-go; register outcomes back to the command center.

Meta-proof

This very site was planned by an agent, built in a swim-lane against the same command center, independently verified by a different model in a separate session, shipped end-to-end, and then registered back into the command center as a new tracked project.

Every gate — reachability, cross-model verification, publish-as-you-go — was enforced by the same versioned operating protocol (40+ sections) the rest of the fleet runs on. No exceptions, no shortcut path. The system built its own storefront.

Stack

MCP-native & engine-agnostic · Supabase source of truth · multi-model roster (Claude Opus / Sonnet / Haiku, plus a long-context model for weekly deep passes) · Lovable + code/CI build substrates.