The 4-Layer Architecture of a One-Person Company Operating System (OPC-AOS)

The Pain — You've automated content generation, testing, and deployment — yet you still copy finished articles into the editor by hand and chase stuck tickets manually. Each module is 50% automated, but the manual seams between modules eat the gains: total time saved ends up under 20%.

What You'll Learn:

• Why "point automation" fails, and what a truly closed loop looks like
• The 4-layer OPC Automation OS (OPC-AOS): Core → Delivery → Service → Growth
• A runnable Python scaffold — data models, a pipeline scheduler, and a growth analytics engine — up and running in ~30 minutes
• A Before/After comparison, and why a "system" beats a pile of "tools" by 100×

Over the past eight articles, we took AI Agents step by step from "writing prompts" to "designing Loop Engineering" — persistent state, Maker/Checker separation, automated verification, physical enforcement locks, and a self-verification system. But there's one question I've never answered: once your Agent is reliable — then what?

OPC-AOS 4-layer architecture: Core → Delivery → Service → Growth

1. An Awkward Truth

I spent three months tuning my Agent from "forgets everything overnight" to "24/7 unattended self-verification." I was proud of it. Then I stared at it: it can write code automatically, test automatically, fix automatically, and deploy automatically.

Then what?

Can it make money for me? Can it acquire customers for me? Can it serve customers for me? Can it free me from the 996 grind so I can genuinely become a "system owner"?

No.

Because my architecture solved the AI engineering problem — not the business automation problem. I had built an excellent engine, but I hadn't put it in a car that can drive.

This isn't unique to me. I've studied the tech stacks of many OPC founders and found a pattern:

90% of OPC founders have "point automation" — automated content generation, automated testing, automated deployment — but almost nobody has a full closed loop.

They spend three months on Agent engineering, three months on content automation, three months on a support bot. But every module is isolated: the articles the content automation generates have to be manually moved into the WeChat editor; the tickets the support bot can't handle have to be manually chased.

Every link is 50% automated, but combined, the time saved is under 20%.

Because of the breaks — between every two automation modules, there's a manual seam.

2. The Cure: The 4-Layer OPC Automation OS

To eliminate manual seams, you have to start from the top-level design. Not "today I'll build a content tool, tomorrow a support tool" — first, draw the complete blueprint.

I call it the OPC Automation OS (OPC-AOS), a 4-layer architecture:

┌───────────────────────────────────────────┐
│ 🚀 Layer 4: Growth                         │
│ Acquisition · Funnels · A/B · Analytics   │
├───────────────────────────────────────────┤
│ 💰 Layer 3: Service                        │
│ AI support · Delivery · Users · Billing   │
├───────────────────────────────────────────┤
│ 📦 Layer 2: Delivery                       │
│ Content · Build · Asset pipelines         │
├───────────────────────────────────────────┤
│ ⚙ Layer 1: Core (Series 1 output)         │
│ Agent framework · Memory · Quality · Tools│
└───────────────────────────────────────────┘

The core design principle: every layer communicates with the layers above and below only through standardized interfaces. Upper layers don't care about implementation details below; lower layers know nothing about the business logic above.

This means:

• You can build Layer 1 first (Series 1 already did this), then work your way up layer by layer
• Every layer can be independently replaced or upgraded
• Any "manual seam" between two layers is an architecture defect

3. Starting From Code: A Runnable OPC-AOS Scaffold

OPC-AOS Scheduler: Receive → Route → Execute → Feedback

Enough theory. Let's get real.

The scaffold below defines the core data models and communication interfaces of the 4-layer architecture. In 30 minutes, you can have it running on your own machine.

Step 1: Create the project structure

mkdir -p opc-aos/{core,delivery,service,growth,shared}
cd opc-aos
touch shared/__init__.py core/__init__.py delivery/__init__.py service/__init__.py growth/__init__.py

Step 2: Define the data models — make every layer speak the same language

# shared/models.py
from dataclasses import dataclass, field
from datetime import datetime
from enum import Enum
from typing import Optional


class ContentType(str, Enum):
    ARTICLE = "article"
    VIDEO = "video"
    CODE = "code"
    PRODUCT = "product"


class DeliveryStatus(str, Enum):
    QUEUED = "queued"
    IN_PROGRESS = "in_progress"
    COMPLETED = "completed"
    FAILED = "failed"


@dataclass
class ContentAsset:
    """Layer 1→2: the content asset produced by the Agent"""
    id: str
    content_type: ContentType
    title: str
    body: str
    metadata: dict = field(default_factory=dict)
    created_at: str = field(default_factory=lambda: datetime.now().isoformat())
    tags: list = field(default_factory=list)


@dataclass
class DeliveryOrder:
    """Layer 2→3: the delivery work order"""
    content_id: str
    channel: str  # "wechat" | "website" | "email"
    status: DeliveryStatus = DeliveryStatus.QUEUED
    result_url: Optional[str] = None
    error: Optional[str] = None


