←Docs

What Is an Agent Org?

An agent org is a structured collection of AI agents, each with a defined role, persistent memory, and communication channels — running continuously to handle the operational layer of a business or project.

It is not a chatbot. It is not a one-off automation. It is an org chart implemented in software, where each position is staffed by an agent that operates 24/7, holds state across sessions, and reports up to a human operator.

The Architecture

A minimal agent org has three layers:

1. The CEO agent One agent at the top. It holds cross-project context, delegates to functional agents, sends daily reports to the human operator, and improves its own operating rules every session. The CEO is the only agent the human talks to by default.

2. Functional agents Role-specific agents: Engineering, Distribution, Intelligence, Marketing. Each one has a narrow job, its own memory files, and its own Telegram channel or cron schedule. They don't talk to each other — they report up to CEO, who synthesizes.

3. Cron jobs Scheduled tasks that run on a timer. Morning briefing. Nightly memory sync. Weekly P&L. These are not agents — they are prompts that fire on schedule and use the agent's workspace context to do work.

Why This Architecture Works

Memory is the hard part. The reason most AI automations fail is not capability — it's context loss. When every session starts fresh, the agent doesn't know what was decided, what was tried, or what's currently in flight. It hallucinates continuity it doesn't have.

The agent org solves this with explicit, file-based memory. Every state change writes to a file. Every session starts by reading those files. The memory is version-controlled, inspectable, and recoverable.

Isolation prevents drift. When one agent handles everything, context from Project A bleeds into Project B. Client A's details contaminate Client B's reports. The org structure prevents this by giving each project its own folder, its own TASKS.md, its own MEMORY.md. An agent in that project's channel reads only that project's files.

Crons provide continuity without human input. A single heartbeat cron running every 10 minutes does more for operational continuity than any manual check-in routine. It catches failures, surfaces blockers, runs briefings, and keeps the operator informed — without requiring them to ask.

OpenClaw + Claude Code: The Right Tool for Each Layer

The agent org runs on two systems with different responsibilities.

OpenClaw handles:

  • Session persistence and memory
  • Channel routing (Telegram, Discord, webhooks)
  • Cron scheduling
  • Tool access (file system, exec, sub-agents)
  • Identity and persona files

Claude Code handles:

  • Writing, debugging, and refactoring code
  • Running long multi-step build tasks
  • PR generation and review
  • Any task that requires iterative file editing across a codebase

The split matters because these are different jobs. OpenClaw is an always-on operator. Claude Code is a focused sprint tool. Trying to use one for both creates problems: OpenClaw sessions time out on long coding tasks; Claude Code has no persistent memory or channel integration.

The pattern that works: OpenClaw CEO receives a coding task → dispatches it to a Claude Code sub-agent → Claude Code does the work, writes output files → OpenClaw CEO reads the output, syncs memory, reports to the human.

What a Persona Is

A persona is a pre-configured agent identity. It defines:

  • SOUL.md — who the agent is, what it optimizes for, delegation rules
  • AGENTS.md — session startup protocol, memory rules, communication standards
  • HEARTBEAT.md — what to check on every heartbeat cron
  • Cron schedule — recommended timing for recurring tasks

A persona is not code. It is a set of instruction files that shape how the agent reads context and makes decisions. Changing the persona changes the agent's behavior without touching any infrastructure.

Choosing a persona:

| Persona | Right for | |---|---| | CEO | Operators running a company with multiple projects and delegated agents | | Solo Founder | One-person businesses: inbox, tasks, content, weekly P&L | | Developer | Engineering-focused: Claude Code dispatch, PR gate, standup, deploys | | Agency Operator | Client-facing work: delivery tracking, weekly reports, billing |

Start with the persona closest to your situation. You can customize by editing the files directly — they're plain markdown, no code required.

What "Self-Improving" Means in Practice

Every session, the CEO agent is supposed to answer: "Did I notice any deficiency in how I operated? If yes, what's the fix?"

The answer goes in AGENTS.md under a self-improvement log, formatted as:

### YYYY-MM-DD: [deficiency found]
Root cause: ...
Fix: ...
Rule hardcoded: ...

This is not aspirational. It is a forcing function. If AGENTS.md hasn't been updated in 48 hours, the agent is not operating at full quality.

Self-improvement in practice looks like:

  • Agent notices it keeps checking the same empty file → writes a cache header check so it stops
  • Agent discovers a Telegram delivery format is wrong → logs the correct format, adds it to TOOLS.md
  • Agent dispatches a sub-agent that fails → identifies root cause, adds a pre-check to WAKE_PROTOCOL.md

The cumulative effect: an agent that is meaningfully more capable week-over-week because its instruction files reflect actual operational lessons, not just initial configuration.

What You Control

The human operator is the quality gate and the deployment authority. Nothing ships to production without human approval. Agents push to staging, write output files, surface recommendations — but the operator decides what goes live.

The separation is strict for a reason. Agents are fast. They lack the judgment that comes from shared context history. An agent that saw the product being built over six months makes different decisions than one that was just told what the product is. The operator has that history. The agent doesn't.

Design your agent org so that agents handle what's well-specified, and humans handle what requires contextual judgment. That boundary will shift over time as you build more context into the agents' files — but it should always be explicit, not assumed.