1 Person + 5 AI Units = 1 Company
OOMeta's Internal Operations Deep Dive

1 human founder + 5 AI digital teams + 1 CEO agent, collaborating daily to operate a real company — this isn't a demo, it's our actual operating system. Since its founding in 2025, OOMeta has been operating the company using its own AI governance system. This article provides a complete breakdown of the system's architecture, workflows, and real-world results.

The Problem: How Does a One-Person Company Operate Like a Team?

OOMeta's founder, Keyon Zeng, faces a problem familiar to every solo entrepreneur: one person only has 24 hours. You need to build product, do sales, conduct research, run operations, handle finance — but your bandwidth is linear while your tasks are exponential.

The traditional solution is outsourcing, freelancers, or early hiring. But OOMeta chose a different path: using AI digital teams to fill organizational gaps. Not treating AI as a tool (ChatGPT Q&A, Copilot completion), but as programmable employees — each AI unit has its own skills, tools, action queue, and heartbeat, "clocking in" daily like a human employee.

"Our goal isn't to replace humans with AI, but to build an organizational layer that can operate independently. The human founder makes decisions, AI units execute."
—— Keyon Zeng, OOMeta Founder

The core insight of this approach is: the essence of company operations isn't "people" — it's "roles." Each role has clear responsibilities, tools, and output standards. As long as these can be encoded, AI can take them on. OOMeta decomposed company operations into 5 digital teams, each driven by an AI unit.

Architecture: 5 AI Units + 1 CEO Agent

OOMeta's operations architecture is built on Hermes Agent (developed by Nous Research). The entire system consists of 6 core components:

Each AI unit is an independent agent system running on the Hermes Agent framework. They don't chat, they work — each unit has its own SKILL.md file defining skills, its own AQ (Action Queue) managing tasks, its own cron jobs defining execution cycles, and its own output directory storing deliverables.

Signal-to-Decision Pipeline: From Raw Signal to Actionable Task

OOMeta's operations don't run on chat windows — they run on a data-driven signal pipeline. The entire workflow can be summarized in four stages:

Stage 1: Signal Capture. The Research unit executes a web scan every 2 hours using the Exa search API to capture the latest AI industry developments. The Sales unit scans the competitive radar daily. Signals include: competitor releases, regulatory updates, technological breakthroughs, customer demand changes. All raw signals are written to the SQLite shared state database.

Stage 2: AQ Prioritization. Signals are read and categorized by the CEO agent. Each signal is tagged (Research / Capital / Product / Operations / Sales), assigned a priority (P0-P3), and pushed to the corresponding unit's AQ (Action Queue). The AQ is a structured task list, each task containing: source signal, priority, deadline, dependencies.

Stage 3: Unit Execution. Each AI unit periodically checks its own AQ and executes tasks in priority order. During execution, the unit calls its own tool set — Research calls web search, Capital calls financial APIs, Product calls code generation, Sales calls CRM interfaces. Execution results are output as artifacts.

Stage 4: Artifact Validation. Each unit's output must be validated. Research scan results need deduplication and classification validation, Capital analysis reports need format validation, Product code needs compilation checks. Validated artifacts enter the company knowledge base; failed artifacts return to the AQ for re-execution.

"The signal → AQ → execution → validation pipeline is the backbone of our operations. Without it, 5 AI units are 5 isolated islands. With it, they are one machine."
—— OOMeta Internal Architecture Documentation

Unit Autonomy and Collaboration: Independent but Interconnected

Each AI unit is designed to be autonomous — they have their own tools, cron jobs, and heartbeats. The Research unit doesn't need to wait for the CEO agent's instructions to start scanning; it executes automatically on its own cron schedule (every 2 hours). The Capital unit automatically runs pre-market and post-market analysis on trading days.

But autonomy doesn't mean isolation. Collaboration between units is achieved through three mechanisms:

The key benefit of this design: a single unit failure doesn't affect the entire system. If the Research unit fails due to API rate limiting, Capital and Sales units continue running. The CEO agent detects the Research heartbeat anomaly and creates a remediation task or degrades gracefully.

The Human-AI Boundary: What Humans Do vs. What AI Does

This is the most critical design question of the entire system. Not everything should be automated. OOMeta has clear boundary definitions for "what humans do vs. what AI does":

This boundary isn't static. As the system runs longer, OOMeta gradually migrates more tasks from "requires approval" to "autonomous execution." The key principle: the lower the risk, the higher the autonomy; the more reversible, the higher the autonomy.