@dataclass
class UserAction:
    """Layer 3→4: user behavior event"""
    user_id: str
    action_type: str  # "view" | "subscribe" | "purchase" | "ticket"
    payload: dict = field(default_factory=dict)
    timestamp: str = field(default_factory=lambda: datetime.now().isoformat())

Design notes:

• dataclass instead of dict — every data structure has an explicit schema; layers never pass "unknown fields" to each other
• Enum constraints — state machines are fixed at the type level; "pending" and "PENDING" can never coexist
• Optional null-safety — passing None where you shouldn't is a loud Exception, not silent corruption

These look like small things, but I only arrived here after tripping over three data-inconsistency bugs. How strict your interface contracts are directly decides whether the system can run long-term.

Step 3: The core scheduler — get the pipeline turning

# core/scheduler.py
"""End-to-end scheduler: the receive → route → execute → feedback loop"""
import logging
from typing import Callable

from shared.models import ContentAsset, DeliveryOrder, DeliveryStatus, UserAction

logger = logging.getLogger("opc-aos")


class PipelineStep:
    """The standard interface for one step in the pipeline"""

    def __init__(self, name: str, handler: Callable):
        self.name = name
        self.handler = handler

    def execute(self, context: dict) -> dict:
        logger.info(f"[{self.name}] executing...")
        try:
            result = self.handler(context)
            logger.info(f"[{self.name}] ✅ done")
            return result
        except Exception as e:
            logger.error(f"[{self.name}] ❌ failed: {e}")
            raise


class ContentPipeline:
    """Layer 1 (Agent output) → Layer 2 (format conversion) → Layer 3 (publish)"""

    def __init__(self):
        self.steps: list[PipelineStep] = []

    def add_step(self, name: str, handler: Callable):
        self.steps.append(PipelineStep(name, handler))

    def run(self, asset: ContentAsset) -> DeliveryOrder:
        context = {"asset": asset}
        for step in self.steps:
            # each step's output automatically becomes the next step's input
            result = step.execute(context)
            if result:
                context.update(result)
        return context.get(
            "order",
            DeliveryOrder(
                content_id=asset.id,
                channel="unknown",
                status=DeliveryStatus.FAILED,
                error="Pipeline completed without producing an order",
            ),
        )


# example: from content to WeChat publication
pipeline = ContentPipeline()
pipeline.add_step(
    "format_markdown",
    lambda ctx: {"formatted": f"# {ctx['asset'].title}\n\n{ctx['asset'].body}"},
)
pipeline.add_step(
    "upload_to_wechat",
    lambda ctx: {
        "order": DeliveryOrder(
            content_id=ctx["asset"].id,
            channel="wechat",
            status=DeliveryStatus.COMPLETED,
            result_url="https://mp.weixin.qq.com/s/example",
        )
    },
)

With this skeleton, the OPC-AOS runtime mechanism is clear:

1. Layer 1's Agent produces a ContentAsset
2. The Core Scheduler feeds the asset into the ContentPipeline
3. Each pipeline step executes automatically and hands its output to the next
4. The final output is a DeliveryOrder — published, or failed
5. Zero human intervention

Step 4: The automated growth engine — feed data back into the system

# growth/analytics.py
"""A simple growth analytics engine that auto-tracks conversion funnels"""
from collections import defaultdict

from shared.models import UserAction


class GrowthEngine:
    """Layer 4: growth tracking — the full lifecycle of every piece of content"""

    def __init__(self):
        self.events: list[UserAction] = []

    def record(self, action: UserAction):
        self.events.append(action)

    def content_funnel(self, content_id: str) -> dict:
        """the conversion funnel from exposure to purchase"""
        funnel = defaultdict(int)
        for event in self.events:
            if event.payload.get("content_id") == content_id:
                funnel[event.action_type] += 1
        return {
            "views": funnel.get("view", 0),
            "subscribes": funnel.get("subscribe", 0),
            "purchases": funnel.get("purchase", 0),
            "conversion_rate": (
                f"{funnel.get('purchase', 0) / max(funnel.get('view', 1), 1) * 100:.1f}%"
            ),
        }


# usage example
engine = GrowthEngine()
engine.record(UserAction("user_1", "view", {"content_id": "a01"}))
engine.record(UserAction("user_1", "subscribe", {"content_id": "a01"}))
engine.record(UserAction("user_1", "purchase", {"content_id": "a01"}))
print(engine.content_funnel("a01"))
# output: {'views': 1, 'subscribes': 1, 'purchases': 1, 'conversion_rate': '100.0%'}

Note: this engine is under 30 lines of code, but it gives the system "self-awareness." Before, you'd open the WeChat dashboard by hand to check read counts; now the system tracks the complete conversion funnel of every article automatically — and can even decide by itself what to write next.

Step 5: Wire it all together — 24-hour unattended operation

# main.py
"""OPC-AOS main entry point — runs once every 30 minutes"""
import logging
from datetime import datetime

from core.scheduler import ContentPipeline
from growth.analytics import GrowthEngine
from shared.models import ContentAsset, ContentType, DeliveryOrder, DeliveryStatus

logging.basicConfig(level=logging.INFO)
logger = logging.getLogger("opc-aos.main")


class OPCAutomationOS:
    def __init__(self):
        self.pipeline = ContentPipeline()
        self.engine = GrowthEngine()
        self._setup_pipeline()

    def _setup_pipeline(self):
        self.pipeline.add_step("verify_quality", self._quality_check)
        self.pipeline.add_step("publish_to_wechat", self._publish)

    def _quality_check(self, ctx: dict) -> dict:
        # reusing the quality-check system from Series 1
        asset: ContentAsset = ctx["asset"]
        issues = []
        if len(asset.body) < 500:
            issues.append("内容过短")
        return {"quality": "pass" if not issues else f"fail: {issues}"}

    def _publish(self, ctx: dict) -> dict:
        logger.info(f"publishing: {ctx['asset'].title}")
        # publish via the platform's official API
        return {
            "order": DeliveryOrder(
                content_id=ctx["asset"].id,
                channel="wechat",
                status=DeliveryStatus.COMPLETED,
            )
        }

    def run_cycle(self, asset: ContentAsset):
        """one complete run cycle"""
        logger.info(f"🚀 processing: {asset.title}")
        order = self.pipeline.run(asset)
        logger.info(f"✅ done: {order.status.value}")
        return order


if __name__ == "__main__":
    aos = OPCAutomationOS()
    # simulate the Agent producing an article
    article = ContentAsset(
        id=f"article-{datetime.now().strftime('%Y%m%d-%H%M')}",
        content_type=ContentType.ARTICLE,
        title="OPC自动化实践：从零到一",
        body="这是一篇由AI自动生成的OPC实践文章……",
    )
    order = aos.run_cycle(article)
    print(f"publish status: {order.status.value}")

Notice what happened? 35 lines of code wired together one complete run cycle of the 4-layer architecture. Agent produces content → quality check → auto-publish → track results. All automatic.

4. Comparison: Before vs. After

Dimension	Before (point automation)	After (OPC-AOS)
Content production	Agent generates → manually copy into WeChat	Agent generates → Pipeline auto-QC + auto-publish
Effect tracking	Weekly manual look at dashboard data	GrowthEngine auto-tracks each article's conversion funnel
Error handling	Errors discovered manually	Every step has try/except; failures logged automatically
Adding a new channel	Rebuild from scratch	Add one PipelineStep
Data consistency	Every tool uses its own format	Unified dataclass contracts
Solo maintainability	3 tools = 3 sets of logic to maintain	1 Pipeline maintains everything

Before: you have 4 automation tools, but you still spend an hour a day on "manual handoffs." After: you have 1 automation system, and you spend 10 minutes a day checking exceptions.

The gap isn't code volume. It's architecture design.

5. Why a "System" Matters 100× More Than "Tools"

I've watched too many OPC founders stumble on exactly this:

They don't lack automation ability — they try to be "perfect" too early. They see content automation, spend three days building it; they see support automation, spend another three days building it. Each tool looks great on its own — but they were never wired together.

This is the classic systems thinking vs. tools thinking split:

• Tool mindset: I want to solve this specific problem
• System mindset: I want to design a structure that keeps solving this class of problems

The tool-minded person builds 5 tools and spends an hour a day managing the "seams" between them. The system-minded person spends one day designing the architecture — and spends all the remaining time just adding new Steps.

Series 1 ran for eight articles and taught you how to design reliable Agents. Now we're assembling those Agents into a business system that runs itself.

6. What's Next

This is Part 1 of the OPC Automation Pipeline series. We've built the skeleton of the 4-layer architecture and its scheduler.

But one key problem remains unsolved: what if the content the Agent produces is unreliable?

Next time we'll go deep into Layer 2 (Delivery) and build a complete automated content factory — AI that doesn't just generate content, but also auto-reviews it, auto-adds images, auto-formats it, and auto-schedules publication windows, with zero human intervention.

Key spoiler: the core of the next article is not "write the perfect prompt so the AI writes a great article" — that's for prompt writers. Our approach: have the AI generate 10 articles, then use rules to automatically pick the best one to publish. Quality isn't guaranteed by "writing well" — it's guaranteed by "selecting well."

Series plan:

#	Title
01	✅ The complete architecture of a one-person company — the 4-layer design of the OPC Automation OS (this article)
02	🔜 The automated content factory — a complete solution for AI-powered continuous output
03	📝 Customer service as code — using AI Agents to handle 95% of user inquiries automatically
04	📝 No more manual handoffs — the OPC automated product delivery system
05	📝 The data-driven growth engine — automatic analysis from reads to paid conversion
06	📝 A/B testing for one person — an AI-driven automated optimization system
07	📝 From 996 to 007 — the OPC unattended operations system
08	📝 Sell the system to more people — from one-person company to replicable business system

About the author: Wu Ji (无记) — AI & digitalization practitioner focused on Agent engineering, Loop Engineering, and digital transformation. Practical, hands-on tutorials — follow along and it just works.