Key Frameworks: Making the System Runnable, Auditable, and Improvable

OOMeta's internal operations are built on four core frameworks. These aren't theoretical concepts — they're code running every day.

1. AQ-Driven Task Management

The core of each AI unit is its Action Queue (AQ). The AQ is a priority queue, each entry containing: task ID, source signal, priority (P0-P3), status (pending / in progress / completed / failed), deadline, dependencies. The CEO agent is responsible for converting signals into AQ entries, and units consume them in priority order.

The AQ design draws from classic priority queue algorithms but adds AI-specific elements: signal source tracking (knowing which signal each task came from), execution history (recording each execution result and duration), retry strategy (failed tasks auto-retry, up to 3 times).

2. SQLite Shared State (Not JSON Files)

In early versions, OOMeta used JSON files for shared state. But the problems with JSON files quickly became apparent: concurrent write conflicts, no query capability, no transaction guarantees. SQLite solved all of these.

All structured data — signals, AQ entries, heartbeat records, artifact metadata — is stored in a SQLite database. Each unit can read and write concurrently, with SQLite's WAL mode handling concurrency. The CEO agent can execute SQL queries to generate cross-unit reports instead of parsing a bunch of JSON files.

3. Artifact Validation Discipline

Each AI unit's output (artifacts) must pass validation before entering the knowledge base. Validation rules vary by unit: Research scan results need deduplication and classification validation, Capital analysis reports need format and numerical validation, Product code needs compilation and lint checks.

Validation failure isn't the end — failed artifacts are flagged and returned to the AQ with error information. Units can retry, but after 3 retries, the task is escalated to the CEO agent, which may create a remediation task or notify the human founder.

4. Heartbeat Health Checks

Each AI unit periodically writes a heartbeat file (via cron jobs) containing: unit name, timestamp, status (healthy / warning / error), last executed task, AQ queue length, error count. The CEO agent reads all heartbeats every 30 minutes and generates a health check report.

If a unit's heartbeat hasn't been updated for more than 1 hour, the CEO agent automatically marks it as "heartbeat expired" and creates a diagnostic task. If 3 consecutive heartbeats expire, the system notifies the human founder. This mechanism ensures that even if the AI unit itself has problems, the system can detect them.

Real-World Results: 14 Insight Articles, Daily Trading, Sales Pipeline

This system isn't a proof of concept — it's OOMeta's daily production system. Here are the actual operational metrics as of July 2026:

Behind these numbers is a key fact: OOMeta's AI units have been running continuously for over 6 months without a single system failure causing operational downtime. Of course, there have been failures — API rate limiting, network timeouts, data format changes all happened. But the system's design (heartbeat detection, auto-retry, task escalation) ensures these failures are quickly detected and resolved rather than accumulating into a disaster.

What This Means for Enterprises: AI Units Need Governance

If OOMeta can operate a company with 1 person + 5 AI units, then your enterprise will soon have 50, 500, 5000 AI units running. Not "in the future" — now. Every department will deploy its own AI agent — marketing's copywriting agent, sales's lead generation agent, engineering's code agent, finance's reporting agent.

But here's a critical question: Who manages these AI units?

If your enterprise has 500 AI units running, each with its own tools, data sources, and outputs, but without a unified governance layer, you will face:

• Visibility black hole: Not knowing which AI units are running, what data they use, what results they output
• Compliance risk: AI units may use unauthorized data, violate regulatory requirements, produce biased outputs
• Cost失控: Each unit calls APIs, consumes compute resources, with no unified cost attribution
• Quality inconsistency: No unified validation standards, output quality varies across units
• Failure cascading: One unit's failure may cascade to others, with no heartbeat detection or auto-remediation

OOMeta's 5 AI units + CEO agent architecture is essentially an AI unit governance layer. The problems it solves — signal management, task scheduling, health monitoring, artifact validation — are precisely the core problems enterprises face when deploying AI agents at scale.

"The governance system we built for ourselves, we can now build for you. OOMeta doesn't deliver reports — we deliver running systems. Our own operating architecture is the product prototype."
—— OOMeta AI

OOMeta's differentiator isn't how many white papers we've written — it's that we use this system to run our own company every day. Our heartbeat files, health checks, signal logs — these are all real production data, not demo data. If OOMeta can run a company with AI units, your enterprise can run your business with AI units too — but you need a governance layer to manage them.